Gone Phishing - Understanding IE7 False Positives
I know.. -10 for the cheezy title - but I couldn't resist. I really did go fishing last week, actually crabbing to be specific, but that's not what I want to talk about. I want to talk about my recent run-in with the IE7 Phishing filter.
As many of you know, I've been doing a lot of application development these days. One of the apps I've been working on, "Infradashboard" is a mock investor portal. It's a blend of real and make believe. The data and "users" are all fictitious, but there are some live items like a news feed, and stock quotes. Nothing too crazy, so I was really perplexed when IE7 marked it as a suspicious site.
My initial thought was that maybe I was doing a redirect that IE didn't like, but there were no redirects going on. Then I thought.. I know, it's the news feed, because I'm loading it from a different domain. But wait.. that all happens on the server-side, IE doesn't know anything about that. After thinking about it for a while and not getting anywhere, I decided to do a little searching. Specifically, I wanted to know what would trigger the 'suspicous website' warning. I finally found the anti-phishing whitepaper available from Microsoft. After reading through the entire paper, the only 'real' data I could find was the following 4 bullets
· Certification. If Web site owners intend to ask users for personal information, they should have secure sockets layer (SSL) certification.
· Security. Legitimate Web site owners should continually make sure their sites are as secure as possible from outside attacks by maintaining up-to-date firewalls and installing all necessary security updates.
· Cross-site scripting attacks. All Web site owners should be protecting themselves by using anti-cross-site scripting attack tools.
· External content. If a Web site intends to post external or third-party content, it is recommended that the content be secure and from a known and trusted source.
Still with out a whole lot to go on, I decided to take another look at my content. I still had a sneaky suspicion that the problem was somehow related to my live news feed, which made me focus on the last two bullets - Cross-site scripting (XSS) and External content. If you've never heard of XSS, I definitely recommend you do a quick search on it. There is a ton of content available online that covers this type of attack, and it's also explained pretty well in Wikipedia. However, I couldn't find anything that IE might think was XSS.. but I did find something else. Cross Site Request Forging.. CSRF (read c-surf). I believe that this may be what the generic 4th bullet point is referring to. The main mechanism behind CSRF is usually a maliciously crafted URL that is set as the src of an image tag. The image src will be an external domain, but because it's an image and relies on HTTP GET, the browser allows the request even though it is not from the same origin domain. CSRF relies on the browsers built-in mechanism to pass any cookies matching the requested domain, which is how an attacker would get past authentication. There's one more part to CSRF though.. the URL almost always contains query string parameters. The hacker is taking advantage of the fact that he can get a page to perform an action, simply based on an HTTP GET. This is one of the reasons why you always want to stick to reading form post values, rather than using query string params.
So what went wrong? This is still mainly speculation, but I'm pretty confident that the images which are included in the yahoo news feed were the source of the warning. The images themselves all point to an external domain, which from an XSRF perspective is already suspect. But to make matters worse, the image urls all contain query string prams! It looks like yahoo uses a neat technique where you can specify the size of the image using query string params. Unfortunately, when the browser sees http://d.yimg.com/us.yimg.com/p/nm/20070716/2007_07_16t073409_450x308_us_abn_takeover.jpg?x=130&y=88&sig=HM5f64K8BGC1c9I7OdT6fw--, it can't help but to flag this as a suspected CSRF attack - and I don't blame it.
So what can you do? Well, one option would be to create a proxy for the images. You can create your own HTTP handler which simply re-streams the images using a local url. Another option would be to strip off the query string params from the image url - though I'm not sure what the image would look like in this case. You're third option, which was the one I decided to go with, is to use the "Suspicious Website" dialog to report the site as a false positive. Hopefully, if all goes well, you'll be added to Microsoft's whitelist, and the yellow warning will disappear. I'll let you know what happens..
[AL 07.17.2007] UPDATE - Not even 24 hours later, Microsoft has responded to my request, and whitelisted the site. I'm very impressed with the short turnaround..