This week I did pentest of a commercial application. I was frustated to find that most of the user supplied content was sanitized using html entities, before being sent to the browser. So, it was not possible to inject my scripted content to cause XSS.
Just when I was about to give up, I found the possibility of a phishing attack in one of the pages, specifically the error page in the application. The problem was user supplied content from the url paramater list was put directly into the error page, filtered only for XSS characters and the whitespace character. In a normal scenario, user is redirected to the error page, resulting in:
/security/phishinguserinput/error.cgi?url=/my_app_url&user=jack
Using URL encoding and the ‘%09′ ASCII character (horizontal tab), I can phish a user to go evilsite.com. Evilsite.com will have the same inferface looks as the legitimate site and some users might unknowingly fall prey into typing their login credentials.
/security/phishinguserinput/error.cgi?url=/my_app_url&user=%2e%54%68%69%73%09%73%69%74%65%09%69%73%09%63%75%72%72%65%6e%74%6c%79%09%64%6f%77%6e%09%66%6f%72%09%6d%61%69%6e%74%65%6e%61%6e%63%65%2e%09%50%6c%65%61%73%65%09%75%73%65%09%65%76%69%6c%73%69%74%65%2e%63%6f%6d
This class of phishing attack can apply to any page. It does not confine to error pages and is not blocked by filtering and encoding mechanisms. The only requirement is user’s language characters (including whitespace character like %09, %20, etc) should be injectable in the page output and the rendered page should sound convincing to phish a user into going to evil site. If the user is not convinced and types the domain name directly into the address bar, this attack will fail .
A solution to this issue is to use url encoding or html entities for all the special characters [not just XSS chars < > " '] before writing back user’s input data back to the browser. For links, using url encoding instead of html entities also protects from HTTP Parameter Pollution.
Tags: HTML Entities, Phishing, URL Encoding, Whitespace
I remember when i raised this as a vulnerability issue (phishing) i had an argument with the vendor (owner of the application) as they think this is not even a low risk issue! funny huh
Most vendors and admins think that XSS is a joke and they keep it un-patched. According a past study I made, 6 on 10 online banks are vulnerable to a XSS attack and could be used to inject a HTML form to spoof the login.
Nice article, as always.