4 ms·

> It's not difficult to take user-entered data and just dump it to a log file. I'm pretty positive none of these vulnerabilities exist with System.out.println.

by a-dub 5y ago

> It's not difficult to take user-entered data and just dump it to a log file. I'm pretty positive none of these vulnerabilities exist with System.out.println. yes, but there can be (and have been) vulnerabilities in terminal emulators, terminal multiplexers, text editors, databases, web renderers and all manner of tools that can be used to store the contents of or view that file. your argument makes sense that the logging library should not be attempting to parse the log strings, but think about all the other millions of lines of code that could potentially try to parse that data as well. patch log4j one day and the next you find a bug in some colorizer javascript library or in the sixel support for the terminal emulator. people add parsing everywhere. i think ideally that all user supplied data should be sanitized in the strictest possible manner before anything is done with it, including logging.

hn_throwaway_99 5y ago
So you never browse the web?
- a-dub 5y ago
  sure. i don't think i'm articulating my real point well enough. web browsers and all of their components get audited. because they process potentially malicious data as their core function, they see A LOT of attention in terms of hardening. the point that i'm trying to make is: the amount of software that doesn't immediately and apparently touch potentially malicious data is absolutely enormous and the number of paths that data can take to touch that software is even more enormous. yes, one can put forth good principles for "building codes" for software and yes, one should... but there's an awful lot of software out there that is not up to code (where the craft is so young that the idea of a code isn't even close to being finalized) and it won't be for a very long time. that being the actual on the ground situation, what is one simple thing that individual developers can do to help prevent catastrophes? always sanitize inputs. moreover, it's much easier to find and audit every place where data is accepted from untrusted sources than it is to find every place where data may be parsed.
  - a-dub 5y ago
    sort of raises an interesting question. rust has memory safety, but it's still possible to write code that "isn't up to code." i wonder if maybe rust+1 will be the first language/environment/ecosystem that has application development security principles built in. that would mean, like, not just taking the compiler forward in terms of memory safety, but also codifying a set of principles, enforcing those that can be statically checked in the compiler with the compiler, and aggressive curation for a singular library archive (similar to how some internet library archives require unit tests or style, etc).
    - yjftsjthsd-h 5y ago
      Up until "singular library archive" I would say that exists today in the form of Ada and formal methods (and both in the form of SPARK)
NavinF 5y ago
> user supplied data should be sanitized in the strictest possible manner before anything is done with it, including logging Oh come on, how would you even do that if you don’t know how the data is going to be interpreted by parsers that nobody knows they’re using? WAFs have been trying to do this since forever, but it’s always been security theater that separates gullible companies from their money and randomly blocks users that use “special” characters like slash or quotation marks. I guess you could base64 encode everything, but that wouldn’t save you from the terminal bugs you mentioned. At some point you’re gonna have to undo the “sanitizing” and look at the text.

by a-dub 5y ago

hn_throwaway_99 5y ago

So you never browse the web?

a-dub 5y ago
sure. i don't think i'm articulating my real point well enough. web browsers and all of their components get audited. because they process potentially malicious data as their core function, they see A LOT of attention in terms of hardening. the point that i'm trying to make is: the amount of software that doesn't immediately and apparently touch potentially malicious data is absolutely enormous and the number of paths that data can take to touch that software is even more enormous. yes, one can put forth good principles for "building codes" for software and yes, one should... but there's an awful lot of software out there that is not up to code (where the craft is so young that the idea of a code isn't even close to being finalized) and it won't be for a very long time. that being the actual on the ground situation, what is one simple thing that individual developers can do to help prevent catastrophes? always sanitize inputs. moreover, it's much easier to find and audit every place where data is accepted from untrusted sources than it is to find every place where data may be parsed.
- a-dub 5y ago
  sort of raises an interesting question. rust has memory safety, but it's still possible to write code that "isn't up to code." i wonder if maybe rust+1 will be the first language/environment/ecosystem that has application development security principles built in. that would mean, like, not just taking the compiler forward in terms of memory safety, but also codifying a set of principles, enforcing those that can be statically checked in the compiler with the compiler, and aggressive curation for a singular library archive (similar to how some internet library archives require unit tests or style, etc).
  - yjftsjthsd-h 5y ago
    Up until "singular library archive" I would say that exists today in the form of Ada and formal methods (and both in the form of SPARK)

NavinF 5y ago

> user supplied data should be sanitized in the strictest possible manner before anything is done with it, including logging Oh come on, how would you even do that if you don’t know how the data is going to be interpreted by parsers that nobody knows they’re using? WAFs have been trying to do this since forever, but it’s always been security theater that separates gullible companies from their money and randomly blocks users that use “special” characters like slash or quotation marks. I guess you could base64 encode everything, but that wouldn’t save you from the terminal bugs you mentioned. At some point you’re gonna have to undo the “sanitizing” and look at the text.