Quoting from here,
If a resource is delivered with a policy that includes a directive named frame-ancestors and whose disposition is "enforce", then the X-Frame-Options header will be ignored, per HTML’s processing model.
I don't understand the part that mentions 'disposition is "enforce"'. Can't find examples. Could someone shed some light on this?
According to https://w3c.github.io/webappsec-csp/#policy-disposition: 'Each policy has an associated disposition, which is either "enforce" or "report".' This corresponds to Content-Security-Policy and Content-Security-Policy-Report-Only, respectively. If you are using the "Report-Only" version of CSP, X-Frame-Options will not be ignored as you are not enforcing the overriding policy.
Related
Genuinely can't find a resolution to this issue anywhere. Currently trying to add multiple SHA256 hashes to a Content Security Policy, like so:
default-src 'self' 'sha256-UITiqbXyaWS7NpwiFrMIbdXAZy5EXLRUHkpylF4504k=' 'sha256-0EZqoz+oBhx7gF4nvY2bSqoGyy4zLjNF+SDQXGp/ZrY=';
However, doing this seems to make no difference and just returns:
Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self' 'sha256-UITiqbXyaWS7NpwiFrMIbdXAZy5EXLRUHkpylF4504k=' 'sha256-0EZqoz+oBhx7gF4nvY2bSqoGyy4zLjNF+SDQXGp/ZrY='
Any idea how to add multiple hashes to this policy?
Already attempted to add multiple hashes delimited by spaces in their own single quotations marks under standard default-src 'self' policy. Only works if there's one hash, but want to add several.
You policy syntax seems to be ok. I assume that the most likely reason for the behavior is:
Variations in the script code. Hashes will only work on static script code. If the code changes the hash will need to change, which means you will need to compute it dynamically and instert into CSP, move the variable out of script code or use a nonce.
Script event attributes such as "onClick". These can only be allowed with support for 'unsafe-hashes' in CSP level 3. Rewrite with an event handler.
Let us assume I have these header:
Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload
For purpose of writing regex, I need to know:
Are headers space sensitive? e.g. max-age=<expire-time> vs. Max-age=<expire-time>
Are they case-sensitive? e.g. max-age= <expire-time> vs. Max-age=<expire-time>
Are they order-sensitive? e.g. max-age=<expire-time>; preload vs. preload; max-age=<expire-time>;
The source for answering this kind of question is the standard - that's what standards are for. To cite from RFC 7230 section 3.2:
Each header field consists of a case-insensitive field name followed
by a colon (":"), optional leading whitespace, the field value, and
optional trailing whitespace.
As for the field values, this depends on the actual header. For examples in Set-Cookie the values are case-sensitive. For Strict-Transport-Security you have to look at the relevant standard. In RFC 6797 it says in section 6.1:
The order of appearance of directives is not significant.
...
Directive names are case-insensitive.
You should read the relative RFC specifications.
In general HTTP Header names are case insensitive and should not contain white space. HTTP/2 goes further and states that HTTP Header names should be lower case, and also white space there causes errors.
HTTP Header values can be case sensitive depending on the header. For the Strict-Transport-Security header your questions are covered in that RFC, specifically:
It is based on the Generic Grammar defined in Section 2 of [RFC2616] (which includes a notion of "implied linear whitespace", also known as "implied *LWS").
Which basically means white space is not important.
And then the HSTS RFC goes on to say:
The order of appearance of directives is not significant.
...
Directive names are case-insensitive.
I would like nginx to change its behavior based on a response header from a backend.
My backend (also nginx) returns a Foo header:
HTTP/1.1 200 OK
Server: nginx/1.15.5
Foo: true
If the Foo header is set, I would like to change the behavior.
If I use the following config, $sent_http_foo doesn't appear to be truthy and the header isn't set.
if ($sent_http_foo) {
add_header "Foo-Header-Set" "true";
}
However, if I use this config instead:
add_header "Foo-Header-Value" "$sent_http_foo";
I see the new header with true in my response.
Is it possible to use the $sent_http_* variables in this way?
This is quite an old mailing list but it is related to your question - Nginx mailing
In the mailing list you can read -
Both "set" and "if" directives you mentioned are executed before
a request is sent to upstream.
and at this point there is no foo header in the response....
"if" or "set" directives isn't going to work, and this is what
causes behavior you see.
Moreover, you can read further about If Is Evil
Directive if has problems when used in location context, in some cases it doesn’t do what you expect but something completely different instead. In some cases it even segfaults. It’s generally a good idea to avoid it if possible.
In conclusion - the way you do is totally fine:
add_header "Foo-Header-Value" "$sent_http_foo";
I need to set multiple 'set-cookie' headers in Shelf, but since headers is a Map<String,String>, setting the second one replaces the first and so on because keys are unique. How can I solve this in Dart?
There is an open feature request https://code.google.com/p/dart/issues/detail?id=18844 and also https://code.google.com/p/dart/issues/detail?id=18845
Here is an implementation https://github.com/wstrange/shelf_simple_session/blob/master/lib/src/cookie.dart
Is it possible to send a response with 302 status code to a url like this:
http://mysite.com/something/#somethingelse
Yes, you can use the fragment identifier. This was a known bug in the HTTP spec, fixed in subsequent revisions of the spec. See RFC 9110.
Following the HTTP specification, the value for the Location header field must be an absoluteURI value. And that is according to the RFC 3986 (they just changed the name from absoluteURI to absolute-URI):
absolute-URI = scheme ":" hier-part [ "?" query ]
So theoretically the fragment is not allowed as part of the value. But the browsers can handle it.
With strict reading RFC2616 does not allow fragments in Location header values, since they are not part of absolute URIs. However, with the IETF's HTTP rewrite draft this was fixed.
Recently Julian put up a comparison how browsers handle URI fragments (that's what the HTML anchor tags deal with) in the Location header: http://www.greenbytes.de/tech/tc2231/redirects.html
So the answer ist: Yes, you can put fragments in Location header URIs.
There appears to be no problem in doing so from PHP:
Header(
"Location: http://en.wikipedia.org/wiki/HTTP#Status_codes",
true,
302
);
Yes. It's the browser which doesn't send the hash to the server, not the other way around.
While the original RFC 2616 allowed only absoluteURI in the Location header, as the other (older) answers explain, the current RFC 7231 allows any URI-reference, either a full URI (with fragment possibly included), or even a relative URI, resolved against the current effective URI. And it even explicitly describes the behavior of fragments during redirection (if the Location header includes the fragment, it is used, if not, the original fragment is inherited and applied after the redirection).
I.e. yes, you can, it is even officially standardized now.