While interacting with Giorgio I came across something new to me: InputDecoding. As Giorgio says:
In the Paypal case, it’s not doing output encoding, it’s skipping input decoding (quite strangely).
The correct workflow should be:
- Input decoding (decodeURIComponent)
- Input validation
This Paypal page was missing all the 3, and only by luck the fact browsers different by IE properly encode the URL saves them from XSS.
Again, regarding IE Giorgio said:
>>IE doesn’t encode the URL?
No it doesn’t. Therefore an application which doesn’t encode its output is not protected even if it doesn’t decode the input.
You should always encode the output, and decode the input if it makes sense (almost always).
>>IS there any way to bypass this URL-encoding and execute XSS?
No (except in IE), unless the injection point is not quoted, because quotes in an URL are usually escaped by the browser (except in IE).
So, I became more susceptible towards IE. I know it since long back that IE is comparatively unsafe when I was testing script in file upload in Google Pages. The Firefox simply printed the URL back whereas IE executed the script. Other theories as well goes against the IE.
Even in case of above Paypal case , exploitation of this specific Paypal vulnerability requires the “double quotes” character to pass through with no encoding: therefore, while the vast majority of XSS exploits are cross-browser, this one affects exclusively IE.