4 ms·

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 libra

by 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?

by onli 8y ago

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?