I would like to ask a question what is the best protection against Cross-Frame Scripting.
I have set up my web server to adding these flags into HTTP HEADER:
X-Same-Domain: 1
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Is it enough? Or is there any more protection which could be used?
My web application is running on IIS.
One answer: No.
This is a good start but these headers are indicators for the Anti-XSS filters and engines which are incorporated by the modern browsers. These are very fragile and thin protection against Cross-Site Scripting (XSS). An attacker will easily bypass these.
In order to completely make your application armoured and protected against XSS, I would still recommend using the ASP.NET's ValidateRequest filter along with a custom application-wide filter which encodes special characters in all requests.
The application should not accept any script, special character or HTML in fields whenever not required. It should escape special characters that may prove to be harmful. The characters can be escaped as per the list available at this link:
Cross-frame scripting is not a term I've seen used before. From what I've read, it sounds like it's a subset of XSS (Cross-site scripting) using injected frames. Blocking cross-site scripting should be the top priority. The critical behaviors to protect against XSS are output encoding (anything that could possibly be user-controlled gets escaped or entity-encoded before being echoed into the response, for example, a < sign into an HTML context should be turned into <) and input validation (don't let users put any kinds of values that don't match the expected format and characters for each field).
If you want a header-based protection against XSS, the solution is Content Security Policy, which restricts the sources of all kinds of potentially-malicious content (usually focused on scripts and stylesheets, but it also supports restricting frames). Used properly, CSP is an extremely strong protection, but users running old browsers (including all versions of IE) won't be protected by it (though Microsoft Edge supports it, or will soon, I forget). Note that using CSP correctly may require some refactoring of your site, to move all scripts, etc. to their own files instead of allowing inline script.
For protection against your site being framed by an attacker, the X-Frame-Options header is your go-to solution, protecting everything except extremely old browsers (like, IE6). Generally speaking, use DENY instead of SAMEORIGIN unless you have some specific reason to use SAMEORIGIN; it's not really an additional security boundary per se, but it can make certain types of attacks harder.
