0

I was going through some CLIENT side defenses against reflected XSS e.g. XSS auditor(chrome), IE8 XSS Filters, NoScript. They use regular expression and other sophisticated techniques. Why didn't they use any simpler idea?

My question is- why don't we store what ever is going to server as parameters and if these parameters are reflected in HTML response then discard it or encoded it. Simple idea. I feel there may be false positives but not very convincing ones. Any input?

migrated from stackoverflow.com Apr 18 '14 at 21:05

This question came from our site for professional and enthusiast programmers.

  • Okay. I will not do that from now. – Naman Apr 18 '14 at 16:13
1

My question is- why don't we store what ever is going to server as parameters and if these parameters are reflected in HTML response then discard it or encoded it

Any parameters? So if I search for “Hello” and the response page contains the text “Here are your results for Hello”, it gets mangled?

There has to be some criterion for what counts as potentially dangerous, otherwise every form on the web is going to break like this. You could start out with “any parameter with a < in”, but then what about attribute injection attacks like onmouseover=, or JavaScript injection like '; alert(document.cookie)? And how do you stop a parameter of just < from breaking every tag on the page? There isn't an obvious watertight answer, which is why detection ends up being a complex mess of heuristic rules and not a clean, watertight pattern.

Personally I think client-side reflected-XSS detection is deeply misguided: in principle doomed to failure and in practice worse than useless, but if you're going to do it you'll need to limit its scope because content reflection is a common property the web needs to work properly, not always an attack.

  • We can specify that store only when some special characters in input(with certain length) are present then check for reflection. – Naman Apr 17 '14 at 12:51
  • @Naman: which special characters? <? &? "? '? Backslash? Space? (To deal with unquoted attribute value injections.) There are many characters which could potentially cause reflected XSS issues if incorrectly handled, and if you're counting reflection of any of them as an attack you are going to get loads of false positives, more than with the complex rules currently used by IE. – bobince Apr 17 '14 at 15:13
  • Can you give me an example of a good false positive where it is bad idea? What if I HTML encode it? there will be no problem I guess. – Naman Apr 17 '14 at 23:21
  • @Naman How about on Stack Overflow - how would it then be possible to enter code examples to post to other users if you're preventing <script> tags and the like (see what I did there)? – SilverlightFox Apr 18 '14 at 10:34
  • The encoding will not happen in serverside. If I encode it on my browsers, other user will see it just fine. – Naman Apr 18 '14 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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