Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I'm guessing that HTML encoding the input would probably be a better solution, but I'm curious if just stripping out any < and > characters would be an effective defense against XSS attacks.
Will doing this keep a site safe against XSS?
UPDATE: If it won't protect me could someone explain what type of attack could get through?
It depends on the context the injection happens.
Obviously, if the injection happens in the context of an elements content like this one:
<p>Your search for "❌" has returned the following results:</p>
< is required to switch from text to markup. But even here, if you echo user input in a <script>, e.g.:
<script>var search = "❌";</script>
You’ll need to look for other characters as you’re not in the plain text context. Here you should take care for characters which are special inside JavaScript string literals as well as certain sequences that can denote the script element’s end tag, e.g. </script>, or </script/.
Similarly, if you print user input in an element’s attribute value:
<input type="text" name="search" value="❌">
Here you have to take care of characters that are special for double quoted attribute values, i.e. the delimiting " quote. If you’re using single quotes or no quotes at all, different rules need to be applied.
Additionally to that, you don’t just have to look for syntax but also for semantics. Like there are javascript: and data: URIs that can be used for XSS. Or there is a JavaScript that uses part of the user supplied data for some evaluation, or retrieval of some additional script code, etc. There are hundreds of examples.
So always take the context into account in which you want to put user supplied data and encode that data correspondingly.
Short answer: No.
Long answer: In a lot of cases, yes, but don't do it.
Someone correct me if I'm wrong about anything here.
If, and only if, the text is only outputted to "the body" of a standard styling element, and if that body isn't then grabbed by some Javascript or otherwise, then I would honestly have to say yes. By body I mean the text is being outputted in the form <b><u>$USERINPUT</u></b>; it's text inside the HTML document and is not already part of the markup in some way. So it is not within some tag or special block.
However, many times this is not the only case where user input will be written to the page. If you are writing inside of an HTML tag, typically an attribute value, then it will look something like this: <img src="file.jpg" alt="$USERINPUT" />. Here, filtering on < or > won't help, since the attacker can input " onload="alert('XSS')" or something similar, and the resulting HTML will become <img src="file.jpg" alt="" onload="alert('XSS')" />, which means arbitrary Javascript can be executed.
And if somehow you are placing user input into something inside a <script> tag, there are a whole myriad of things you need to worry about.
Basically, just use a good and tested HTML sanitization function. You won't have to worry about all the cases if you do.
json.dumps(user_input) should suffice for this, shouldn't it? (Assuming that user_input is a string.)
May 4, 2013 at 3:07
json.dumps should be fine. I meant if you were to place some input into a <script> block with no filtering, or just trying to use custom character filtering. The reason you aren't worrying is because you are serializing an object of some sort and making it accessible to Javascript, versus writing whatever you like into the block.
Nope because there are ways which actually omit the < > tags. Input should be treated as a string so you need to properly encode it. I suggest you have a look at the owasp testing guide v3
%3E and %3C instead of > and <. Is this what you are referring to?
Apr 29, 2013 at 22:15