5 ms·

> but tools like SRI and CSP stop these attacks dead in their tracks. this isn't... usually true. in the case of this attack, the Javascript was appended direc

> but tools like SRI and CSP stop these attacks dead in their tracks. this isn't... usually true. in the case of this attack, the Javascript was appended directly to a 'known good' library resource[1]. Typically CSP whitelists based on origin, which would make CSP ineffectual in this case. Also, websites like BA have advertising, and it's nearly impossible to run CSP with ads unless you use the `strict-dynamic` directive, which whitelists any javascript loaded by your javascript recursively... including this javascript[2]. There are other, more uncommon modes for CSP which you might be referring to: 1. Nonce, which provides protection by ensuring each script has a server-calculated one-time-use token. This would not have any effect, as the script is part of one naturally loaded by the server. 2. Hash[2], which provides protection by checking the script's content against a predetermined hash. This possibly could be effective, but in practice rarely is. If the attackers could edit this script, there's absolutely no reason to believe either (1) this just updates the generated hash or (2) the attackers cant just update the hash. (this is essentially the same as SRI). Hash is potentially effective where taking advantage of a third-party CDN with known content that should not change, but by the look of the url: http://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js http://www.britishairways.com/cms/global/scripts/lib/moderni... the resource was not on a CDN. [1]: https://medium.com/asecuritysite-when-bob-met-alice/the-british-airways-hack-javascript-weakness-pin-pointed-through-time-lining-dd0c2dbc7b50 https://medium.com/asecuritysite-when-bob-met-alice/the-brit... [2]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

K0nserv 7y ago
From the reporting I've read, primarily by RiskIQ, in both the Ticketmaster and BA case it was not the origin servers that were compromised in which case SRI would have been effective in so far that it would have required the attackers to compromise the origin servers too at which point it's all game over anyway. So I would assert that SRI would have stopped both these attacks.
- zemnmez 7y ago
  i cant find any hits for "origin" or "CDN" on the original RiskIQ article: https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ https://www.riskiq.com/blog/labs/magecart-british-airways-br... the RiskIQ article identifies the location of the script as "the main website" additionally, I'm not sure how this would solve the problem. If BA went to all the effort of putting their frontend assets on a CDN, why wouldn't their HTML, with the hashes also be on the CDN? and if the hashes are not generated by the CDN, how does the server generate the hashes without being affected by changes on the CDN? regardless of outcome, if the process is automated, does a human being need to read a diff every time any file on any CDN changes? Can't an attacker then just wait until the hashes are automatically updated?
  - K0nserv 7y ago
    Sorry I should have been clearer here. RiskIQ doesn't distinguish between the CDN and origin in their write up. That's an assumption on my part, I believe it be the case that the CMS that serves the JS file is different from the origin server that would be serving the checkout pages and other parts of the BA website. From a quick Google it looks like the CMS path on BA is just a file storage server of some kind. Most likely the origin server had a hardcoded reference to the CMS path(https://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js https://www.britishairways.com/cms/global/scripts/lib/modern...) and if that had been done as <script type="text/javascript" src="https://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js" integrity="sha384-5XrDTQbmmgpJKmfKW8outDDdYpRCnIf+nxX2nVR10NyWby6pPcujAELgWVmCu2P/"></script> I speculate the attack would not have been successful. For an extremely static resource like this it wouldn't have been complex to adopt SRI.
chopin 7y ago
>Also, websites like BA have advertising Third-party advertising is a strict no-go on ecommerce sites imho. Anybody who does this should face the full 4% fine on the first offense. I hate sites where I am willing to purchase and which serve me ads with a passion.
sitkack 7y ago
Running ads was totally worth it.
xtomus 7y ago
There is absolutely no reason to be loading third party ad scripts on the payment gateway.

K0nserv 7y ago

From the reporting I've read, primarily by RiskIQ, in both the Ticketmaster and BA case it was not the origin servers that were compromised in which case SRI would have been effective in so far that it would have required the attackers to compromise the origin servers too at which point it's all game over anyway. So I would assert that SRI would have stopped both these attacks.

zemnmez 7y ago
i cant find any hits for "origin" or "CDN" on the original RiskIQ article: https://www.riskiq.com/blog/labs/magecart-british-airways-breach/ https://www.riskiq.com/blog/labs/magecart-british-airways-br... the RiskIQ article identifies the location of the script as "the main website" additionally, I'm not sure how this would solve the problem. If BA went to all the effort of putting their frontend assets on a CDN, why wouldn't their HTML, with the hashes also be on the CDN? and if the hashes are not generated by the CDN, how does the server generate the hashes without being affected by changes on the CDN? regardless of outcome, if the process is automated, does a human being need to read a diff every time any file on any CDN changes? Can't an attacker then just wait until the hashes are automatically updated?
- K0nserv 7y ago
  Sorry I should have been clearer here. RiskIQ doesn't distinguish between the CDN and origin in their write up. That's an assumption on my part, I believe it be the case that the CMS that serves the JS file is different from the origin server that would be serving the checkout pages and other parts of the BA website. From a quick Google it looks like the CMS path on BA is just a file storage server of some kind. Most likely the origin server had a hardcoded reference to the CMS path(https://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js https://www.britishairways.com/cms/global/scripts/lib/modern...) and if that had been done as <script type="text/javascript" src="https://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js" integrity="sha384-5XrDTQbmmgpJKmfKW8outDDdYpRCnIf+nxX2nVR10NyWby6pPcujAELgWVmCu2P/"></script> I speculate the attack would not have been successful. For an extremely static resource like this it wouldn't have been complex to adopt SRI.

chopin 7y ago

>Also, websites like BA have advertising Third-party advertising is a strict no-go on ecommerce sites imho. Anybody who does this should face the full 4% fine on the first offense. I hate sites where I am willing to purchase and which serve me ads with a passion.

sitkack 7y ago

Running ads was totally worth it.

xtomus 7y ago

There is absolutely no reason to be loading third party ad scripts on the payment gateway.