The reflective XSS filter landed in Bug #26199 is too strict in evaluating whether inputs were reflected back into the output. If, for example, the server-side code does the equivalent of a PHP addslashes() on the input, then the following input will dodge the filter while still executing script: <script>var bogus=/\/; alert(document.URL);</script> The backslash will be doubled, resulting in an output that's subtly different than its input. IE's filter accounts for such subtle differences between input and output using regular expressions, and perhaps we should do the same.
Right. We are aware of this issue and it is among our list of improvements. (In reply to comment #0) > The reflective XSS filter landed in Bug #26199 is too strict in evaluating > whether inputs were reflected back into the output. If, for example, the > server-side code does the equivalent of a PHP addslashes() on the input, then > the following input will dodge the filter while still executing script: > > <script>var bogus=/\/; alert(document.URL);</script> > > The backslash will be doubled, resulting in an output that's subtly different > than its input. > > IE's filter accounts for such subtle differences between input and output using > regular expressions, and perhaps we should do the same.
Dan fixed this in http://trac.webkit.org/changeset/46250