3 ms·
Have you heard about this: https://www.zdnet.com/article/equifax-confirms-apache-struts-flaw-it-failed-to-patch-was-to-blame-for-data-breach/ https://www.zdnet
by smsm42 4y ago
Have you heard about this:
https://www.zdnet.com/article/equifax-confirms-apache-struts-flaw-it-failed-to-patch-was-to-blame-for-data-breach/ https://www.zdnet.com/article/equifax-confirms-apache-struts...
Pretty much everyone's private credit data in the US were leaked because of code written in... Java. Should we still go on into this discussion about how a statically-typed language saves you from whatever, or we can bury this finally?
- lolinder 4y agoThis is what I said: > This class of bug cannot happen in a statically-typed language. I never claimed statically typed languages prevented all RCE bugs, I claimed they prevent RCE bugs that result from making bad assumptions about the shape of your data, which is what happened here with gitlab. The RCE you linked to was the result of including an interpreter for a scripting language and incorrectly executing it during error handling. This is exactly the kind of malfeasance I identified in my original comment as potentially breaking the safety static typing can bring. Even this could have been prevented by better use of the type system: the OGNL interpreter shouldn't be able to accept just any String, it should require wrapping the String in an OGNLScript class first. As long as library code doesn't construct that class, this would force all layers to keep track of whether a given string is actually safe to interpret. The user must at some point opt in. Back to the gitlab exploit: It's a fact that a statically-typed language does save you from bugs whose explanation is "id is supposed to be a number, but..." We can quibble about whether it's worth the hassle to have that guarantee, but this particular bug would not have been written in Java.