Comment by ashishb
2 days 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.
Even in a browser, a compromised JS payload can put your user's data and privacy at risk.
> 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.
> your non-user data at risk.
That sounds like a GDPR fine waiting to be issued right there.
In 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.
> 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.