5 ms·

Could you elaborate on this or point me to a site that explains the security risks? For my product, I have a web app that does 100% of the rendering in Javascr

by sdesol 16y ago

Could you elaborate on this or point me to a site that explains the security risks? For my product, I have a web app that does 100% of the rendering in Javascript so I use html() a lot. I adhere by the rule that I don't trust anything that comes from the client so I'm curious to learn what the security problem may be. Thanks.

varaon 16y ago
All you need: http://www.owasp.org/index.php/XSS http://www.owasp.org/index.php/XSS
- sdesol 16y ago
  Thanks for the link but I really don't see anywhere where it says using something like html() would be a greater risk. The rule of thumb is to sanitize information from untrusted sources. And as long as you adhere to this rule, I really don't see how using html() would pose a security threat. That is unless I'm missing something?
  - tptacek 16y ago
    I think the suggestion is that programmatically creating specific DOM nodes is safer than handing the library a string containing user input and hoping that the browser doesn't interpret it in a way that corrupts the DOM.
    - sdesol 16y ago
      I certainly agree with this but I think it's misleading to say it increases your chances for xss security threats. I can see it increasing the chances of having a webpage not behave properly across all browsers though.
      - mhansen 16y ago
        Say some "<script>do_bad_stuff();</script>" got through from some source you just expected to have text. (e.g. this happened for youtube the other day) If you insert this into the DOM with html(), it will execute the script, doing bad things. If you insert it into the dom with e.g. text(), it won't be interpreted.
        DrJokepu 16y ago
        You don't even need a script tag. Any tag with event attributes will work, e.g. <span onmouseover="alert('XSS')">Hello World!</span>
DrJokepu 16y ago
You can do the filtering either on input or output (or both if you want to be very careful). Both works, however I prefer filtering on output because (a) if a new way to conduct an XSS attack is discovered, I only need to update code, not data; (2) if tomorrow HTML gets replaced by a hypothetical future document format, I would need to refilter all my data if I only filter at input.

by sdesol 16y ago

varaon 16y ago

All you need: http://www.owasp.org/index.php/XSS http://www.owasp.org/index.php/XSS

sdesol 16y ago
Thanks for the link but I really don't see anywhere where it says using something like html() would be a greater risk. The rule of thumb is to sanitize information from untrusted sources. And as long as you adhere to this rule, I really don't see how using html() would pose a security threat. That is unless I'm missing something?
- tptacek 16y ago
  I think the suggestion is that programmatically creating specific DOM nodes is safer than handing the library a string containing user input and hoping that the browser doesn't interpret it in a way that corrupts the DOM.
  - sdesol 16y ago
    I certainly agree with this but I think it's misleading to say it increases your chances for xss security threats. I can see it increasing the chances of having a webpage not behave properly across all browsers though.
    - mhansen 16y ago
      Say some "<script>do_bad_stuff();</script>" got through from some source you just expected to have text. (e.g. this happened for youtube the other day) If you insert this into the DOM with html(), it will execute the script, doing bad things. If you insert it into the dom with e.g. text(), it won't be interpreted.
      - DrJokepu 16y ago
        You don't even need a script tag. Any tag with event attributes will work, e.g. <span onmouseover="alert('XSS')">Hello World!</span>

DrJokepu 16y ago

You can do the filtering either on input or output (or both if you want to be very careful). Both works, however I prefer filtering on output because (a) if a new way to conduct an XSS attack is discovered, I only need to update code, not data; (2) if tomorrow HTML gets replaced by a hypothetical future document format, I would need to refilter all my data if I only filter at input.