Search code examples
javascriptxsscode-injectioncross-site

Mitigating XSS attacks from submitted data - is the < character the heart of all attacks?

I have been perusing the OWASP Xss Filter Evasion cheat sheet and it appears that most (all?) user-input based XSS attack vectors depend on the ability to successfully submit the < character or an encoded version thereof. Per the OWASP document, I can't find any attack vectors that bypass the need to inject the < character in some way. So if the input filter checks for and removes or replaces all instances of < from user-submitted data, will XSS risks be mitigated?

Specifically I'm asking if there are other XSS attack vectors against user-submitted data that don't depend on the < character.

Obviously this doesn't mitigate SQL injection etc, but that's a separate issue.

Thanks for any input!

Solution

  • I am not going to get into what this does prevent, but I will address some of what it allows through.

    Let's say your filter takes a string, and returns a string with all of the < replaced with empty strings. Ignoring that you could mess up this implementation if you are not careful. If you inject un-trusted data into html attributes or javascript strings, for example, you've done nothing to mitigate XSS.

    Here's an example of an XSS attack vector that we could use to bypass FilterLeftBrackets():

    <div id="content" data-query="~injection-point~"></div>

    payload could be: q" onmouseover=alert('xss'); data-x="

    Resulting in:

    <div id="content" data-query="q" onmouseover=alert('xss'); data-x=""></div>

    here's one for JavaScript:

    var queryMsg = "you searched for: " + "~injection-point~";

    payload could be: q"; alert('xss'); var x="

    Resulting in:

    var queryMsg = "you searched for: " + "q"; alert('xss'); var x="";

    In both cases, you needed to escape ", but it could have easily been '. the thing with injection is that it depends entirely on the context. Be thoughtful about WHERE you are putting user input, and check what could have been used to "break out" of the constraints you assume are set.

    In short, use a library... don't come up with your own scheme, and be thoughtful of the context.

    Please note this from the evasion cheat sheet:

    This cheat sheet is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion.

    You may find this more helpful: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

    I'm also a big fan of this tutorial from google: https://www.google.com/about/appsecurity/learning/xss/