Online retailer Play.com has been accused of leaking its customers' email addresses to spammers.

Many customers reported receiving a spam email yesterday, offering an Adobe Reader upgrade which requires registration and payment. Some of these emails were sent to unique email addresses that have only been used at play.com, suggesting that the spammer had access to private customer details.

Most complaints relate to an email with the subject line "Get more done, much faster, with Acrobat X PDF Reader. Upgrade Available Now":

One Play.com customer commented yesterday:

"I too received the email this morning. I use a unique email address for each website using the plus addressing feature of gmail; in this case the phishing attack was sent to myemailaddress+play@gmail.com. This is pretty compelling evidence that play.com are at fault."

Although it does seem that Play.com's customer details have been breached, it is not yet clear how this may have happened, or indeed whether Play.com are at fault. In particular, Play.com's privacy policy reveals several other places where leaks could have occurred. Play.com shares data with other business and technical partners to handle orders, process credit and debit card payments and for fraud protection.

Another recipient of the spam was advised the following by Play.com:

"Please be advised that our database is maintained on a secure internal server that is not connected to the internet. No unauthorised access of any kind is available to the network."

Fortunately, most browser software has already blocked the spammer's website as a web forgery:

If the user chooses to ignore this warning, the site offers a download link for PDF Reader/Writer software:

The user is then taken to a third-party site, secureonline-form.com, which requires registration:

Finally, the user must pay for membership in order to obtain the software:

Play.com did not respond to Netcraft's request for comment before this article was published.

Earlier this morning, GitHub announced that it had changed its revision control website to use SSL only; however, a significant flaw in the implementation means that session cookies can still be captured by Firesheep and other network sniffing tools.

Firesheep brought session hijacking to the masses when it was released last month. Ironically, its own GitHub repository includes a github.js handler, which was designed to capture unencrypted session cookies from GitHub users. This allowed novice attackers to monitor shared network traffic (such as public WiFi) and hijack those sessions.

A day after its release, Firesheep's author stated that a basic expectation of privacy should not be a premium feature, referring to the fact that, at the time, you had to pay GitHub if you wanted to use full-session SSL. GitHub's move to SSL this morning should have eliminated the session hijacking vulnerability, rendering Firesheep useless; however, the session cookies used by the site are not always handled securely.

When a user logs in to GitHub, the server sets a _gh_ses session cookie in the client browser. This cookie is not marked with the Secure flag, which means it will be transmitted unencrypted if the user subsequently visits http://github.com, even though that page immediately redirects the user to https://github.com. This means the site's users may still be vulnerable to sniffing tools such as Firesheep.

Netcraft successfully hijacked a session from the GitHub site by sniffing the cookies that were sent via unencrypted HTTP. Many legacy URLs will still point to the HTTP version of the site, so an attacker may not even need to entice a victim into visiting the HTTP site. Once a session has been hijacked, the attacker can freely create repositories, delete/add email addresses and change passwords, so it looks like the sidejack prevention that GitHub implemented a week ago (which did use a Secure cookie) has been undone.

Although GitHub's move to SSL has not yet been implemented securely, it is at least a step in the right direction for Firesheep's author, Eric Butler. When he released the tool on 24 October 2010, he said:

Websites have a responsibility to protect the people who depend on their services. They've been ignoring this responsibility for too long, and it's time for everyone to demand a more secure web. My hope is that Firesheep will help the users win.

GitHub announced the SSL-only change on Twitter this morning, and is expected to publish a blog post about it soon.

Update

GitHub has since fixed the session cookie to be secure. Now that it can only be transmitted over encrypted connections, this makes the site invulnerable to Firesheep.

A years-old vulnerability has been brought into the limelight by an open source FireFox extension which makes it extremely easy to hijack sessions belonging to other Web users on shared networks.

Eric Butler's Firesheep tool makes it remarkably simple for novices to hijack sessions on several social networking sites. Firesheep monitors network traffic and detects when someone visits a website which transmits unencrypted session cookies. The victim's name and photo is displayed by the tool, and double-clicking on that person instantly logs you in as them.

