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.
I added a new rule for deny all the external requests to 'actuator' .(spring endpoints) as following:
The rule works as expected until I am using partial decode URL like:
<host>/%61ctuator
Do you know any way or a better to define a rule like that that block encoded URLs as well?
Cloud Armor recently released additional operator functionality that will allow for URL decoding of attributes within a given CEL rule match.
For example:
request.path.lower().urlDecode().contains("/actuator")
I setup a simple nodejs http-server that stream-processes an html request. As the html is streamed, it extracts any inline content into a seperate element and calculates its hashes.
In the final step, a trailer-header is send containing the original csp + the new hashes. (This is the only csp send, it is combined in the server!)
However, the browser (all: Chrome, Firefox, Edge) does not honour the csp!
(According to canIuse all of these browsers support trailer-headers though.)
The above in pseudo-code (node-js like):
const server = http.createServer((reqest, response) => {
response.setHeader('Transfer-Encoding', 'chunked');
response.setHeader('content-type', 'text/html');
response.setHeader('Trailer', 'content-security-policy');
const stream = getHTMLSAXStream();
stream.on('data', function(element) {
// extract inlines and save, e.g. styles.push(element.style);
// then remove the attr: e.g. element.style = undefined;
// then on the stripped html: e.g. response.write(element.toHTML())
});
stream.on('end', function() {
const stylefile= `${styles.join("\n")}`;
const url = getUrlForString(stylefile); // make this file available on a temporary url
response.write(`<link rel="stylesheet" href="${url}">`)
response.addTrailers({ 'content-security-policy': mergeWithDefaultCSP("style-src: sha256-${sha256(stylefile)}") });
response.end(); // send response
})
As per MDN docs on trailers some headers are disallowed, however couldn't find a reason why the content-security-policy shouldn't be allowed.
More specifically, as per trailer header and csp spec:
A sender MUST NOT generate a trailer that contains a field necessary
for message framing (e.g., Transfer-Encoding and Content-Length),
routing (e.g., Host), request modifiers (e.g., controls and
conditionals in Section 5 of [RFC7231]), authentication (e.g., see
[RFC7235] and [RFC6265]), response control data (e.g., see Section 7.1
of [RFC7231]), or determining how to process the payload (e.g.,
Content-Encoding, Content-Type, Content-Range, and Trailer).
The CSP is not used for message framing, it is not used for routing, it is not used as a request modifier, not used for authentication and isn't used for processing the payload (only used after processing the payload, aka the html) - in short, I don't see a reason it shouldn't work!
Does anyone know more? Have I missed anything?
To get around this, currently I'm using the following workaround (I'd like to get rid of):
don't use hashes, whitelist by domain (e.g. all scripts are coming from the same domain)
use nounces instead of hashes (won't play well with cdns though)
More on the background, why am I doing this at all:
I have a cms that allows using raw html (incl. inline-styles and script tags) which I frequently use (else I'd need to deploy again, etc etc). On the other hand I'd like a good working CSP (e.g. when user-generated comments are loaded onto the page from an api with javascript (not in the backend, that would defeat the purpose!), just in case. Therefore I'd like to allow only my own inline-style and script tags, but no-others. The above addresses this adequatly.
No matter what the spec says, it’s up to browsers to support this and last I header browser support for trailing headers is very limited: Do any browsers support trailers sent in chunked encoding responses?
Additionally I don’t think it makes sense for CSP for two reasons:
HTML is often streamed (as you state you are doing) and the browser will render as the HTML comes in. To then retrospectively apply the CSP to already rendered content would be pointless - the damage has been done.
Multiple CSPs are additive and not replacing. I.e. it the most restrictive CSP that matters. So if you’ve a basic CSP and then want to add a nonce that is not possible AFAIK.
A.S/ probably for another SE.com site: why "referer" is spelt with only r at Google's?
Anyway, here we go again with another occurrence of RefererNotAllowedMapError.
I couldn't find my answer in the existing Q&As.
Hypothesis:
I have a local website that includes a GMap.
It displays and works
fine provided I remove all restrictions on that key, from the Google
API console.
But the browser will receive a Google Maps JavaScript
API error: RefererNotAllowedMapError whenever I add a referrer
restriction, which seems to match the refering URL.
The referrer, where the map is being called form, is:
https://app.developr.online.local/projects?p=name-asc-0-20-1&a=createProject
Below is my GAPI KEY security configuration:
Below is the corresponding console output:
To be noted:
If I add a trailing asterisk when declaring the referer, validating that entry will clear it anyway. To me it means: "that's ok, we're covering trailing /* already.".
My question: what pattern should I enter as a referrer (2 r's) to have it recognised by GAPI security layer?
I've tried a few things, I didn't get a cigar.
Thank you.
I need to allow the user to submit queries as follows;
/search/"my search string"
but it's failing because of request validation, as outlined in the following 2 questions:
How to include quote characters as a route parameter? Getting "Illegal characters in path" message
How to modify request validation?
I'm currently trying to figure out how to disable request validation for the quote character, but i'd like to know the risks before I actually put the site live with this disabled? I will not disable the request validation unless I can only disable it for the quote character, so I do intend to disallow every other character that's currently not allowed.
According to the URI generic syntax specification (RFC 2396), the double-quote character is explicitly excluded and must be escaped (i.e. %22). See section 2.4.3. The reason given in the spec:
The angle-bracket "<" and ">" and double-quote (") characters are excluded because they are often used as the delimiters around URI in text documents and protocol fields.
You can see easily why this is the case -- imagine trying to create a link in HTML to your URL:
<a href="http://somesite/search/"my search string""/>
That would fail HTML parsing (and also breaks SO's syntax highlighting). You also would have trouble doing basic things with the URL like emailing it to someone (the email client wouldn't parse the URL correctly), posting it on a message board, sending it in an instant message, etc.
For what it's worth, spaces are also explicitly excluded (same section of the RFC explains why).