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.

A technique for avoid filtering of common words is the one I described in the title.

However, why does this technique work? SELECT isn't the same as SELSELECTECT for example.

share|improve this question
add comment

2 Answers

up vote 22 down vote accepted

Let's say I blacklisted the word <script> and replace it with nothing. Then <scr<script>ipt> becomes <script>.

This is why well-written html sanitizers/purifiers apply the rules recursively. That is only when the last sanitation step made no changes to the content will it stop/not apply another round of the processing rules. (It also likely will fail and return no content if too many processing rounds are necessary).

share|improve this answer
8  
IMO a well written html doesn't use such replacement rules in the first place. It should actually parse the html into a DOM like representation, and then generate output form it after comparing tags/attributes against a whitelist. –  CodesInChaos Feb 22 '13 at 16:54
2  
@CodesInChaos - Agree. I'm not advocating someone builds their own HTML sanitizer. Its saner to just use a safe lightweight markup language (where symbols like < are automatically escaped to &lt; and whitelisted safe HTML elements are inserted) or well-tested HTML purifier, and have said this more than once. However, this is a clear example of bypassing non-recursive filtering (see example 5 ). –  dr jimbob Feb 22 '13 at 17:47
    
The question is if a more paranoid sanitizer shouldn't simply return nothing or an error condition whenever it even finds bad words instead of trying to make something sensible out of from an apparent attack. –  Hagen von Eitzen Feb 23 '13 at 8:05
    
@HagenvonEitzen - For HTML sanitation there is a good solution of just escaping <>&'" to their HTML escaped versions e.g., &lt; that the browser specifically should not invoke, and just because you saw <scr<script>> doesn't necessarily imply an attack -- it could be a generic discussion like what we are having where someone forgot to escape. Granted, I agree with your approach to sanitation if you are sure its an attack of some sort. E.g., if a POST variable came from a pull down form and there's an unexpected value -- that could mean someone's attacking/probing you. –  dr jimbob Feb 23 '13 at 16:44
add comment

This works against broken sanitizers that simply use s.Replace("select",""). When you apply that to selselectect, it removes the select in the middle, but since it doesn't run again on the output, the split sel+ect becomes select and survives the sanitizer.

This attack won't work against any sane sanitizer.

share|improve this answer
add comment

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.