4 ms·

Not every application developer realized that writing a string to a log required trusting that string (its just a text file, what could go wrong!). Meanwhile,

by antsar 5y ago

Not every application developer realized that writing a string to a log required trusting that string (its just a text file, what could go wrong!). Meanwhile, library developers didn't realize app devs would be feeding untrusted strings to their library. I guess its debatable who's more at fault. I'd argue a logging library that executes the log entries as code is a hell of a footgun. (Not a Java dev. Maybe log4j had obvious warnings on the tin? If nothing else, there is a UX lesson here.)

Sohcahtoa82 5y ago
> Meanwhile, library developers didn't realize app devs would be feeding untrusted strings to their library. What?! It's a logging library. I would expect users of it to be feeding user input, so that in the case of a bug, I can look at logs to see what input triggered a bug.
- cesarb 5y ago
  > It's a logging library. I would expect users of it to be feeding user input, I agree with you, but I did see a couple of days ago someone with the diametrically opposite opinion: that we should never log user input, with a link to https://owasp.org/www-community/attacks/Log_Injection https://owasp.org/www-community/attacks/Log_Injection (plus this bug) as the justification.
  - Sohcahtoa82 5y ago
    Seems like a strange conclusion to draw. I mean, taking input from one user and presenting it to another creates the opportunity for XSS attacks, but obviously you wouldn't use that to argue that you should never show one user's input to another, because then no website could contain user-generated content. Forums would not exist and the entire web would be non-interactive. Nah...logging user input is a must to be able to perform digital forensics and incident response. Certainly knowing exactly how an attack was triggered would help in preventing it in the future. Just filter the CRs and LFs to prevent log forging, and make sure log files are not accessible from the web app. They should be in /var/log, not in the web root.

by antsar 5y ago

Sohcahtoa82 5y ago

> Meanwhile, library developers didn't realize app devs would be feeding untrusted strings to their library. What?! It's a logging library. I would expect users of it to be feeding user input, so that in the case of a bug, I can look at logs to see what input triggered a bug.

cesarb 5y ago
> It's a logging library. I would expect users of it to be feeding user input, I agree with you, but I did see a couple of days ago someone with the diametrically opposite opinion: that we should never log user input, with a link to https://owasp.org/www-community/attacks/Log_Injection https://owasp.org/www-community/attacks/Log_Injection (plus this bug) as the justification.
- Sohcahtoa82 5y ago
  Seems like a strange conclusion to draw. I mean, taking input from one user and presenting it to another creates the opportunity for XSS attacks, but obviously you wouldn't use that to argue that you should never show one user's input to another, because then no website could contain user-generated content. Forums would not exist and the entire web would be non-interactive. Nah...logging user input is a must to be able to perform digital forensics and incident response. Certainly knowing exactly how an attack was triggered would help in preventing it in the future. Just filter the CRs and LFs to prevent log forging, and make sure log files are not accessible from the web app. They should be in /var/log, not in the web root.