Friday, 20 June 2008

At about 2015hrs UTC, I clicked a link in an email from one of my subscriptions to view a video sent to me and from there I tried to login. Strangely, rather than being directed back to the video I wanted to watch, I instead found myself looking at a YouTube profile by the name of "LoginForm", 27 of Brazil (the url for which is and I still hadn't been authenticated. There was just one comment on the profile page, auf Deutsch, which translates to "This is only a test" and there had been, at that time, about 2500 visitors to the profile. The user apparently joined in November 2006, had watched 39 videos, but hadn't logged-in for a year.

There's nothing strange about the link in the email (if there had been, I would not have clicked it) so it seems that someone was able to get the youtube login page to redirect to the profile with this name and maybe to cause the login submission data to be POSTed to the profile. I wished I'd had Tamper Data running so I could see what was happening, but I didn't think of it in time. I don't see anything in the source code of the profile page that would receive my cleartext username and password and cookie from the POST data I submitted, but I suppose such code could have been removed once identified. I changed my password as soon as I was able to login which was almost immediately after I sent an email to the security people at YouTube, so they must have either had reports already or else noticed that no one was successfully authenticating. The profile is steadily receiving more views which could be inquisitive people like myself or maybe there's still an issue for some people.

It's a mystery at the moment and, so far, I haven't seen anything written about it.

UPDATE: 21 January 2009

Thanks to the commentor named "Noscript" there is now an answer.  As the commentor says, the redirection to /loginForm is due to the excellent NoScript add-on for firefox.

Specifically, if javascript is disallowed on a page and NoScript is set to "Attempt to fix JavaScript links" then NoScript will attempt to rewrite the link so that the href attribute contains the URL of the page to which the javascript link points.

In the case of the YouTube login page, this doesn't work too well.  Here is the HTML anchor for the Sign In link before NoScript changes it: <a id="button-signin" class="yt-button yt-button-primary" onclick="document.getElementById("loginForm").submit(); return false;" href="#" style="">

and here it is afterwards: <a id="button-signin" class="yt-button yt-button-primary" onclick="document.getElementById("loginForm").submit(); return false;" href="loginForm" style="" title="document.getElementById("loginForm").submit(); return false; #">

NoScript either takes the word in quotes in the onclick attribute or it finds the element with id="loginForm" and uses it's name attribute (it ought to use the action attribute, but in this case there isn't one) and replaces the href attribute with this string so that clicking the link will direct the browser to the relative path "loginForm" which from the root of the site leads us to and straight to the user profile of LOGINFORM.

I think that maybe NoScript ought to be a little stricter about fixing javascript links and to leave them as they are if they can't be fixed in a sensible way.

If you want to prevent this happening then in the NoScript options, navigate to the "Advanced" tab > "Untrusted" tab and uncheck/untick "Attempt to fix JavaScript links"

UPDATE: 21 January 2009 again (and edited on the 26th) NoScript's author Giorgio Maone has fixed this particular issue in version  The current version of NoScript can be downloaded at

The YouTube login form is now correctly submitted to the login page when javascript is disallowed and the LOGINFORM user will soon get no more visits to their YouTube profile from NoScript users!