Re: questions about MIME and XSS in email messages

From: Javier Fernandez-Sanguino (jfernandez@germinus.com)
Date: Thu May 04 2006 - 07:18:00 EDT


offset dijo:
> I have a couple questions about the limitations of XSS regarding
> email messages/MIME types.

As I don't see any answer to this question I'll jump in.

> 1) Is it an RFC standard that if no MIME type is defined in the
> header that the mail client default to plaintext? Or is this
> implementation specific by the authors of the email clients (ie. not
> ruled by RFC rules)

AFAIK, RFC1521 covers how MIME headers should be interpreted by clients.
 From section 7.2 (page 27):

" A body part is NOT to be interpreted as actually being an RFC 822
    message. To begin with, NO header fields are actually required in
    body parts. A body part that starts with a blank line, therefore, is
    allowed and is a body part for which all default values are to be
    assumed. In such a case, the absence of a Content-Type header field
    implies that the corresponding body is plain US-ASCII text. The only
    header fields that have defined meaning for body parts are those the
    names of which begin with "Content-". All other header fields are
    generally to be ignored in body parts. "

> 2) Are there are any scenarios where its possible to trick an email
> client into processing text/html when the header doesnt indicate a
> MIME type and appears to be plaintext even though the XSS code is
> shown (due to lack of input/output validation by the client).

You can trick users to use a link that includes XSS code by using some
http link that does not give away the trick. It will be seen as plain
text, but you can trick users to "follow" it. With a little bit of
social engineering, you could make naive users take the link from the
text and copy & paste it to a browser, thus triggering the XSS attack.

Links that might not give away the attack include, for example, a
tinyurl.com link (notice that it might be a violation of its terms of
service) or a server you control that forces a 302 redirect in the WWW
browser.

HTH

Javier

------------------------------------------------------------------------------
This List Sponsored by: Cenzic

Concerned about Web Application Security?
Why not go with the #1 solution - Cenzic, the only one to win the Analyst's
Choice Award from eWeek. As attacks through web applications continue to rise,
you need to proactively protect your applications from hackers. Cenzic has the
most comprehensive solutions to meet your application security penetration
testing and vulnerability management needs. You have an option to go with a
managed service (Cenzic ClickToSecure) or an enterprise software
(Cenzic Hailstorm). Download FREE whitepaper on how a managed service can
help you: http://www.cenzic.com/news_events/wpappsec.php
And, now for a limited time we can do a FREE audit for you to confirm your
results from other product. Contact us at request@cenzic.com for details.
------------------------------------------------------------------------------



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:55:54 EDT