3 ms·

A good Content-Security-Policy that did not allow unsafe-eval would have worked to protect against this. Puzzling that ecommerce sites have not set up proper CS

A good Content-Security-Policy that did not allow unsafe-eval would have worked to protect against this. Puzzling that ecommerce sites have not set up proper CSP on their checkouts.

bawolff 6y ago
If someone can insert an eval() in your website, the battle is lost and they can do other evil things. Sure it defeats this one particular obfuscation method, but the ship has already sunk at that point (To be clear, not dissing on CSP, its great, but it can't stop all attacks) Now if script-src CSP prevented the script tag part of this attack, that would be a good thing CSP can potentially do (depending on what type of access attacker had).
- atoav 6y ago
  Which is why I usually writw the CSS completely myself (at max reusing my own css cose). I want to know the things I built, both for security and in case something doesn't work.
- SahAssar 6y ago
  Yeah, it's not just unsafe-eval that needs to be blocked, I just said that that was the specific feature that would have blocked this. A good CSP would have protected against most injection attacks though (as long as the JS files have not been modified).
  - jeroenhd 6y ago
    You're right if this was some included third party script, but usually these hacks involve an attacker getting access to the (PHP/HTML) source code and injecting stuff directly. At that point there's very little you can do to prevent JS files from being changed or the CSP being disabled at all. Very few web store systems rely on statically generated HTML pages, and the ones that do usually have some JS file for animations or functionality that the attacker can also modify. CSP is great for blocking XSS and other such attacks, but I don't think it can be an effective defence in this particular attack. The only way I can think of to get CSP to protect you is to host no JS on the server itself, configure some kind of proxy (Cloudflare?) and inject CSP config there. An attacker could still compromise the website but they'd need to escalate their attack to the point of a DNS takeover or add a noticeable redirect to an attacker-controlled skimming page, both of which aren't very likely to be used against random targets like these web shops often are.
blindm 6y ago
> Puzzling that ecommerce sites have not set up proper CSP on their checkouts CSP is usually added as an afterthought and after the fact of an attack. Yes, it's great at weeding out XSS, but it's a grossly underused and underimplemented feature.
strictnein 6y ago
Keeping a CSP updated is beyond the technical abilities of people running most small online stores.

A good Content-Security-Policy that did not allow unsafe-eval would have worked to protect against this. Puzzling that ecommerce sites have not set up proper CSP on their checkouts.

bawolff 6y ago

If someone can insert an eval() in your website, the battle is lost and they can do other evil things. Sure it defeats this one particular obfuscation method, but the ship has already sunk at that point (To be clear, not dissing on CSP, its great, but it can't stop all attacks) Now if script-src CSP prevented the script tag part of this attack, that would be a good thing CSP can potentially do (depending on what type of access attacker had).

atoav 6y ago
Which is why I usually writw the CSS completely myself (at max reusing my own css cose). I want to know the things I built, both for security and in case something doesn't work.
SahAssar 6y ago
Yeah, it's not just unsafe-eval that needs to be blocked, I just said that that was the specific feature that would have blocked this. A good CSP would have protected against most injection attacks though (as long as the JS files have not been modified).
- jeroenhd 6y ago
  You're right if this was some included third party script, but usually these hacks involve an attacker getting access to the (PHP/HTML) source code and injecting stuff directly. At that point there's very little you can do to prevent JS files from being changed or the CSP being disabled at all. Very few web store systems rely on statically generated HTML pages, and the ones that do usually have some JS file for animations or functionality that the attacker can also modify. CSP is great for blocking XSS and other such attacks, but I don't think it can be an effective defence in this particular attack. The only way I can think of to get CSP to protect you is to host no JS on the server itself, configure some kind of proxy (Cloudflare?) and inject CSP config there. An attacker could still compromise the website but they'd need to escalate their attack to the point of a DNS takeover or add a noticeable redirect to an attacker-controlled skimming page, both of which aren't very likely to be used against random targets like these web shops often are.

blindm 6y ago

> Puzzling that ecommerce sites have not set up proper CSP on their checkouts CSP is usually added as an afterthought and after the fact of an attack. Yes, it's great at weeding out XSS, but it's a grossly underused and underimplemented feature.

strictnein 6y ago

Keeping a CSP updated is beyond the technical abilities of people running most small online stores.