CSP has frame-src, child-src and frame-ancestors.
frame-src is deprecated in favor of child-src.
child-src and frame-ancestors are for iframes as part of CSP 2.
So I simply want to say iframes are only allowed for origin.
frame-src ‘self’; child-src ‘self’; frame-ancestors ‘self’
so what’s the difference between child-src and frame-ancestors ?
presumable a browser supporting CSP2 takes child-src over frame-src?
Related
I have an admin panel, I would like to permit only browsers without any extension/addon.
I tried setting stringent csp policy
content-security-policy:
script-src 'nonce-xxx' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'self';
block-all-mixed-content;
but it seems that Chrome addons can bypass it.
I'm trying to build a CSP policy that looks like following:
Content-Security-Policy: "default-src 'self'; script-src 'self' https://*.example.com; object-src 'none'; style-src 'self'; img-src 'self' 'unsafe-inline'; media-src 'self'; frame-src 'self' https://*.example.com; font-src 'self'; connect-src *"
If you noticed everything is normal except for connect-src *.
We need to implement this as we are seeing scaling issues as we onboard new services which requires different endpoints to connect to. I want to understand what the security threats are if we allow connections to everything but restrict other derivates.
The connect-src directive covers interfaces:
<a> ping
fetch
XMLHttpRequest()
sendBeacon()
WebSocket
EventSource
The "what security threats are if we allow connections to everything" depends on how do you use on the page the things which you are get via connect.
even if I'm allowing connections to everything, but I've set script-src to self, does that mean it'll allow connections to everything but script will be restricted to self?
No. The script-src directive covers only sources for script loading/execution. script-src 'self' means that is allowed to load external scripts from the same scheme:/domain:port_number from where the page itself was loaded.
Fithermore, nothing prevents you from loading the script using XMLHTTPRequest from any source (because of connect-src *) and execute it.
What do frame-src and frame-ancestors do exactly? The definition shows the purpose is the same to define valid contents for frames for both directives.
When to use which one? I was able to load an external domain content in iframe using -
frame-ancestors and default-src rules
frame-src
Both are working but couldn't get correct use cases.
default-src, frame-ancestors, and frame-src are all part of the Content-Security-Policy response header.
frame-src
Restricts what domains and page can load 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>.
For example: If the website at https://example.com has a response header of Content-Security-Policy: frame-src 'self', it can only load https://example.com inside iframes.
frame-ancestors
Restricts what domains and page can be loaded in from an iframe (similar to the X-Frame-Options header, but takes precedence over it).
The HTTP Content-Security-Policy (CSP) frame-ancestors directive specifies valid parents that may embed a page using <frame>, <iframe>, <object>, <embed>, or <applet>.
For example: If the website at https://example.com has a response header of Content-Security-Policy: frame-ancestors 'self', it can only be loaded inside iframes from https://example.com.
default-src
Acts as the default value for any fetch directive that isn't explicitly set (here is a list of all fetch directives)
The HTTP Content-Security-Policy (CSP) default-src directive serves as a fallback for the other CSP fetch directives. For each of the following directives that are absent, the user agent will look for the default-src directive and will use this value for it.
For example: Content-Security-Policy: default-src 'self' will default to the value 'self' for all fetch directives. Other directives will be unaffected.
Note: since frame-ancestors is not a fetch directive, setting default-src won't restrict it. It needs to be set separately.
For some reason both Mozilla Observatory and CSP validator are not detecting the CSP header in my .htaccess file yet the header is visible when viewed through Chrome.
Here's my current CSP header in my .htaccess file;
Content-Security-Policy: script-src 'nonce-$RANDOM' 'strict-dynamic' 'unsafe-inline' object-src 'none'; base-uri 'none'; report-uri https://altfit.report-uri.com/r/d/csp/enforce;
Also I noticed that the nonce is not working, inline scripts still load without nonce in place but if I make modifications to the CSP it can restrict script execution and the display of inline elements.
Info:
Server is Light Speed.
PHP version is 7.1
Fixed the issue by modifying the line in .htaccess to the following;
Header set Content-Security-Policy: "default-src https: 'unsafe-inline'; report-uri https://altfitcom.report-uri.com/r/d/csp/enforce;"
Only issue now is the addition of unsafe-inline but from what I have read strict-dynamic and nonce do not work as a cross platform solution and I have to have inline js for some onclick events.
We're currently introducing the Content Security Policy to a website. Started by inserting the Content-Security-Policy-Report-Only header to get some feedback about the impact. Soon we found out that the Evernote Web Clipper plugin in the Safari browser violates the CSP directives as it seems to inject some code into the page.
We get this in the CSP report:
{"csp-report":
{
"document-uri":"http://example.com/index.html",
"violated-directive":"default-src 'self'",
"original-policy":"default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; report-uri http://example.com/report.html",
"blocked-uri":"safari-extension://com.evernote.safari.clipper-uahs7eh2ja",
"source-file":"http://example.com/js/jquery.js",
"line-number":2
}
}
How do we need to modify the CSP header so that the Evernote Web Clipper plugin is not blocked? The blocked-uri seems to contain a user-specific id at the end which makes it pretty difficult.
You're right, the last bit of the blocked uri does vary across computers, and you can't use a wildcard to whitelist it. The only way to unblock the Web Clipper is to unblock all Safari extensions by putting safari-extension://* in default-src, so your policy would look like
default-src 'self' safari-extension://*; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; report-uri http://example.com/report.html