Login form is blocked by CSP and I don't understand why
Chrome Version 94.0.4606.61
Error message :
Refused to send form data to
'https://subdomain.mydomain.com/login/local' because it
violates the following Content Security Policy directive: "form-action
'self' https: *.mydomain.com".
No problem with firefox
This is because during login you perform a redirect through the host-source whose is not allowed in the form-action directive (the port, the scheme, domain/subdomain name does not match).
When redirecting, the CSP checks the entire chain of sources, but browsers have differences in the behavior of form-action for redirects:
Chrome/Safari consider a redirect when submitting a form to be potentially dangerous, since sensitive user data can be redirected to an attacker's domain. Therefore, they block redirection if host-source (domain) not allowed in the form-actions are participate in the chain of redirects.
Firefox believes that the server redirect is under the control of the owner of the page protected in CSP. Therefore, during redirect it allows you to send the form during redirect even to third-party domains.
Note 1. 'self' means exact scheme://domain:port from the Url in the address bar. Therefore CSP:
form-action 'self' https: *.mydomain.com
In case Url is HTTPS://subdomain.mydomain.com the above CSP is become form-action HTTPS://subdomain.mydomain.com https: HTTPS://*.mydomain.com whis is equal to form-action https: - it allows anything except http:-Urls.
In case Url is HTTP://subdomain.mydomain.com, the above CSP is become form-action HTTP://subdomain.mydomain.com https: HTTP://*.mydomain.com and it does not allow a main domain mydomain.com.
Note 2. The Url https://subdomain.mydomain.com/login/local in the message:
Refused to send form data to 'https://subdomain.mydomain.com/login/local' because it violates ...`
is not Url really blocked by Chrome. This is just the first Url in the redirect chain.
Note 3. If CSP, after all, blocks the allowed domain, it is most likely that it's interference of browser extensions such as NoScript/uBlock/AdBlock/PrivacyBadger, etc. interfere.
Related
I have a site that is loaded over secure connection (https://). I have a href to http:// that downloads a file. I want to use the mixed content solution here(I know I should do https:// but for now I want to use http://). So for the fix I added <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> to the head. For some reason I still get the Mixed Content error in google chrome. My current chrome version is 88.
From MDN:
The HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive instructs user agents to treat all of a site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS).
That directive does not allow mixed content. It just treats all http: links as if they were https: links (e.g. if a link which points to http://google.com/ is clicked, the browser navigates to https://google.com/). The only ways (AFAIK) to allow mixed content are to either:
serve your content via plain HTTP, or
allow mixed content manually in the site's settings.
I have this project which is an HTML page and wanted to load an HTTPS URL by iframe, How can I do so?
I get this error:
Refused to frame 'https://www.google.com/' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'frame-src' was not explicitly set, so 'default-src' is used as a fallback.
any help would be much appreciated.
Sounds like you have a Content Security Policy defined for your app.
You need to add frame-src: https://www.google.com to the CSP header to allow iframes with that domain.
Since you have not defined a frame-src in the header, it is falling back to default-src, which doesn't specify the domain either, so it gets blocked.
I am implementing an OpenID Connect client web application. After the user is successfully authenticated in the identity provider, they are redirected back over to my web application. Once they arrive, depending on the value of some query parameters they are redirected to a URL. When the redirection occurs Chrome throws this error in the console:
Refused to send form data to 'https://my-domain-a.com/' because it violates the following Content Security Policy directive: "form-action 'self' https://my-domain-b.com/receive-token".
After some googling I tried adding a Content-Security-Policy header as:
content-security-policy: form-action 'self' https://my-domain-a.com
This does not seem to have any affect and I still receive this message.
I have 2 questions:
How do I fix this?
Why is Chrome throwing this error off of a 301 redirect?
After much googling (and profanity) I figured out why this is happening, as well as an (ugly) fix.
During my experiments, I noticed that all Chromium browser descendants (Chromium, Chrome, and Vivaldi) had this issue. Non-Chromium browser descendants (Firefox and Safari) did not. As it turns out, the identity provider was setting a content security policy directive of: form-action 'self' https://my-domain-b.com/receive-token. Since my browser was getting redirected from the identity provider to my-domain-b.com to my-domain-a.com the Chromium descendants flagged the redirect from my-domain-b.com to my-domain-a.com as violating the content security policy set by the identity provider. I unfortunately don't know the spec well enough to say which of the 2 behaviors exhibited by the different browsers is the most correct...
I fixed this issue by doing a somewhat ugly hack. Rather than doing a 301 redirect from my-domain-b.com to my-domain-a.com, I instead had my-domain-b.com render a simple HTML page that immediately submitted to my-domain-a.com:
<html><body onload="window.location='https://my-domain-a.com?my_param=my_value'"/></html>
This solution satisfied the Chromium descendants since there was no longer a redirect to an unrecognized domain. In my case relying on Javascript is acceptable as the site the user is redirected to is an Angular app, so the user must have Javascript enabled.
I am trying to load a simple iframe into one of my web pages but it is not displaying. I am getting this error in Chrome:
Refused to display 'https://cw.na1.hgncloud.com/crossmatch/index.do' in a frame because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self' https://cw.na1.hgncloud.com".
Invalid 'X-Frame-Options' header encountered when loading 'https://cw.na1.hgncloud.com/crossmatch/index.do': 'ALLOW-FROM https://cw.na1.hgncloud.com' is not a recognized directive. The header will be ignored.
This is the code for my iframe:
<p><iframe src="https://cw.na1.hgncloud.com/crossmatch/" width="680" height="500" frameborder="0"></iframe></p>
I am not really sure what that means. I have loaded plenty iframes before and never received such errors.
Any ideas?
It means that the http server at cw.na1.hgncloud.com send some http headers to tell web browsers like Chrome to allow iframe loading of that page (https://cw.na1.hgncloud.com/crossmatch/) only from a page hosted on the same domain (cw.na1.hgncloud.com) :
Content-Security-Policy: frame-ancestors 'self' https://cw.na1.hgncloud.com
X-Frame-Options: ALLOW-FROM https://cw.na1.hgncloud.com
You should read that :
https://developer.mozilla.org/en-US/docs/Web/Security/CSP
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
The reason for the error is that the host server for https://cw.na1.hgncloud.com has provided some HTTP headers to protect the document. One of which is that the frame ancestors must be from the same domain as the original content. It seems you are attempting to put the iframe at a domain location that is not the same as the content of the iframe - thus violating the Content Security Policy that the host has set.
Check out this link on Content Security Policy for more details.
For any of you calling back to the same server for your IFRAME, pass this simple header inside the IFRAME page:
Content-Security-Policy: frame-ancestors 'self'
Or, add this to your web server's CSP configuration.
In my case it was that the site i was embedding had a specific url for embedding content and a different url for sharing
the url i had set in the iframe was
https://site/share/2432423232
changing it to
https://site/embed/2432423232
worked for me
The same issue appears to me, don't open the page in a private window.
You can use multiple browsers if you need to log in with different users.
I know that this may be just me being stupid, but in a Chrome tab that has a page loaded with a URL which begins with chrome-extension://, can the scripts be online or use eval();? I know that browser or page actin oopups or app windows can't use it. Part of my extension opens a normal new tab with a page which uses eval();.
All pages running at the chrome-extension:// origin are subject to a default content security policy described here, specifically:
script-src 'self'; object-src 'self'
A popup is considered such a page, too, as is the invisible background page. If you open a file from your extension, it will be subject to it too.
You can either:
Relax (or tighten) the default policy for all pages with your manifest:
"content_security_policy": "[POLICY STRING GOES HERE]"
This way you can allow eval and friends by adding 'unsafe-eval' to script-src.
You can also allow loading external scripts by adding their origin to the policy; however, only HTTPS origins are allowed for MitM protection reasons.
However, it's important to remember that 'unsafe-inline' will be ignored regardless of your custom policy.
Relax (or tighten) the default policy for a specific page by declaring it sandboxed.
"sandbox": {
"pages": [
"page1.html",
"directory/page2.html"
]
// content_security_policy is optional.
"content_security_policy":
"sandbox allow-scripts; script-src https://www.google.com"
],
Sandboxed CSP can be more permissive, but still there are a couple of restrictions.
The price of sandboxing is losing access to Chrome API. The sandboxed script has to communicate via DOM messages with some privileged pages to do privileged things.
There's a guide in the documentation, "Using eval in Chrome Extensions. Safely."
For Apps, the situation is a bit different. Again, a default (and more restrictive) CSP applies, but you cannot modify it in the manifest.
Sandboxing approach still works, though.
To use eval, look at the policy "unsafe-eval" in https://developer.chrome.com/extensions/contentSecurityPolicy