Note: For some background on HTTP authentication and username/password caching, see HTTP Authentication: a Primer.

I was reading Schneier yesterday, and it reminded me of all those MySpace and similar worms going around. Why are they so bad? How will they get worse in the future? Their biggest problem is that they welcome everyone, making it easy for bad people to establish themselves. The second is that even though the sites themselves are not high-security, they have security implications for other sites, including high-security sites.

MySpace is scary because it enables a very large number of people to post content your browser will parse and possibly execute. Further, they’re casual sites, so don’t have the same level of security urgency or corporate paranoia as a bank obviously needs (the reality of bank security is a different matter, but the expectation is higher for Citibank than MySpace). The other concern is that people and their browsers (often on auto-pilot, for both people and browsers) enter login information routinely to access these sites.

This makes community sites a rich target for attackers – especially since many people use the same username & password for MySpace and electronic banking (and everything else)! Those people who get hacked on MySpace, and then immediately on their electronic banking sites, are screwed. But at least everybody can say “You should have known better.” It doesn’t help much, but is important to both MySpace and the banks for liability reasons. And it’s true – in 2006 you’re asking for trouble if you use the same password for your bank as a low-security site like MySpace. This isn’t to confuse the victim with the perpetrator, but we have to expect more self-defense than that. We can’t provide all the security everybody needs – they have to help! But site developers must make the assumption that every user has exactly one username and password, which they use everywhere, and make every effort to protect that password (this means not storing accounts in a plaintext MySQL table, not showing passwords to customer service/support staff, and not emailing passwords on request – reset them and email the new random password to the address on file).

Crossing the Line

So there are high-security sites, and low-security sites, and people can understand that banks are better guarded (physically and electronically) than lots of other places (perhaps not as well as sports & concert venues, though). When this line is erased or faded, risk increases.

For example, Apple hosts user web pages through its .Mac online service. Amazon encourages people to post reviews of books and other products. Do these have security implications? Of course (everything does, actually).

Scenario: Harry the Hacker gets a free .Mac trial account, posts an evil JavaScript that records username, password, and all cookies, to his new disposable site on Apple’s .Mac servers, and starts collecting data. Community sites often attempt to block JavaScript, but it’s an ongoing struggle. What does Harry get? With a working JavaScript, it’s easy to capture usernames & passwords from all the .Mac subscribers who logged into their own sites or just auto-enter credentials (disclaimer: I don’t know how .Mac uses cookies). Some substantial percentage of these passwords work on banks, as we’ve already discussed.

Can Harry grab people’s store.apple.com accounts this way, to order a brand new Mac Pro? Not directly, at least, because store.apple.com and homepage.mac.com are different domain names, so their account information is stored and accessed separately; the same goes for the iTunes Store. Naturally, Apple’s doesn’t give .Mac users posting access to store.apple.com. So Apple’s okay here. Not great, but I don’t see a solution aside from not authenticating to .Mac at all, and that wouldn’t work. Note that the problem is made worse by the fact that Apple pushes people towards using a single “Apple ID” for all Apple services, and further requires 1-click ordering to be enabled for at least iPhoto print orders, which makes .Mac password compromises more severe, by linking them to active credit cards.

There’s an ongoing dynamic tension between making the site richer and more capable, and limiting it to prevent ‘mischief’. MySpace is clearly possible partially because it’s so flexible. Every security restriction is necessarily weighed as a potential detractor from ease of use, power, and popularity.

What about Amazon? They put user content on the main amazon.com shopping site! But I believe what they allow is much more restricted HTML, and there’s at least some editorial review, so they’re probably okay.

I’m sure more problems will appear over time, as people add community functionality to more and more sites, for feedback, documentation, etc. I recently had to think long and hard about sending a financial document to an ISP based on a publicly-editable wiki page (it’s no longer editable, but there’s still plenty of potential for mischief there). It’s a wiki – I didn’t even have a guarantee that the offer on the page was real. I eventually decided the page and fax number were almost certainly legitimate (they were), and the risk was very small, but that doesn’t mean the next such page will be copacetic. People have asked me a couple times to add CMS-type functionality to the website for our 31-student co-operative pre-school, so it’s clear that interactive “community” features are not stuck in a MySpace-type-only ghetto.

This is an issue that all web developers must keep in mind as they consider user contributions and interactivity or their sites: What does it do to our existing security model? Do we need to draw a stronger line between official/ecommerce/corporate and public/collaborative/non-binding/untrusted?

Note that this isn’t a Web 2.0 issue. Various companies have been mixing employee and customer email domains for years. I believe Netscape used to provide @netscape.com email addresses to subscribers. What a great opportunity for spam!

From: update-service@netscape.com
Subject: Urgent Netscape Upgrade

Please go to update-service.netscrape.com to get an important security patch for your Netscape browser!

It’s quaint now, but 5 years ago lots of people used Netscape, and there are still companies mixing employees and subscribers on a single domain. If you get email from support-rep42@earthlink.net, how do you know if the sender is Earthlink tech support on legitimate business? Remember, with phishing and spam, the assumption is that most people won’t fall for it. You just need a small fraction to make money.

Usernames, passwords, and login cookies are all highly vulnerable to anyone who can put code onto the server, whether it’s ASP, Java, Cold Fusion, PHP, Ruby, or something else. SSL doesn’t help with this, as it merely protects communications between the user and the compromised server; it doesn’t affect what happens to the data once it reaches the server, although browsers can be a bit more paranoid when they’re running in SSL mode, warning about mixed content that would be silently accepted in non-SSL mode.