Earlier quoted context omitted.
> You could argue that the API is bad for allowing HTML strings as arguments That is exactly what I’m arguing, yes. And how native DOM helps there?
There are relatively few DOM APIs which take a trusted string. innerHTML and outerHTML are two and clearly state that they take HTML so it's no surprise for the stuff you give them to be interpreted thus. But if you use e.g. textContent or createTextNode to insert text into your document, they will correctly sanitise it. jQuery has text()[0], but because most of its API takes strings to start with, it's very convenie…
What I learned from suffering my first and last XSS attack
41–43 of 43 posts
Re: What I learned from suffering my first and last XSS attack
#42Earlier quoted context omitted.
There are relatively few DOM APIs which take a trusted string. innerHTML and outerHTML are two and clearly state that they take HTML so it's no surprise for the stuff you give them to be interpreted thus. But if you use e.g. textContent or createTextNode to insert text into your document, they will correctly sanitise it. jQuery has text()[0], but because most of its API takes strings to start with, it's very convenie…
yes, API takes strings, but it calls native DOM at the end anyway, so I still don't get what's your point.
jQuery calls unsafe API which should only be handled trusted strings but makes it easy and convenient to give them untrusted string and thus introduce exploit vectors.
Furthermore it's also significantly more difficult to audit the code, using the regular DOM there are only a pair of attributes to check, whereas pretty much any jQuery method call is a potential security hole.
tldr: jQuery makes doing things wrong very easy, much easier than doing things right.
Re: What I learned from suffering my first and last XSS attack
#43Earlier quoted context omitted.
Thanks, I got an error message. I'll check it out once the site is up!
Tinfoil discovered a few errors on my site. Thank you! I wish you hired a designer though :)