Currently, I am assessing the Vulnerability of one of the websites and one of the points I am looking at is how can I prevent my website from potential clickjacking attacks?
I am no expert in this domain, but I have a few observations so far,
Missing X-Frame-Options header means that this website could be at
risk of a clickjacking attack.
The X-Frame-Options HTTP header field
indicates a policy that specifies whether the browser should render
the transmitted resource within a frame or an iframe.
Servers can declare this policy in the header of their HTTP responses to prevent
clickjacking attacks.
As I said, I am no expert in this field so looking forward to hear some ideas of how can I use X-Frame-Options header from preventing clickjacking attacks?
you can rely on security header X-Frame-Options to indicate to the browser not to render any iframe.
this can used by sending a response header X-Frame-Options: DENY or
X-Frame-Options: SAMEORIGIN if you want to use iframes but only for pages that are in the same origin as your page.
<IfModule mod_rewrite.c>
Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>
You can get the more details of X-Frame-Options on below
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
You can add below snippet code on last of your server .htaccess file and test the site on https://clickjacker.io/test.
Related
How do you do this?
On example.com, I need to have it so an iFrame of example.com can load at subdomain.example.co.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
So it looks like the only two options are:
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
And the one I would have wanted
ALLOW-FROM uri
Is deprecated according to the linked MDN.
Then there's frame-source
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors
The HTTP Content-Security-Policy (CSP) frame-ancestors directive
specifies valid parents that may embed a page using , ,
, , or .
Setting this directive to 'none' is similar to X-Frame-Options: deny
(which is also supported in older browsers).
what does "valid parents" mean? Where specifically do I set this? It doesn't say what file on the server you need to change.
So if I say
Content-Security-Policy: frame-ancestors subdomain.example.co;
That will work? And if so, where on the server config do I do that?
frame-ancestors can only be set when Content-Security-Policy is set as a response header. It might be controlled in a .htaccess file, but it may also be set in other types of configuration, code, webserver or proxy, depending on your setup.
"Valid parents" would be the hosts that are allowed to frame your page. It could be multiple different pages and all the hosts in a chain of framing.
You can use X-Frame-Options ALLOW-FROM for IE when you also set frame-ancestors as frame-ancestors will cause the browser to ignore X-Frame-Options for most other browsers. If you set the value in code you can insert a value from a list of acceptable framers when the referrer matches.
Is there any documentation that explains what you cannot do, to make an iframe unusable?
You cannot use facebook iframe because of x-frame-options is deny
Twitter you cannot use iframe because an ancestor violates the following content security policy directive:"frame-ancestors" self
Is there anywhere I can check what can and can't be set to accept an iframe
To my knowledge, there are two HTTP Headers that can be used to prevent a website from being loaded as an iframe on other websites:
X-Frame-Options
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>.
The possible values are:
deny
sameorigin
allow-fromuri
You can read more about what they each do on MDN.
Note that according to the specification, frame-ancestors takes precedence over X-Frame-Options:
The frame-ancestors directive obsoletes the X-Frame-Options header. If a resource has both policies, the frame-ancestors policy SHOULD be enforced and the X-Frame-Options policy SHOULD be ignored.
From the example you posted, it seems like Facebook has X-Frame-Options: deny as a response header, which prevents it from being loaded in an iframe from anywhere (in browsers that support this header).
Content-Security-Policy
Using either:
frame-ancestors which restricts what domains can embed this website in an iframe
The HTTP Content-Security-Policy (CSP) frame-ancestors directive specifies valid parents that may embed a page using <frame>, <iframe>, <object>, <embed>, or <applet>.
The main difference with X-Frame-Options is that
many user agents implement SAMEORIGIN such that it only matches against the top-level document’s location. This directive checks each ancestor. If any ancestor doesn’t match, the load is cancelled.
frame-src which restricts what domains this website can embed in an iframe
The HTTP Content-Security-Policy (CSP) frame-src directive specifies valid sources for nested browsing contexts loading using elements such as <frame> and <iframe>.
You can read more about frame-ancestors and frame-src on MDN.
From the example you posted, it seems like Twitter has Content-Security-Policy: frame-ancestors 'self', which means that that website can only be embedded on the same domain.
I have a server which hosts resources for several users on the same hostname. For example:
http://example.com/alice/blog.html
http://example.com/bob/cat.jpg
http://example.com/carol/todo.txt
I would like to allow users to specify their own response headers for resources within their directories, similar to what is done on AWS S3. For example, Carol may want her TODO list readable from scripts on another domain, so she might want Access-Control-Allow-Origin: * set for todo.txt.
While I want this feature to be as flexible as possible, I cannot allow just any response headers to be specified, as some response headers have side effects for the entire origin or hostname. For example, Set-Cookie could be used for one person's directory, but the user agent could then make a request to someone else's directory with the cookie value. As another example, a user could set Strict-Transport-Security, potentially locking out other users from using normal HTTP.
What other HTTP response headers have the potential for side effects for the entire origin, rather than just the resource that was requested? My list so far:
Alt-Svc
Public-Key-Pins
Server
Set-Cookie
Strict-Transport-Security
Rather than blocking response headers that could affect the entire domain I would recommend a slightly different approach and specify a white list of response headers that are definitely okay to use. There could be new, experimental or browser-specific headers that are non-standard but potentially affect the entire domain for a user with a specific browser.
I would suggest that the following headers are safe to use and should be everything your user needs to modify:
Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Expose-Headers
Access-Control-Max-Age
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Age
Allow
Cache-Control
Content-Disposition
Content-Encoding
Content-Language
Content-Length
Content-Location
Content-Range
Content-Type
Date
ETag
Expires
Last-Modified
Link
Location
Pragma
Retry-After
Transfer-Encoding
For static content such as files and html pages I would not set Content-Range or Content-Length manually. The server should set many of these headers automatically. Nevertheless overriding them might make sense for some users. Transfer-Encoding can be used to add gzip or deflate during transfer if your server supports it, but must not be used with HTTP/2.
Also Location, Allow and Retry-After only make sense for certain status codes. You might want to omit them
I have a requirement to set the X-Frame options on the server level to either:
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM https://example.com/
Understand that X-Frame Options are mutually exclusive. See here.
However, my application requires framing in https://example.com and also from its SAMEORIGIN.
Please advise if there is a way around this while retainining my application's requirement to having allow framing on the same origin and be framed on 1 external site.
Or is this impossible?
In addition to only supporting one instance of the header, X-Frame-Options does not support any more than just one site, SAMEORIGIN or not.
You'll have to use Content-Security-Policy and frame-ancestors, which does support multiple origins, like so:
Content-Security-Policy: frame-ancestors 'self' https://example.com
A couple notes to bear in mind:
frame-ancestors obsoletes X-Frame-Options - meaning that if frame-ancestors is present and the browser supports it, it will override the behaviour of X-Frame-Options.
Internet Explorer and Edge do not currently support the frame-ancestors directive, according to MDN. This means they will fall back to X-Frame-Options. If you need to support multiple origins in IE or Edge, see this answer on SO with a workaround.
I had a similar requirement and i handled in global.asax. i checked from where the request is coming and based on that i changed the header value to either sameorigin or allow-from. hope that helps.
Does Content-Security-Policy ignore X-Frame-Options, returned by a server, or is X-Frame-Options still primary?
Assuming that I have:
a website http://a.com with X-Frame-Options: DENY
and a website http://b.com with Content-Security-Policy: frame-src a.com
will browser load this frame?
It is unclear.
On the one hand, http://a.com explicitly denies framing.
On the other hand, http://b.com explicitly allows framing for http://a.com.
The frame-src CSP directive (which is deprecated and replaced by child-src) determines what sources can be used in a frame on a page.
The X-Frame-Options response header, on the other hand, determines what other pages can use that page in an iframe.
In your case, http://a.com with X-Frame-Options: DENY indicates that no other page can use it in a frame. It does not matter what http://b.com has in its CSP -- no page can use http://a.com in a frame.
The place where X-Frame-Options intersects with CSP is via the frame-ancestors directive. From the CSP specificiation (emphasis mine):
This directive is similar to the X-Frame-Options header that several
user agents have implemented. The 'none' source expression is
roughly equivalent to that header’s DENY, 'self' to SAMEORIGIN,
and so on. The major difference is that many user agents implement
SAMEORIGIN such that it only matches against the top-level
document’s location. This directive checks each ancestor. If any
ancestor doesn’t match, the load is cancelled. [RFC7034]
The frame-ancestors directive obsoletes the X-Frame-Options header. If a resource has both policies, the frame-ancestors policy SHOULD be enforced and the X-Frame-Options policy SHOULD be ignored.
An older question indicated this did not work in Firefox at that time but hopefully things have changed now.
UPDATE April 2018:
Content Security Policy: Directive ‘child-src’ has been deprecated. Please use directive ‘worker-src’ to control workers, or directive ‘frame-src’ to control frames respectively.
Looks like child-src is now the deprecated one and frame-src is back.
None of your hypotheses are universally true.
Chrome ignores X-Frame-Options.
Safari 9 and below ignore CSP frame-ancestors.
Safari 10-12 respect the CSP frame-ancestors directive, but prioritize X-Frame-Options if both are specified.
The answer was found by testing in practice.
I have created two web-sites and reproduced the described situation.
It seems like X-Frame-Options is primary.
If target server denies framing, then client website cannot display this page in iframe whichever values of Content-Security-Policy are set.
However, I haven't found any confirmations in documentation.
Tested on Chrome 54 and IE 11.