I'm talking about MAGECART! Or, more generally, credit card skimming: https://www.computerworlduk.com/security/magecart-who-what-is-behind-british-airways-attack-3683768/ … This works as follows: 1. Attacker compromises the site 2. Attacker injects JavaScript into the site 3. JavaScript listens for and send credit card details to attacker /2
-
Show this thread
-
So, HOW DOES THIS HAPPEN?! Well, it seems to happen one of two ways: 1. The server gets owned, or 2. The administrative control panel of the application (such as Magento) gets owned From there, JS insertion is trivial. /3
1 reply 1 retweet 1 likeShow this thread -
Now, ONTO THE PROBLEM! We, as systems administrators, have little / no visibility* to what happens within the browser. So, 1. We get hacked, and, 2. We don't know about it. So, these hacks can persist for months! /4 *except this changed recently
1 reply 0 retweets 0 likesShow this thread -
HOWEVER! Recently this changed. WE CAN TELL THE BROWSER WHATS ACCEPTABLE! We do this by defining a "policy" for the website to follow. This is called "Content Security Policy" or CSP /5
1 reply 2 retweets 1 likeShow this thread -
CSP allows us to define a bunch of things that our website should do, like: 1. Only accept JavaScript from one domain (default-src, script-src) 2. Only allow in-page connections to a specific set of domains (connect-src) /6
1 reply 0 retweets 0 likesShow this thread -
CSP will prevent the website doing things that we, as web administrators, say "nope this is bad don't do this". It'll even tell us when it's doing it! (via the report-uri) THIS IS AMAZING! /7
2 replies 1 retweet 2 likesShow this thread -
Replying to @andrewhowdencom
I'm asking this question as I'm not familiar with CSP. But couldn't the atracker change the CSP or simply remove it from the header? When he has access to the server or the distributor that sounds like an easy thing to do.
1 reply 0 retweets 0 likes -
Replying to @trickser26
Yes! This is an excellent point. There are a couple of ways to handle this; 1. Define the header in the webserver. This means that we have the additional security boundary of a Linux user, increases attacker cost... /1
1 reply 0 retweets 0 likes -
Replying to @andrewhowdencom @trickser26
2. Implement it in the application, but in a way that's not trivial to override. In the case of 2, it's likely the attacker will be able to drop the CSP. You could set some sort of static analysis on the site to ensure CSP is present -- but it's a "turtles all the way down" /2
1 reply 0 retweets 1 like -
Replying to @andrewhowdencom @trickser26
What would probably be ideal is some sort of "expiry" property of the CSP, such as that which is found on HSTS. cc
@ericlaw -- do you know if there's a way to set a "persistent" CSP?2 replies 0 retweets 1 like
As I said before, CSP doesn't help when a bad guy gets root on your server. It just doesn't. But the thing you're asking about is Origin Policy. (Which also doesn't. But it's closer.)
-
-
Replying to @ericlaw @trickser26
This is dope AF! I didn't know this was a thing before. TIL! https://wicg.github.io/origin-policy/#manifest-file …
1 reply 0 retweets 1 like - 1 more reply
New conversation -
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.