17

I'm curious if there is a way to execute XSS via email.

I am not talking about using e-mail as a way to deliver a link that has reflected XSS in it.

I'm talking about sending an email from example.com and having javascript in that e-mail that executes as if it is executing on http://example.com (i.e. gets passed the browser same-origin policy and can read the response of an xmlhttprequest).

The first answer talks about sending an email from example.com to a user of gmail.com that could be used to attack gmail.com. It also mentions problems in Thunderbird but doesn't clarify if those would allow attacks on example.com (i.e. the origin of the mails) or somewhere else.

greggles
  • 560
  • 1
  • 8
  • 20

2 Answers2

17

Yes, this is a very serious concern when it comes to reading your email via a web browser. In fact gmail has had this happen a few different ways. In a broader sense, XSS within an email could be used to spread an email based worm. The XSS payload has access to your list of contacts and the also the ability to send email as you. This is similar to the Sammy XSS Worm.

When it comes to a client like, Outlook or Thunderbird this really isn't much of a concern because the context in which the script executes is mostly useless to the attacker. Although this type of vulnerability has happened and this type of XSS could be useful for delivering a client-side exploit such as a html or javascript based buffer overflow. The pairing of XSS in thunderbird with a buffer overflow would lead to a very nasty email worm.

D.W.
  • 98,420
  • 30
  • 267
  • 572
rook
  • 46,916
  • 10
  • 92
  • 181
  • 5
    This is especially troubling because tools such as NoScript will happily allow the javascript to run because it is being served from a domain you trust. – Ladadadada Mar 10 '12 at 08:18
  • I think this mostly answers my question by exclusion (it's a tough topic to describe). I'm updating my question to try to make it more direct. Thanks for the answer so far! – greggles Mar 12 '12 at 21:11
  • @greggles i am not sure what you mean. The img onload exploit is exactly what you described, and that is worm-able. This is an email that contains javascript and is executed when it is viewed. – rook Mar 12 '12 at 21:21
  • 1
    +1, but it should be noted that as of today, Gmail does sanitize (or attempt to santize) any scripts in email. If you do happen to find a 0-day vector, it probably wont remain open long... – AviD Mar 13 '12 at 11:33
  • 1
    @Rook - the img onload exploit may be what I described, but I'm afraid I don't follow the full attack scenario. If you could lay out the attack scenario it would be helpful to me. i.e. which domain sends the mail, which domain(s) are vulnerable, and whose responsibility is it to filter the javascript? – greggles Mar 13 '12 at 13:34
  • @greggles See: http://en.wikipedia.org/wiki/Cross-site_scripting – rook Mar 13 '12 at 14:38
  • @greggles xss must always be filtered when the text is displayed. This is always true for every system ever. In general it should not be stored in an encoded state. – rook Sep 05 '12 at 00:59
  • I don't agree with the absolute nature of the latest comment - for example, there are systems to "display" text via a phone call. Doing xss filtering could end up with the voice reading out ampersands and semi-colons...Different contexts require different kinds of filtering. – greggles Sep 06 '12 at 15:06
  • @greggles Aaah well good thing I said: "reading your email via a web browser". And as you know XSS filtering should always be done on display, so this should have no effect on other devices. It would be foolish to perform html filtering on storage. – rook Sep 06 '12 at 15:53
  • Well, no, in your Sep 5th comment you didn't say "via a web browser." And if filtering should always be done on display then it seems like it should be up to the email provider to filter the email? And...my question was not about example.com as the email provider but about mail sent from example.com and read anywhere else on the internet. – greggles Sep 10 '12 at 15:34
  • @greggles oah I thought that was obvious. – rook Sep 10 '12 at 16:08
13

The answer to your question is "Yes", but you're asking it wrong. Nowadays XSS via email is only really relevant when reading an email with a web browser. Modern mail clients no longer parse scripts by default.

The mail service in which you're reading the email (as the target/victim) would need to have an available XSS injection point for an attacker to take advantage. This has been seen before in more than a couple services, but is still easily and quickly fixed, so the problem is rare.

You mentioned that the email was coming from @example.com, but that is of no concern to any possible attack. In the past I've primarily seen the issue arise when the mail service improperly filters mail headers or user info that then allows code injection.

And to address the last part of your question: Your code will be executing under the domain of the mail service it's being run under. It would only be able to execute under example.com if you also found a XSS vuln in example.com and were able to call that from the mail service XSS injection.

ShaneB
  • 256
  • 1
  • 4