4 ms·

There's a whole section on input sanitization but nothing on escaping output. If you're on the hook to sanitize all inputs, doesn't that mean you're not escapi

by danneu 10y ago

There's a whole section on input sanitization but nothing on escaping output. If you're on the hook to sanitize all inputs, doesn't that mean you're not escaping output? The biggest security mistake I've made so far in production was that one time I used an HTML templating library that didn't escape output by default.

vollmond 10y ago
Can you clarify? What exactly do you mean by escaping output, and how can forgetting that cause a security issue?
- mryall 10y ago
  User-provided data in any transport format (e.g. HTML) needs to be properly escaped so it can't use special characters to be processed as code or metadata rather than just plain data. Bugs in escaping cause pretty much every kind of injection attack, from SQL to XSS. The fundamental problem is not escaping data correctly for the context in which it is used. If you want to see specific examples, search for how to avoid XSS attacks. Any decent guide will focus on escaping, not sanitisation.
  - vollmond 10y ago
    Right, but you seem to be talking about input -- the question was about output. I did get my answer, though -- output matters because it might be a different medium than input. So even if you sanitize HTML input, malicious VBA code could make it through that eventually ends up in an Excel report and gets executed (for example).
- nommm-nommm 10y ago
  Example HTML output in a user's profile: Would you like to contact ${NAME}? Where ${NAME} is a user supplied parameter (you ask them what their name is) Let's say I entered my name as: <script>/evil code/</script> Now, if the output isn't escaped the page reads: Would you like to contact <script>/evil code/</script>? You've just injected evil code into the website that will be executed every time my user profile page is visited by another user. EDIT: Hacker news doesn't properly render javascript comments.
  - Tehnix 10y ago
    But that script tag would be taken care of in the input sanitation step. You normally remove all hints of HTML tags on input sanitation, which renders output sanitation a moot point.
    - tetrep 10y ago
      Unless you application has a static mapping of input -> output that never changes, you can't properly sanitize input for all potential output contexts. The string ';alert(1) is perfectly safe to drop in between HTML tags, but can be very dangerous in JavaScript, but only if it's inside a single-quoted string. You can try to filter for anything that may be potentially dangerous, but that's going to make a very long list of invalid inputs and once again you're playing whack-a-mole, hoping you correctly sanitize your input for all potential output contexts (unless you go through and re-sanitize all your user data whenever you add a new output context, which is a bit absurd). From a programming perspective, it's akin to a function not checking that the input it has received is valid (because the caller is always going to do that...).
    - nommm-nommm 10y ago
      >>You normally remove all hints of HTML tags on input sanitation Then what happens when you want to use that input in an excel export? PDF export? CSV file? Text file? How about if you want to use it in an HTML attribute? In a URL? Export the database elsewhere? (Such as a credit card company reporting to the CSAs). You can't assume that your data is going to be inside an HTML page between tags always because that mucks up your data. Data should be able to be used in many different ways because it will be and should not be tied to HTML.
      - vollmond 10y ago
        Ok, this is the comment that best explained it to me -- you want to sanitize (escaped, etc, whatever) output because, even if you sanitize all HTML/CSS/JS on input, they might have inserted malicious Excel scripts or PDF exploits, etc, that eventually do get executed in an output context.
- glitcher 10y ago
  And the bigger issue with only sanitizing user inputs without also escaping output is that different escaping methods are required for different output contexts (HTML content, HTML attributes, URL params, JavaScript variables, etc).
bensummers 10y ago
I've written an HTML templating system where the common security issues are simply not allowed: https://github.com/haplo-org/haplo-safe-view-templates https://github.com/haplo-org/haplo-safe-view-templates I'm pretty sure it covers all the HTML generation issues described in https://www.nostarch.com/tangledweb.htm https://www.nostarch.com/tangledweb.htm We're been using it very happily for a good six months, and it's worked out well.

by danneu 10y ago

vollmond 10y ago

Can you clarify? What exactly do you mean by escaping output, and how can forgetting that cause a security issue?

mryall 10y ago
User-provided data in any transport format (e.g. HTML) needs to be properly escaped so it can't use special characters to be processed as code or metadata rather than just plain data. Bugs in escaping cause pretty much every kind of injection attack, from SQL to XSS. The fundamental problem is not escaping data correctly for the context in which it is used. If you want to see specific examples, search for how to avoid XSS attacks. Any decent guide will focus on escaping, not sanitisation.
- vollmond 10y ago
  Right, but you seem to be talking about input -- the question was about output. I did get my answer, though -- output matters because it might be a different medium than input. So even if you sanitize HTML input, malicious VBA code could make it through that eventually ends up in an Excel report and gets executed (for example).
nommm-nommm 10y ago
Example HTML output in a user's profile: Would you like to contact ${NAME}? Where ${NAME} is a user supplied parameter (you ask them what their name is) Let's say I entered my name as: <script>/evil code/</script> Now, if the output isn't escaped the page reads: Would you like to contact <script>/evil code/</script>? You've just injected evil code into the website that will be executed every time my user profile page is visited by another user. EDIT: Hacker news doesn't properly render javascript comments.
- Tehnix 10y ago
  But that script tag would be taken care of in the input sanitation step. You normally remove all hints of HTML tags on input sanitation, which renders output sanitation a moot point.
  - tetrep 10y ago
    Unless you application has a static mapping of input -> output that never changes, you can't properly sanitize input for all potential output contexts. The string ';alert(1) is perfectly safe to drop in between HTML tags, but can be very dangerous in JavaScript, but only if it's inside a single-quoted string. You can try to filter for anything that may be potentially dangerous, but that's going to make a very long list of invalid inputs and once again you're playing whack-a-mole, hoping you correctly sanitize your input for all potential output contexts (unless you go through and re-sanitize all your user data whenever you add a new output context, which is a bit absurd). From a programming perspective, it's akin to a function not checking that the input it has received is valid (because the caller is always going to do that...).
  - nommm-nommm 10y ago
    >>You normally remove all hints of HTML tags on input sanitation Then what happens when you want to use that input in an excel export? PDF export? CSV file? Text file? How about if you want to use it in an HTML attribute? In a URL? Export the database elsewhere? (Such as a credit card company reporting to the CSAs). You can't assume that your data is going to be inside an HTML page between tags always because that mucks up your data. Data should be able to be used in many different ways because it will be and should not be tied to HTML.
    - vollmond 10y ago
      Ok, this is the comment that best explained it to me -- you want to sanitize (escaped, etc, whatever) output because, even if you sanitize all HTML/CSS/JS on input, they might have inserted malicious Excel scripts or PDF exploits, etc, that eventually do get executed in an output context.
glitcher 10y ago
And the bigger issue with only sanitizing user inputs without also escaping output is that different escaping methods are required for different output contexts (HTML content, HTML attributes, URL params, JavaScript variables, etc).

bensummers 10y ago

I've written an HTML templating system where the common security issues are simply not allowed: https://github.com/haplo-org/haplo-safe-view-templates https://github.com/haplo-org/haplo-safe-view-templates I'm pretty sure it covers all the HTML generation issues described in https://www.nostarch.com/tangledweb.htm https://www.nostarch.com/tangledweb.htm We're been using it very happily for a good six months, and it's worked out well.