5 ms·

How would SRI and CSP help in this case? Wasn’t the compromised script served from their own infrastructure? And if hackers had access to that, why wouldn’t the

How would SRI and CSP help in this case? Wasn’t the compromised script served from their own infrastructure? And if hackers had access to that, why wouldn’t they they be able to change the SRI and CSP too?

K0nserv 7y ago
In this specific case the attackers seems to have compromised a CMS which for some reason was used to serve javascript libraries. It’s likely that they did not compromise the origin itself, only the CMS. Thus using SRI on the origin would have prevented or at least drastically complicated the attack. As a general pattern CSP and SRI are very effective protection against CDN compromises and XSS. With CSP and SRI the stack surface is reduced significantly.
- zemnmez 7y ago
  the URI: http://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js http://www.britishairways.com/cms/global/scripts/lib/moderni... doesn't look like its on a CDN
  - K0nserv 7y ago
    It looks like a CMS that is being repurposed as a CDN. I would bet the path https://www.britishairways.com/cms/ https://www.britishairways.com/cms/ resolves via a gateway to a different set of servers than the main BA site. So for all intents and purposes it’s a CDN
throw0101a 7y ago
Depending on one's paranoia level, you could have a monitoring script on independent (third-party?) infrastructure that fetches pages and goes through them checking resource hashes. If the SRI hash listed in the origin, or the actual hash of the resource, changes, you get an alert. If an update was not pushed, then you know something hinky is going on. Some folks regularly check the signature of their SSL certs, and monitor certificate transparency logs. It just depends on how vigilant one wants to be.
elf337 7y ago
Whilst CSP wouldn't have stopped the modified script from loading it would have stopped the AJAX call to the attacker-controlled domain and thus would have been rendered impotent. Whilst it is very worrying that a bad actor was able to get their malicious script served up by a BA server, even if it was only acting as a proxy for a CDN, I suspect that the reality is (or at least should be) that this is much easier than changing the headers sent by that server (and hence the CSP) and that access to one does not imply access to the other

K0nserv 7y ago

In this specific case the attackers seems to have compromised a CMS which for some reason was used to serve javascript libraries. It’s likely that they did not compromise the origin itself, only the CMS. Thus using SRI on the origin would have prevented or at least drastically complicated the attack. As a general pattern CSP and SRI are very effective protection against CDN compromises and XSS. With CSP and SRI the stack surface is reduced significantly.

zemnmez 7y ago
the URI: http://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2.min.js http://www.britishairways.com/cms/global/scripts/lib/moderni... doesn't look like its on a CDN
- K0nserv 7y ago
  It looks like a CMS that is being repurposed as a CDN. I would bet the path https://www.britishairways.com/cms/ https://www.britishairways.com/cms/ resolves via a gateway to a different set of servers than the main BA site. So for all intents and purposes it’s a CDN

throw0101a 7y ago

Depending on one's paranoia level, you could have a monitoring script on independent (third-party?) infrastructure that fetches pages and goes through them checking resource hashes. If the SRI hash listed in the origin, or the actual hash of the resource, changes, you get an alert. If an update was not pushed, then you know something hinky is going on. Some folks regularly check the signature of their SSL certs, and monitor certificate transparency logs. It just depends on how vigilant one wants to be.

elf337 7y ago

Whilst CSP wouldn't have stopped the modified script from loading it would have stopped the AJAX call to the attacker-controlled domain and thus would have been rendered impotent. Whilst it is very worrying that a bad actor was able to get their malicious script served up by a BA server, even if it was only acting as a proxy for a CDN, I suspect that the reality is (or at least should be) that this is much easier than changing the headers sent by that server (and hence the CSP) and that access to one does not imply access to the other