9

I recently stumbled upon a really silly/unsafe but an interesting way to get a read receipt of an e-mail. I'm not 100% sure if the method in use works, which is why I'm asking it here.

G-mail does not have read-receipts. So, I got this e-mail from a reputed company, a trusted source but G-mail had blocked the images on the page. Since it was from a trusted sender, I did click on "Show pictures in this email". I didn't see a picture there. On looking at the source, I saw an <img> tag with a src to a link which I think is a way to find out if the message was read by me.

My question :

  1. Will this work ? Will the same origin policy prevent the request from going through or does the src in the <img> tag always issue a GET request

  2. Is this legal and has anyone else seen this in practice? If it is not, I have a good mind to report this to the concerned company.

Extra Question

If this is indeed possible, then why wouldn't something like : <img onload=alert('XSS') src="some-path.jpg"> work ?

sudhacker
  • 4,260
  • 5
  • 23
  • 34

3 Answers3

15

This is a fairly common practice called a web bug, it is the main reason that mail clients do not automatically load external images (the second being to protect you from viewing unwanted spam images that could be unsettling; e.g., pornography).

Basically when you load an email with external images enabled and a link to an image like <img src='http://192.1.1.1/images/53512_58925.png'> is in the source, their web server will log something like the following (example below is default access log for nginx web server) when your browser/mail client fetches and downloads the image: 

10.1.2.3 - - [10/Oct/2012:10:33:41 -0400] "GET /images/53512_58925.png HTTP/1.1" 200 1933 "http://192.1.1.1/images/53512_58925.png" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.81 Safari/537.1"

which gives them:

  1. your IP address of your computer where you viewed the email (10.1.2.3 in this example),
  2. the timestamp of the access by the server's clock [10/Oct/2012:10:33:41 -0400],
  3. the (first line of the) HTTP GET request to get the image (GET /images/53512_58925.png),
  4. the HTTP response code (200 meaning success),
  5. the size of the file being accessed (1933 bytes),
  6. the full URL of the file (192.1.1.1 is IP of email sender's server), and
  7. the User-Agent string of the client (indicating what web browser and possibly OS you are using).

To really track you accurately, they would need to have a unique URL for the image; e.g., the file 53512_58925.png could mean that user 58925 read the email with the ID 53512 or something. They could also do something with HTTP GET parameters something like <img src='http://192.1.1.1/images/logo.png?user_id=58925&email_id=53512'> that would also be logged.

I'm not going to comment on the legality of it; laws vary and some countries that I do not live in have recently enacted strict IT privacy laws (e.g., against a similar policy cookie tracking without explicit user consent). Also this forum is not really intended to provide legal advice.

This has nothing to do with same-origin policy (used for limiting the power of remotely loaded client-scripts in languages like javascript; so going to unsafe-web-page.com shouldn't be able to read/modify browser data in other tabs) or XSS (where attackers exploit flaws inject content in web pages that are not their own).

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • They also get any and all cookies you have stored for the web site used in the URL and/or domain of the src URL. – HeatfanJohn Oct 10 '12 at 22:10
  • Well, yeah, the current method used is not a typical XSS. My point is, if this is possible, one might as well put malicious content on the `img` tag such as `` Is there any reason this might not work ? – sudhacker Oct 11 '12 at 12:16
  • @asudhak - Well that's a different question. Every modern (released in past ~5 years) email client/web mail site I've ever seen, sensibly disables javascript from running in an HTML email (and as a quick test both thunderbird and gmail block your example even when images are loaded). See: http://javascript.about.com/od/reference/a/jsemail.htm or http://stackoverflow.com/questions/1088016/html-email-with-javascript . – dr jimbob Oct 11 '12 at 16:57
  • @HeatfanJohn - Yes. They can get access have a bit more info then in the default webserver logs; cookies that your browser has associated with their domain. I don't see this as a problem; e.g., if you have previously visited `example.com` in the same browser and they set cookies, and you later open an html email from `example.com` with images set to load, then they can see the cookies they have previously set for you (that were only modified by `example.com`). Though I should have mentioned that they can see http-referer header which for a webmail client indicates what webmail you use. – dr jimbob Oct 11 '12 at 17:05
4

Embedding an image in an email would (if unblocked) fire a HTTP GET for the resource linked in the src field. When it does so, one can get the ordinary "Google Analytics level" of information (+ IP), i.e. Referrer, Browser version, etc.

If the resource does not exist, there will still be a log entry of the GET at the server side when trying to resolve it.

Henning Klevjer
  • 1,815
  • 15
  • 20
1

Yes it will work and I see no reason why it would be illegal.

However, you've already hit upon the main problem with doing this - the person reading the email must push "Show pictures in this email" (or equivalent) for it to work.

There are companies out there that offer this service, such as SpyPig and DidTheyReadIt

Andy Smith
  • 2,742
  • 18
  • 24
  • Well that surprises me. And I would argue that it should be blocked. This is simply using XSS to gather information about the client. It could very well be a malicious link to which the `` is pointing to. – sudhacker Oct 10 '12 at 14:24
  • 1
    It's not XSS - it's just HTML. And it is blocked - by default by gmail and many providers - but you can unblock it (by pushing "Show pictures in this email") – Andy Smith Oct 10 '12 at 14:29