Failure to sanitize input is one thing, but the bigger issue to me is that, with so many of these Java server installations, that a simple injection can immediately lead to "game over" from a server takeover perspective.
For the bug in question, I bet the vast majority of webservers never need the ability to call unrestricted Runtime.exec(), yet access to that is just one unsanitized input away from complete control over your server.
OS vendors have made leaps and bounds in the past decade making it much harder for code vulnerabilities to lead to system takeover. I'd argue it's time for server code and language runtimes to make it easier to write secure code.
That’s fair. But there needs to be a point somewhere that you just get work done.
I absolutely agree that runtimes, frameworks, and server code should do a better job at trust and sanitization, but you will always get to a point where if you want to get something done, you need to do the work.
I guess I’m skeptical that eval() or runtime.exe could or even should take in lists and configs of what the code is allowed to do and monitor for it during execution. It seems like doing that would add countless issues and complexity, but more so just kick the can down the code to another layer with the same eventual issue.
For the bug in question, I bet the vast majority of webservers never need the ability to call unrestricted Runtime.exec(), yet access to that is just one unsanitized input away from complete control over your server.
OS vendors have made leaps and bounds in the past decade making it much harder for code vulnerabilities to lead to system takeover. I'd argue it's time for server code and language runtimes to make it easier to write secure code.