Outlook Web Access Privacy Hole

By Deane Barker on December 23, 2003

Here’s something a little scary for anyone who uses Outlook Web Access. Watch out for the links you click in emails, because your browser may send a whole lot of information about you in the HTTP Referer header.

Browsing through my log files the other day, I found this as one of my referers (all specific information changed to protect the innocent):


This is the referer that results from clicking on a link displayed in Outlook Web Access. It’s the URL from one of the message pop-up windows. You don’t usually see it because when you open a message, the address line is surpressed in the pop-up. Next time, open a message, right-click on the page, and click “View Page Info” (Mozilla / Firebird) or “Properties” (IE).

From one line in a log file, I have the name of the user and the name of her company. I typed in the domain name, and I got a Web site for the company, with helpful contact information listing a city and state.

Using that information, a Google search turned up her email address, home address, and home telephone number. Within about 60 seconds , I knew where she worked, where she lived, and how to email, postal mail, and telephone her.

Based on my knowledge, there’s no way to protect against this. The browser doesn’t know that it’s exposing a privacy hole by sending the URL of the referring page. The browser doesn’t even know it’s using Outlook Web Access. It could be at CNN for all it knows — browsers just blindly pass along URLs, since there’s rarely any identifying information in them.

I know of no browser which you can configure to not send an HTTP Referer header, though this would be a handy feature.

In the end, this brings up a good point for secure coding: never embed any identifying information in a URL thinking the user will be the only one who ever sees it. Browsers will blissfully pass along those URLs without telling you about it.



  1. Based on my reading of the HTTP spec, this seems to be a browser error. That was a secure URL (https://), so the Referer should not have been transmitted, yet it was.

    I took a look back in my logs and found that she was using:

    “Mozilla/4.0 (compatible; MSIE 5.22; Mac_PowerPC)”

    IE 5.22 on a Mac. Could this be a security hole in that version of the browser?

  2. I did a quick query on my database to see how many referrers come from “https” domains, and this was the only one. More evidence that this is a browser bug.

  3. Grepping through my logfiles I’ve found the following browser signatures with https referers:

    “Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; AGENTOR 1.1)” “Mozilla/4.75 [en] (X11; U; SunOS 5.8 sun4u)” “Mozilla/4.79 [en] (X11; U; Linux 2.4.18-24.7.x i686)” “Mozilla/4.8 [en] (X11; U; Linux 2.4.20-4GB-athlon i686)” “Mozilla/5.0 (compatible; Konqueror/3; Linux)” “Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/85 (KHTML, like Gecko) Safari/85” “Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/103u (KHTML, like Gecko) Safari/100.1” “Wget/1.8.2”

    Maybe the problem is more widespread than thought…

  4. Well, crap, maybe this is just a bunch of vendors ignoring the spec? That doesn’t actually happen, does it? I’m disappointed to find Mozilla browsers in there.

    And there I thought I had found an actually bug. Bummer.

  5. As I once mentioned on my own site (http://jasewells.com/archive/post/121), the problem could be mitigated if systems like Exchange Webmail didn’t include so much personal information in their URLs. When browsers screw up and provide the referrer URL to the target site, not only does it reveal the HTTPS referrer, but you know the person’s name/login, the mailbox they were reading, and the subject line of the message. Better architecture of the webmail URL (i.e., using UIDs instead of mailbox names and subject lines) would at least hide some personally identifying information.

  6. Hello folks. In response to the comment in the intial post: “I know of no browser which you can configure to not send an HTTP Referer header, though this would be a handy feature.”

    In fact, with Mozilla-based browsers this is quite trivial. Open the URL about:config and search for “network.http.sendRefererHeader” — that can bet set to 0, 1, or 2: 2 – default, send referer for all requests 1 – do not send referrer for images 0 – do not send referrer for anything I’ve just confirmed with FireBird v0.7 that the above settings function as stated.

    Additionally, according to Syamtec Docs, the Norton Internet Security and Norton Personal Firewall software products can supress referer as part of the privacy functionality. That should work for any browser, I presume. I have not confirmed this though.

  7. I just confirmed that this works perfectly. Thanks for the tip. I’ll post this as a new item later. It’s something that people should know about.

  8. I just checked the preferences for the iCab 2.9.5 browser (Mac only) and it did have an option to control the referer function to “always”, “never” or “only within same domain.” The setting is under “Network” > “HTTP/DNS”

  9. “I know of no browser which you can configure to not send an HTTP Referer header, though this would be a handy feature.”

    Opera can also do this. Just press F12 and it opens a “context” menu where your mouse is. In that menu you can choose many things such as JavaScipt,Cookies etc. there IS also a option named “Enable referer logging”. You can turn that on an off using that option.

    That is also very quick to change when you get used to it. I use it often when I’m browsing with Opera.

Comments are closed. If you have something you really want to say, tweet @gadgetopia.