CSP will not prevent or mitigate this attack and it should not be advertised this way.
-
-
That is completely fair and true but nevertheless I still think it’s worthwhile evangelizing even a poor protection if it pushes people to implementing strong and restrictive CSP policies.
-
Sadly people don’t believe in defense in depth, and lean towards the “if it does not solve everything it solves nothing” approach.
-
A difference between defense in depth and false security. A firewall and server-side code sandboxing are defense in depth..they handle orthogonal issues. That is different than conveying that something mitigates (even a little bit) something that it does not.
-
I see policies that limit external access to unintended 3rd parties as a defense. Granted not perfect...
-
It is fine so long as it actually addresses a concern one can define. The thing here is that we are talking about exfiltration and it does not address that at all (there is no situation..however contrived..where we can’t exfil using some other way).
-
CSP may not be intended to work in the face of an RCE but what is the purpose of form-action besides limiting data exfiltration from an HTML injection? I guess it can keep you from accidentally making a form that submits via http?
-
HTML injection != arbitrary JS running…which was what was the basis of the original discussion.
-
Sure but the things that the CSP Analyzer is looking at are checking the same thing (restrictive default-src, setting form-action, etc.) regardless. Doing it for the wrong reason still protects you regardless of the motivations.
- 11 more replies
New conversation -
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.