Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm testing an application that only skips < and > symbols. The user input being validated is always inserted between html tags like <b>, <span>, <div>, etc. and never passed to the page as an attribute. Is it enough protection or there is a way to bypass this kind of filter?

Example:

<a href="http://www.site.com" style="color:white">
  UserInput
</a>

Regards.

share|improve this question
2  
Don't strip characters, encode them. Or better yet, have your web framework encode them automagically. –  CodesInChaos Aug 13 '13 at 14:54
    
I agree with CodesInChaos... for the cost of development, you might as well output encode as necessary for the context rather than have a weak input sanitisation process as a form of security. What happens in future when the user input ends up as a JavaScript variable or as a field in an <input> tag? –  SilverlightFox Aug 14 '13 at 15:26
    
Not sure I understand the problem correctly, but what if $UserInput = &lt;script&gt;alert(1);&lt;/script&gt? –  Luc Dec 9 '13 at 18:59

3 Answers 3

This is not sufficient protection

There are many ways an attacker might be able to sneak in a byte sequence that will be interpreted by someone's browser as markup.

In your case, it might even be possible just to use ampersand encoding to pass < and > chars.

Failing that, double encoding could be used to bypass your filters, or even overlong utf-8 sequences (however this last one is a bit outdated and most software stacks don't fall for it).

Those are just a few examples, but there are many more ways of bypassing simple markup filters like yours. This bit in particular is relevant.

share|improve this answer
    
I tried all those methods but no one worked. Also I realized that < and > are not filtered only actual html tags. –  Nucklear Aug 13 '13 at 13:53
1  
@Nucklear if you have thrown everything from that OWASP page at your filter, then you're probably pretty good. Whitelisting is still the preferred approach however. eg msg.matches("[\w\s]*") –  lynks Aug 13 '13 at 13:59

Oh, where to begin...

If there's one tenet of security that proves itself again and again and again it's that blacklists fail.

Play the long game - sure your web-application may resist the limited number of attacks you threw at it today, but the internet is going to be able to try thousands of more things with thousands of more variables (new code, different browsers, different language sets, etc, etc, etc).

"The user input being validated is always" -- says you today. What happens when you move on and another developer inherits that code? Are they going to understand and honor the commitments you made to yourself in your head? If you do input validation and output encoding, you give the next guy a fighting chance.

Go ahead and strip out ""<script>", what happens when someone submits ""<scr<script>ipt>"" ?

share|improve this answer

Who is providing the HREF within the url you provided here:

    <a href="http://www.site.com" style="color:white">
  UserInput
</a>

If the href is being pulled from an input tag. Then this is just yet another case of not enough filtering or escaping of user input. All user input needs to be considered evil.

For instance, if it is the user supplying the URL for that anchor tag in your example case, it is entirely possible that this sXSS will work and load on every mouse over:

URL:  http://www.site.com" onmouseover="javascript:alert(1)"

Alternatively, you could change the onmousover to onload and now you have your javascript executing on every page load. Disabling DOM events from within HTML tags is another method of preventing this type of a sXSS attack.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.