Is it possible, instead of "same-origin", to specify a list of domains that are allowed to receive a referrer?
The Referrer-Policy specification makes no mention of being able to specify specific domains that would receive a Referrer.
Related
Hello I am trying to display a part of an website in an iFrame. For example: IP 1.1.1.1 wants to iframe 1.1.1.2.
In apache2 security.conf it is set to:
Header set X-Frame-Options: "sameorigin"
I tried a lot of different forms of ALLOW FROM but nothing worked. I guess those solutions are outdated.
header module from apache 2 is enabled.
Is there any workaround on that? It is really a simple displaying which costs way too much time :D
Tyvm for any hints!
ALLOWFROM is not supported in most browsers. Instead you should set Content-Security-Policy with "frame-ancestors 'self' ", where would be the other host or ip that should be able to frame. You could add multiple sources if you like, not like X-Frame-Options which is limited to one source.
In different site I see different data about what mechanism protects against inserting an iframe.
Tell me, is it possible that these are different levels of protection or are some of these outdated mechanisms?
Same-origin policy prohibits opening an iframe of another domain
At the same time, there is a Content-Security-Policy with the frame-ancestors directive
And there is also X-Frame-Options: DENY
No, the Same-Origin Policy, by itself, doesn't prevent you from framing a document from another origin.
X-Frame-Options and CSP's frame-ancestors directive overlap as defences against cross-origin framing. Only the former is supported in old browsers, though. However, the latter is much more flexible. Also, in case both are present in a response, frame-ancestors takes precedence over X-Frame-Options in supporting browsers.
Finally, don't forget that you can sandbox an iframe in order to further isolate the framing document from the framed document.
I am sorting out a website that will be getting pen-tested soon, we've have been asked to add the X-Frame-Options header to our server configuration. When adding the following header it gives me an error message in the console.log where we are using iframes
-- nginx header --
add_header 'X-Frame-Options' "SAMEORIGIN";
-- Error --
`Refused to display 'https://api.domain.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
Obviously I understand the security reasons for this header but our website has an iframe that we simply cannot change & it is on a different domain e.g oldapp.domain.com rather than api.domain.com.
I would have used the ALLOW-FROM uri directive to allow from this other domain, but this directive is no longer recommended, is there an alternative to ALLOW-FROM uri that will enable me to simply add a domain that can be allowed to display iframe content?
For all browsers except some older ones (like IE) you should use Content-Security-Policy with the frame-ancestors directive instead. With CSP frame-ancestors you can use wildcards *.domain.com or multiple sources "oldapp.domain.com api.domain.com www.domain.com".
X-Frame-Options ALLOW-FROM only accepts one uri, you will likely have to dynamically set the uri from a list of allowed hostnames based on the incoming request. Alternatively you can set the value to SAMEORIGIN if you don't need to fully support IE and other outdated browsers as X-Frame-Options will be disregarded if CSP frame-ancestors is present.
I am working on addition of Content-Security-Policy-Report-Only header to my company's website. While I was researching on it, I found that a few of the pages already have Content-Security-Policy header set.
I investigated further and found that the directives are not required. Also, default directive used for those pages is 'self' whereas what I am planning to set for report-only is 'https:'
I am not an expert in this area and want to make sure that both header values don't interfere. Hence looking for guidance
If I set report-only for the pages that already has CSP header, is it going to interfere with existing headers? Is the behavior browser dependent?
Any help/pointers will be helpful in deciding.
Thanks!
Content-Security-Policy and Content-Security-Policy-Report-Only have no effect on each other and are entirely independent. Setting both is a common practice when tightening policies. I wouldn't doubt that there has been a bug around this behavior at some point, but the spec is clear.
From Section 5 of the CSP2 Spec
A server MAY cause user agents to monitor one policy while enforcing another policy by returning both Content-Security-Policy and Content-Security-Policy-Report-Only header fields. For example, if a server operator may wish to enforce one policy but experiment with a stricter policy, she can monitor the stricter policy while enforcing the original policy. Once the server operator is satisfied that the stricter policy does not break the web application, the server operator can start enforcing the stricter policy.
Based on the link here, server must not send both headers in the same request.
Here is the original text: A server MUST NOT provide Content-Security-Policy header field(s) and Content-Security-Policy-Report-Only header field(s) in the same HTTP response. If a client received both header fields in a response, it MUST discard all Content-Security-Policy-Report-Only header fields and MUST enforce the Content-Security-Policy header field.
I originally had this in my CSP header: default-src 'self';, which limits sources to only my domain, but it says nothing about the scheme/protocol. From what I can gather, this will allow sources to be loaded over http if the page itself was loaded over http. I'm using HSTS and CDN redirects to try to keep all traffic on https, but I want to cover this case off anyway. (In truth, I'm trying to make this header checker give me all green ticks.) Edit: srcclr will happily give all green ticks when using 'self'. I just had to fix some typos.
Anyway, I tried changing the CSP directive to be default-src https: 'self';, but it would seem that adding the scheme allows resources to be loaded from any domain, as long as it's over https. I.e, if either of the rules (https or 'self') matches, then the request is allowed. I tested this by playing around with URLs in the chrome dev tools.
Is there a way to indicate:
All resources should be loaded over https; AND
Resources should only come from the original domain?
Something like default-src https://'self';, but I don't think that's valid, is it?
One solution is to hardcode the domain name, but I'd like to use 'self' if it's possible.
According to https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives, the 'self' content source keyword:
Refers to the origin from which the protected document is being served, including the same URL scheme and port number.
If you serve the web page over https, then self only allow https request to the same domain.
The CSP2 specification http://www.w3.org/TR/CSP2/#match-source-expression says the same thing:
If the source expression is a case insensitive match for 'self' (including the quotation marks), then:
Return does match if the origin of url matches the origin of protected resource’s URL.