Security holes in Hotmail, Yahoo, and other webmails

From: FozZy (
Date: 12/24/01

Date: Mon, 24 Dec 2001 04:08:50 +0000
From: FozZy <>

Hash: SHA1

[submitted to BugTraq -> no answer : yeah, if every hotmail hole was
reported to bugtraq, this could be a DoS against the moderator. However,
I'm sure some Yahoo's bugs affect other web apps and should be interesting
for the security community and developpers. ]


Most webmails services and applications have huge security holes on the
client side.
On Hotmail and Yahoo! Mail, execution of malicious javascript and HTML code
was possible. There were flaws in the HTML filters, and cross-site
scripting vulnerabilites. When an evil HTML message was read, it could
delete emails, launch a webmail worm, steal the session cookie to allow a
third party to gain unauthorized access to the mailbox, etc.
On Yahoo! Mail, it was also possible to automatically manipulate and modify
some parts of the user's mailbox, without use of javascript. This problem
is likely to exist on other web services.


Since these kind of vulnerabilities are NOT new, and a new hole is found
every 6 months, it seems right to say that webmails are not safe at this
time, even if these particular bugs on these particular sites are fixed.
So, users should not use webmails for important or private datas. They should:
- - disable Active Scripting (sadly, many webmails need javascript to
operate properly).
- - disable automatic image loading.
- - view messages in plain text rather than in html, if possible.
- - never click on a link submitted in an email, even if it is to a trusted
- - not rely on webmails as a safe place to store data. Do a backup.


- -- Hotmail

There was a huge flaw in the Hotmail filtering system, when parsing HTML
messages like:
<script> (...) </script>

it becomes :

It looks right. BUT, look at this code:
- -->
<img src="http://none"

After the filtering process I got this:
- -->
<img src="http://none"

And Javascript is executed automatically when viewing the message ! Even if
autoload of images is disabled, there are many other ways to execute
javascript, or insert bad HTML code, since this code is not parsed by the
filter. WoW. So simple and so powerful.

- -- Yahoo! Mail

a) Failure of the html filter to handle a malicious attribute value in HREF

The 'target="_blank"' added by Yahoo when parsing HREF tags can be
neutralized by adding an attribute value containing a '>' character. This
is a variation of the trick Mark Slemko published on vuln-dev, February 2000.
This allowed the link to be opened in the same page. Javascript could then
run in the domain, because the "javascript" string was not
filtered in HREF tags ! (I don't know what was the use of allowing that).

<a href="javascript:...">link</a>
<a href="javascript:..." target="_blank">link</a>
<a href="javascript:..." foo="bar>link</a>
<a href="javascript:..." foo="bar target="_blank">link</a>
   harmful when clicked by user !

b) GET == POST

The user usually navigate through his mailbox by clicking on FORMs (POST
method). But, if the parameters values are supplied in a link with the GET
method, Yahoo cannot say the difference and accepts the input.
This is not a problem in itself but makes things much easier for the
following c) and d) security holes...

c) Cross-site scripting

Cross-site scripting vulnerabilities on the domain was reported
six months ago on Bugtraq by (see This allows a javascript code to steal the
session cookie and send it over internet to a CGI script, which could then
gain access to the mailbox of the user without knowledge of his password.
My tests show that no check on the IP adress of the user (or the HTTP
headers) is performed.

I found that many web pages was still vulnerable to cross-site scripting on
For instance, in the domain, the compose page and the
signature page did not convert special characters in HTML entities in the
"textarea" fields. So, they were vulnerable to posting data containing
something like : "param=</textarea><script>bad code</script>".
This "bad code" could steal the session cookie or manipulate the mailbox
since it is exactly in the same domain.

However, this vulnerability still needs that the user click on an evil link
in a message. But, since it is a link to, it could be trusted by
the user.

d) Automatic manipulation of mailbox

It was possible to perform many actions on the mailbox by posting data to a
predictable URL, without need of giving a particular random string (this is
now fixed). Associated with b), it was possible to automatically modify
some preferences of the user (like the Reply-To address, the signature...),
delete all messages in the Trash Folder, and so on. All of these without
use of javascript, and without user interaction.

The association of b), c) and d) holes could be exploited with the
following scenario (they are many others):
- - User reads an email with a malicious <img
Javascript code is inserted into the preferences of the User [b][d]. User
notices nothing.
- - Later, user opens his Preferences web page.
- - Javascript is executed [c], showing a fake Yahoo "re-enter password" page.
- - Password is stolen and sent to a third party on Internet.
- - The preferences page is opened.
- - User is unaware the integrity of his account has been corrupted.

ATTACHED: the message I used to test Yahoo's bugs.


12/04: Microsoft informed.
12/11: Hotmail problem fixed. Very nice, very quick. Thanks !

12/04: Yahoo France informed.
12/07 : Yahoo USA informed.
12/13: Most Yahoo! Mail problems are fixed.
12/23: I have no news from them about the few bugs that remain.


I will publish a technical security paper explaining known vulnerabilities
and tricks used to bypass protections of webmail services. It will help to
perform audits, will increase the users and developpers understanding of
these problems, and (hopefully) will open the way to a better privacy.
Due to the fact that 80% (if not 100%) of webmails services and
applications seem to have serious security problems, I suggest that
webmails developpers send me their certified PGP key so that I can give
them this text, before I release it to the public on BugTraq and in <ad>
"Hackerz Voice International Edition" (</ad>.
Note that the scope of these vulnerabilities is not limited to webmails.

Thanks to: Uzy.



Independant security consultant
Hackademy member of staff, Paris.

Version: PGPfreeware 7.0.3 for non-commercial use <>


Relevant Pages

  • Re: Web browser in Ada
    ... JavaScript language itself would still be a risk. ... (The vulnerabilities being listed in the Top 25 ... Being less prejudiced against Ada ... HTML parsing and rendering, CSS handling, etc, etc)... ...
  • Re: HTML4.01 STRICT and hyperlinks with target
    ... new window *in HTML* instead of in JavaScript. ... have a link open a new window in HTML instead of in JavaScript. ... I know this is not a great reason, but I think it is reason ...
  • [Full-disclosure] [RT-SA-2009-001] IceWarp WebMail Server: Cross Site Scripting in E
    ... RedTeam Pentesting discovered that the IceWarp ... WebMail Server is prone to Cross Site Scripting attacks in its email view. ... To prevent the execution of JavaScript and VBScript code in HTML emails ... and to remove unwanted HTML tags, the IceWarp WebMail Server filters HTML ...
  • [RT-SA-2009-001] IceWarp WebMail Server: Cross Site Scripting in Email View
    ... RedTeam Pentesting discovered that the IceWarp ... WebMail Server is prone to Cross Site Scripting attacks in its email view. ... To prevent the execution of JavaScript and VBScript code in HTML emails ... and to remove unwanted HTML tags, the IceWarp WebMail Server filters HTML ...
  • Re: No TABLES in html. No hacks in CSS. Any layout possible, crossbrowser. Try it.
    ... Disable JavaScript, like ~10% of your visitors, and look at your ... HTML and CSS can do much more than you seem to realize. ... transitioning from? ...