Even though these session hijacking vulnerabilities have been possible for many years, the sheer user friendliness of this new tool is causing a storm of comments on Twitter. No specialist hacking knowledge is required to use the tool – all you need is to be on the same network as your victim. Sending unencrypted data over open WiFi networks has always posed a security risk, and the release of this new tool greatly increases the likelihood of exploitation.

Online banking services typically employ HTTPS throughout an entire session, keeping the session cookies encrypted and thus hidden from eavesdroppers. Due to the computational overheads of providing HTTPS connections, many other websites reserve this secure protocol only for transmitting login credentials, after which the user would continue to use the website over an unencrypted HTTP connection. This is the weakness which allows Firesheep to work, as it makes the session cookies vulnerable to eavesdropping. This type of vulnerability is commonly discovered during Netcraft's security tests, and Butler's new extension greatly simplifies the process of exploiting it on a range of popular sites.

In recent years, the computational overheads of HTTPS have become less significant due to the continual improvements in computer hardware, so more and more sites are beginning to adopt HTTPS for the entire lifetime of a user session. For instance, Google introduced an "always use HTTPS" option on their widely used Gmail service in 2008, before eventually making this the default setting at the start of 2010.

Butler announced Firesheep at the 12th ToorCon conference. The extension already allows session hijacking vulnerabilities to be exploited against 26 different sites, including Facebook, Flickr, Twitter and WordPress. Additional sites can be monitored simply by adding a new script to its existing list of handlers.

Earlier this morning, an Australian teenager discovered a new cross-site scripting vulnerability on twitter.com. Just a couple of hours later, hackers used the same flaw to launch a massive XSS worm attack against Twitter users.

By posting specially crafted tweets, zzap noticed he could get other Twitter users to execute arbitrary JavaScript whenever they moved the mouse cursor over the affected messages.

zzap appears to have discovered the vulnerability shortly after seeing RainbowTwtr's colourful use of CSS injection to display the colours of the rainbow.

Using a similar technique, zzap was able to inject an onmouseover attribute containing arbitrary JavaScript. This was first demonstrated with an "uh oh" message, which zzap recognised as an XSS vulnerability.

zzap (jokingly?) suggested that nobody should tell the 4chan forum about the XSS vulnerability; however, some other users have already started Rickrolling other users by tweeting Rick Astley lyrics in pop-up JavaScript alert messages. It is feasible for much larger JavaScript payloads to be loaded from external websites, which could allow complex cross-site request forgery attacks (CSRF) against authenticated Twitter users.

zzap later demonstrated that it was possible to steal cookies from Twitter users, by displaying the contents in another pop-up message. This could be mitigated to some extent if Twitter used the HttpOnly attribute for their cookies — this would prevent injected scripts from being able to directly access the document.cookie value.

Although the XSS exploits demonstrated by zzap were mostly harmless, some users were nonetheless baffled by the unexpected behaviour and concluded that Twitter had been hacked:

zzap told another Twitter user that the flaw could be used to steal account information, while one of his other examples made the obvious point:

Rather impressively (and also unfortunately), it took less than 2 hours for hackers to exploit this vulnerability in a wide scale fashion. Many users have already been targeted by scripts which attempt to propagate in a worm-like fashion, or load larger JavaScript payloads from external locations.

Searching Twitter for "onmouseover" shows many of the different attack vectors currently being exploited and propagated:

The vulnerability is still present right now, but John Adams at Twitter Security responded to Netcraft within just a few minutes to say they are looking into it.

A backdoor has been discovered among a collection of security testing tools for Firefox.

The rogue Mozilla Sniffer add-on was included in the Web Application Security Penetration Testing collection. This set of tools is popular within the security community, as it simplifies the process of discovering vulnerabilities in web applications.

However, using the Mozilla Sniffer add-on would have introduced an unexpected vulnerability in any application being tested — whenever a login form was submitted, the add-on secretly sent a copy of the URL, password and other details to an IP address presumably controlled by the malicious author.