3 ms·
JavaScript fanatics will downvote me, but I will say again. JavaScript is meant to be run in an untrusted environment (think browser), and running it in any for
by ashishb 10mo ago
JavaScript fanatics will downvote me, but I will say again.
JavaScript is meant to be run in an untrusted environment (think browser), and running it in any form of trusted environment increases the risk drastically [1]
The language is too hard to do a meaningful static analysis.
This particular attack is much harder (though not impossible) to execute in Java, Go, or Rust-based packages.
1 - https://ashishb.net/tech/javascript/ https://ashishb.net/tech/javascript/
- tantalor 10mo agoEven in a browser, a compromised JS payload can put your user's data and privacy at risk.
- ashishb 10mo ago> Even in a browser, a compromised JS payload can put your user's data and privacy at risk. True. In a backend, however, a compromised payload can put all of user's and your non-user data at risk.
- Muromec 10mo ago> your non-user data at risk. That sounds like a GDPR fine waiting to be issued right there.
- mcintyre1994 10mo agoIn what way is it harder to write a library that exfiltrates credentials passed to it in those languages? I’d think it’d be a bit easier because you could use the standard library instead of custom encryption, but otherwise pretty much the same.
- ashishb 10mo ago> In what way is it harder to write a library that exfiltrates credentials passed to it in those languages? It is not harder to write. It is more challenging to execute this attack stealthily. Due to the myriad behaviors of runtimes (browser vs. backend), frameworks (and their numerous versions), and over-dependency on external dependencies (e.g., leftpad), the risk in JS-based backends increases significantly.