-
Notifications
You must be signed in to change notification settings - Fork 83
Scripts only in <head> #395
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
What about dynamic insertion? |
Similar to how Not that I use dynamic insertion (can I haz options to block all the things plz - where I'll probably be the only person in the world do that). |
Also, what about injecting |
Similar to And while most XSS issues should be covered by CSP as normal; an attacker might be able to create a bypass in the form of repeating a That said, an attacker adding an e.g. I'm hesitant to suggest same-origin iframes will have to have scripts in their Any suggestions? if not, it's probably best closing this. |
I have a limited understanding of all of this, but to me it looks like this is something that trusted types could restrict. Am I wrong? |
@Malvoz, not really, CSP is about the content that can be loaded; whereas Trusted Types limits the JavaScript methods/APIs that it can used after it has been loaded (e.g. it restricts the use of innerHTML). |
XSS in the <head> is a thing (the title tag was a common vector for a while, and DOMXSS still happens there), but assuming your <head> is perfect could you close out your head with a CSP of |
Good thinking @dveditz, I can set a normal CSP header, then just after the last valid If I do have an XSS in the body, it means attackers can't add any
|
This technique doesn't work for MS Edge 17.17134 (and maybe earlier) when using normal "text/html". The CSP3 spec says "policies in Interestingly, this technique works in Edge when using "application/xhtml+xml". It will also continue to work if you change to "text/html" and press the Refresh button - as Edge will continue to use the XML parser (more info). And as a second Edge 17 bug, when adding this I will now skip this |
@craigfrancis What if you insert the |
That's interesting @briansmith, adding it dynamically in MS Edge 17, inline scripts that followed it are now blocked - good; but external scripts are still allowed (most of the time) - not good, but at least all the legitimate scripts still work. When I say "most of the time", if the evil XSS:
So your approach can be used for all browsers (while Edge 17 is wrong, at least it no longer blocks all JavaScript). But from a purist point of view, it does introduce inline JavaScript (I don't want to put this in an external file, as I want to load all my JavaScript asynchronously, for performance reasons). Test Script:
Results for
Results for
Results for
In this last one, note how the order is wrong, the external files are listed first. |
Taking some ideas from #392, and from the old/dead
<plaintext>
tag...Considering most XSS exploits are found in the
<body>
(where most dynamic content is), and because websites can put all of their<script>
tags in the<head>
(ideally as async or defer), I would like to tell the browser that no<script>
tag will be found after the<body>
has started.As an aside, the
<body>
is optional, so it's started even if the tag does not exist in the document.The text was updated successfully, but these errors were encountered: