4 ms·

If you're responsible for a website that collects payment details or other sensitive information you need to stop what you're doing right now and create a job t

If you're responsible for a website that collects payment details or other sensitive information you need to stop what you're doing right now and create a job that downloads all the JS libraries on your site and diffs it against a known "clean" copy. Run that job daily/hourly as your level of exposure demands and have it reviewed by someone who knows Javascript at a deep level. Yes, that sucks and isn't fun, but this isn't going away and these guys are good at what they do. Next step is versioning of JS libraries, which enables you to utilize SRI, and then look at implementing CSP. You can lock this down, but it'll likely require a lot of buy in from people across the enterprise. The diffing job requires none. CSP and SRI info: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

onli 8y ago
Isn't that the wrong approach? That's not something to do hourly, that's something you do once when deploying the site, and then again when you update the libraries. Which you host locally. If the code on your site happens to change every hour there is no way you have a chance to assure security.
- Vendan 8y ago
  I think they are saying, "diff your release branch against what's live", in the hopes of catching "someone hacked your server and changed your JS" early.
  - strictnein 8y ago
    Your release branch wouldn't have any 3rd party JS, so diffing it vs the live stuff would catch a BA style attack, but not a TicketMaster style attack, which is more prevalent.
- strictnein 8y ago
  BA had a file they hosted compromised through their CMS. Many, many websites have 3rd party JS that updates at will. Only doing the check when you do a deployment wouldn't catch either one.
  - onli 8y ago
    You're right, with that perspective an hourly check to compare that what is online mirrors what is supposed to be online is a good additional defense.
- ilikehurdles 8y ago
  If you're using a third party cdn to serve js assets then you have no chance to assure security.
  - thaumasiotes 8y ago
    Not quite true; you can set a Content-Security-Policy header which whitelists scripts by their cryptographic hash. Assuming you know the exact contents of the script you want to run (which you should, if the only issue is that you're using a CDN), this should be fine. Just set the header yourself. If you're letting third parties load arbitrary code on your site, that's harder to deal with. Then a compromise of them is likely to also be a compromise of you.
  - dotancohen 8y ago
    If you're using a third party CDN to serve Javascript assets on a page that requests users to enter sensitive information, such as credit card details, then you are DOING IT WRONG. Seriously, do the devs not realize that "cloud" means "somebody else's computer" and using "cloud assets" on your payment pages means somebody else is deciding what Javascript to run on your payment pages?

onli 8y ago

Isn't that the wrong approach? That's not something to do hourly, that's something you do once when deploying the site, and then again when you update the libraries. Which you host locally. If the code on your site happens to change every hour there is no way you have a chance to assure security.

Vendan 8y ago
I think they are saying, "diff your release branch against what's live", in the hopes of catching "someone hacked your server and changed your JS" early.
- strictnein 8y ago
  Your release branch wouldn't have any 3rd party JS, so diffing it vs the live stuff would catch a BA style attack, but not a TicketMaster style attack, which is more prevalent.
strictnein 8y ago
BA had a file they hosted compromised through their CMS. Many, many websites have 3rd party JS that updates at will. Only doing the check when you do a deployment wouldn't catch either one.
- onli 8y ago
  You're right, with that perspective an hourly check to compare that what is online mirrors what is supposed to be online is a good additional defense.
ilikehurdles 8y ago
If you're using a third party cdn to serve js assets then you have no chance to assure security.
- thaumasiotes 8y ago
  Not quite true; you can set a Content-Security-Policy header which whitelists scripts by their cryptographic hash. Assuming you know the exact contents of the script you want to run (which you should, if the only issue is that you're using a CDN), this should be fine. Just set the header yourself. If you're letting third parties load arbitrary code on your site, that's harder to deal with. Then a compromise of them is likely to also be a compromise of you.
- dotancohen 8y ago
  If you're using a third party CDN to serve Javascript assets on a page that requests users to enter sensitive information, such as credit card details, then you are DOING IT WRONG. Seriously, do the devs not realize that "cloud" means "somebody else's computer" and using "cloud assets" on your payment pages means somebody else is deciding what Javascript to run on your payment pages?