FetLife has had a lot of security issues in the past, which I think most people aren’t aware of. I’ve been meaning to write about some of them (and my experiences in reporting them and how FetLife has reacted), and since suddenly security of the site has become a big discussion topic due to Maymay’s proxy, I figure this is as good a time as any. This post is long, but it’s long because FetLife has had that many security issues.

Long story short: FetLife has had a lot of serious security problems, and has (in my opinion) done a horrible job reacting to them—in at least one case knowing about serious flaws for at least a year before fixing them. What’s more, for almost the entire time the site has existed, it was possible for any user to take over another user’s account entirely (allowing to do things like reading private messages). I’m going to make the case that FetLife seems to care more about people thinking that the site is secure than actually making the site secure. You may say “well, of course there are security problems; it’s the Internet”; the fact is, though, that FetLife has had far more than its share of very basic flaws, and has furthermore done a terrible job of actually informing its users about the risks, and that puts everyone on the site at risk.

One problem with talking about security issues is that they tend to be pretty technical, relying on subtle details of how web technologies work. I’m going to do my best to keep the “what does this mean for you” separate from the technical details, and you should be able to skip over any of the “technical details” sections without missing out on much.

It’s also worth mentioning that all of the major security issues I’ll be going into detail about have been fixed. I’m trying to be very careful not to open any doors to attacks; instead, I’m mostly describing things that could in the past have been used by malicious users to compromise the security and privacy of other users, but can no longer.

Cross-Site Scripting

Let’s start with one of the earliest and biggest security problems the site had: cross-site scripting (or XSS) vulnerabilities. These are bugs that allow an attacker to insert some code into a page to do whatever it wants, as if another user had done it.

To give you an idea of what a malicious user could have done with these bugs, here’s a partial list:

• Reading someone else’s private messages
• Sending private messages as another user
• Moderating someone else’s groups, including editing and deleting posts
• Finding another user’s email address
• Finding another user’s IP address
• Finding another user’s password (see below—passwords were originally not stored securely)
• Make posts as another user
• Add or delete fetishes of another user

One of the scarier implications of this is that it would have been possible to write attack code that would spread from profile to profile, stealing emails, passwords, and IP addresses. How? Well, whenever you add a fetish, it appears in all of your friends’ feeds. If it contains malicious code, it will run for anyone viewing your feed as well… and so in turn in can appear on each of their friends’ feeds, and so forth. (Incidentally, this is essentially how the MySpace worm in 2005 worked.)

The sad reality of the web is that these kinds of flaws are pretty common: many sites have XSS vulnerabilities that can be found by looking hard enough. FetLife, though, had them pretty much everywhere. You could embed code in topics for private messages. You could embed it in fetish names. You could embed it in your orientation. About the only place where they did seem to make any effort to prevent it was in the bodies of messages, but even then the protection they had was inadequate: it was still possible to embed code in links. Cross-site scripting is a very basic web security issue that everyone who does web development should know—this isn’t something terribly advanced; it’s something that should have been covered in any decent course on web development. It’s pretty clear that John Baku either wasn’t aware of it, or made no effort whatsoever to prevent it.

What really bothered me, though, is how FetLife reacted when I contacted them about it. I first reported the flaws sometime early in 2009, and got an acknowledgment that they did exist, and that they were working on fixing them. In March of 2009 I got another email from John Baku asking for more details (which were mostly irrelevant). But it wasn’t until February 2010—about a year after I first reported the issues—that they did anything about them. (Even then, one place where XSS code could have been inserted wasn’t fixed—but to their credit, they closed that hole within minutes of me reporting it.)

Nobody is perfect at security (even though these particular holes were ones that even a novice web developer should have been able to avoid), but knowing about such a significant hole for over a year, and not fixing it, is inexcusable. (And it wasn’t for lack of time or resources: during that year, several features like videos were added to the site.)

Technical Details

Most of it really was run-of-the-mill XSS. A few of the places Javascript could be embedded were slightly non-obvious, though: for example, even though things like “orientation” were pull-down boxes, the site originally did no validation whatsoever about what was sent, meaning that those fields could be used for XSS. As for embedding Javascript in the bodies of messages (which did filter HTML, and which used a version of Markdown), there was no checking that links started with “http:"—so it was possible to include “javscript:” links which could have carried out XSS attacks.

Password Storage

One of the basic rules of web development is to never, ever store someone’s password as is. Instead, the passwords should be “hashed”—scrambled in such a way that they can’t be unscrambled. When a user logs in to the site, it’ll scramble the password in exactly the same way, and then compare the two scrambled passwords to see if they’re the same. This way, if someone breaks into the site and steals the password database, all they get is a list of scrambled passwords, not a list of actual passwords.

FetLife does this now (as they brag on their privacy page), but they didn’t always: it wasn’t until March 2009 that they started to do this. Even worse, the site would tell you your old password when you visited the “change password” page. Combined with the XSS attacks described above, this meant that anybody could steal your password. If you used the same password on other sites, the damage from that could go far beyond your FetLife account.

Data Validation Issues

Web browsers can send whatever they want to a web server. Web pages can politely ask that they send only certain things—when you change your orientation on FetLife, for example, the site asks your web browser to only send an orientation that appears in the drop-down list. But there’s nothing stopping a browser from sending whatever it wants (and there are plugins/extensions for many browsers to allow them to send whatever you want them to). “Never trust any data from the user, and always double-check it” is another one of those basic web security rules.

FetLife, originally, didn’t seem to realize that.

As a result, a bunch of things were possible. Some were arguably good things: a user could set their gender or orientation to something not in the list, for example. But more worryingly, they could set it to include code for cross-site scripting attacks (see above). A user could also moderate groups they didn’t own (including editing or deleting posts), and anyone could appoint themselves as a leader of any group.

Technical Details

Profile fields like orientation and gender could be set to any value, relatively straightforwardly: just change the form information that was sent to the server; it would blindly accept whatever you sent it.

The bugs with group moderation were more interesting. The URL for a post in a group looked like this (remember, this was before FetLife used SSL!):

http://fetlife.com/groups/311/group_posts/516055

Note that this contains the number of the group (311) as well as a number for the post (516055). The post number is global: the next post on FetLife, no matter what group it happened to be in, would have number 516056. That means that the group number is redundant: each post belongs to only one group, and so knowing the post number should have been enough for FetLife to know what group it was posted to (that information is all contained in its databases).

Unfortunately, FetLife trusted the group number in the URL. If I wanted to edit this post, I would create a new group—let’s say it ended up being group number 400—in which I’m the moderator. Then I visit

http://fetlife.com/groups/400/group_posts/516055

(the same URL, with the group number changed). FetLife shows me the same post, but (for me only) thinks that the post is part of my own group. It therefore lets me, as the moderator of group number 400, do whatever I want to it—edit it, delete it, lock it, or anything else a moderator can do. There would be no sign at all that I’d done this.

Appointing someone as the moderator to a group was similar. Just as posts get global numbers, entries of the form “user X is a member of group Y” each have a number. Let’s say that entry number 12345 was “Kirr is a member of Kinky and Geeky.” Visiting a URL such as

http://fetlife.com/groups/400/group_memberships/12345/mod_promote

would promote me to be a moderator of Kinky and Geeky—it wouldn’t check that the person visiting that URL had permission to do it.

Finding out the entry number was the only challenge, but it turns out there were relatively straightforward ways to do it.

Cross-Site Request Forgeries

Almost exactly when the cross-site scripting vulnerabilities in the site were fixed—within a couple days at the most—a new kind of vulnerability was introduced into the site. It was a form of cross-site request forgery (or CSRF) vulnerability. This would have allowed an attacker to do many of the things that they could have done with the XSS attacks, including changing someone’s password.

Whenever you change your password on FetLife, your browser will send the relevant information to FetLife—in effect, saying “hey, can you change my password to ‘hunter2’?” The problem is that other websites you visit can tell the browser to do the same thing: “hey, tell FetLife that you want to change your password to ‘hunter2’,” and your browser will do it. The way to fix this problem is to include a secret number: when you visit the “change password” page on FetLife, it will instruct your browser to send some secret number (known as an “authenticity token”) along with the new password; this number is different for every user on the site. If some malicious site asks your browser to tell FetLife to change your password, it will refuse because the secret number won’t have been there or won’t have been correct.

When FetLife was first launched, it included protection against CSRF attacks, in pretty much exactly the way I described. It seems like the developers might not have realized that these authenticity tokens were essential for the site’s security, though, and so they were removed when the XSS bugs were fixed.

I first reported these bugs in August 2011, and a few days later got acknowledgments from James Lennon and John Baku that they were working on fixing them. About a week after I reported the bugs they were fixed (certainly better than the year it took to fix the XSS bugs!), but by December the bugs had returned. This time they took about two months to fix them again (a very long time to fix something as serious as this), with no communication with me during that time.

FetLife had made a big deal about fixing the XSS flaws, but were completely quiet about the CSRF issues: there was no mention in the announcements group or the changelog that these flaws had ever existed.

Technical Details

FetLife includes a form field called “authenticity_token” to protect against CSRF attacks. This field and the checks for it were removed when the XSS flaws were fixed. When FetLife fixed this bug, they didn’t do it by adding in the authenticity token again—instead they did it by checking certain headers that can in theory only be sent using Javascript, and so FetLife would be protected against CSRF attacks due to Javascript’s same-origin policy. (This solution is not a very good one, and is fragile in many ways). When the bug re-appeared and was fixed for the second time, they finally went back to using the “authenticity_token” form field.

SSL Issues

FetLife makes a big deal about SSL (the technology that encrypts pages being sent over the Internet so they can’t be read by third parties), even saying on their homepage that “We have a fetish for security. That’s why we’re the first social network to be 100% SSL. The same security banks use.” There’s a lot that’s wrong with that.

First of all, Google+ did it before FetLife (and FetLife even said so in their announcement of SSL support).

But second, simply having SSL isn’t enough. It’s a complicated technology, and there’s a lot that can be done wrong in ways that jeopardize the security of it. Second, it’s only one part of the security of a site. Think of it this way: you can install a really fancy, expensive, impossible-to-pick lock on your front door… but if you leave all of your windows wide open, it’s going to be useless. Having a good lock is necessary for security of your home, but many other things are necessary too. SSL is the same way. (The XSS and CSRF bugs, in fact, were totally independent of SSL—they’d work just fine with or without it.)

In particular, there have been many problems with FetLife’s use of SSL. Here are some of them:

• Originally, FetLife used SSL only on the login page. This would in theory protect passwords, but nothing else—an eavesdropper could still see everything you did on the site, and even use the site under your account (similar to how Firesheep worked). In fact, an eavesdropper could have taken permanent control over another user’s account; see MayMay’s post for details.
• Even then, FetLife’s use of SSL wasn’t adequate to even protect passwords: the page with the login form wasn’t encrypted; just the page it sends it to. An attacker could take advantage of this to send the username and password anywhere on the Internet. (This does require a more sophisticated attacker than the attack Maymay described, but it is still a feasible attack.)

As far as I can tell, though, their use of SSL has been better ever since they moved the entire site to SSL. (As mentioned, though, other security flaws could and did still entirely negate any benefit from SSL, which makes their advertising very misleading.)

One Non-Bug: Image Hotlinking

In recent discussions about privacy that resulted from Maymay’s proxy and FetLife’s reaction, several people have mentioned the fact that you can hotlink images, and anyone (logged in or not) can see them if they have the link. This is usually brought up as a big privacy issue, but the reality is somewhat more complicated than that.

First things first: it’s true. For example, https://flpics1.a.ssl.fastly.net/27/27238/0004a965-… is the direct URL for one of the images on my profile. If you visit that, you’ll see the image. Even if you’re not logged in, and even if I make the image friends-only, and even if I block you on FetLife. How bad is this?

Actually, not very. Anyone with the URL also could have downloaded the image and reposted it anywhere else; from a technical point of view, anyone who can see an image can save it and do what they want with it (though there may, of course, be legal issues with doing so). This lets a user share a URL rather than the image content, but that’s not a huge difference. And this is something done by almost every major website, including Facebook.

What’s more, “fixing” this problem could actually open up another. If pictures return an error to non-logged-in users, any website could tell if a visitor is logged in to FetLife. This could be used for tracking, for ad targeting… possibly even more nefarious things. (Imagine if an anti-BDSM website started collecting the IP addresses of all visitors who were also FetLife members—if FetLife didn’t allow hotlinking of images, that would be possible). There are ways around it, but they can end up adding a lot of complexity to the system, opening up the potential for still other problems.

So while it’s kind of unfortunate that hotlinking of FetLife images is possible, it’s not as big an issue as people make it out to be (as long as the users are well-informed, which FetLife needs to do a better job of). Furthermore, the alternative could end up being an even worse privacy problem. This isn’t the fault of FetLife; this is the fault of how Web technologies ended up.

Technical Details

See this article, for example, for a description of how similar attacks have worked. The key point is that it’s possible for Javascript to detect if an image loads successfully or not; it’s therefore important for all images on FetLife to load regardless of whether the person requesting them is logged in to the site or not.

Other Things

The bugs I’ve talked about above aren’t the only ones the site has had. Here, briefly, are a few (more minor) others, in case the ones above didn’t drive home the point. (I won’t go into much detail on most, because some of these are still problems in the site.)

• There was a way to tell if a user on chat, who was marked as “invisible,” was online. (To their credit, they fixed this one quickly when I reported it.)
• It’s possible to tell if a certain post is deleted or just friends-only, and to tell if a user has friends-only photos (but you still can’t view them).
• It’s possible to bypass the protection FetLife has against saving images. (This isn’t FetLife’s fault, but see below for why this is still a problem.)
• It’s possible to change certain things about another user’s account. (I don’t want to go into any more detail on that, because this bug still exists. As far as I can tell, though, it’s unlikely it would be able to cause any serious harm.)
• FetLife in theory requires you to enter the current password on the “change password” form for verification, but there’s a way around that. (Fortunately, attacking an account based on this requires already having some form of access to that account.)
• It’s possible to tell if someone is using a given email address for an account. (This is fairly minor, but keep in mind that you have unlimited guesses.)

Communication About Security

Security and privacy are not only technical issues. Part of any good security or privacy system is making sure that the users are well informed about the limitations of the system. This is especially true of sites like FetLife, where most users aren’t able to evaluate the security of the system—they have to trust what other people say about it.

There are many places where FetLife falls short:

• As mentioned above, FetLife likes to point out SSL as proof that they’re super-secure. This is really, really misleading. Furthermore, they talk a lot about how much they care about security, even though their security track record has been terrible—and often, they don’t communicate at all about serious security problems in the site.
• FetLife has a feature where it will attempt to prevent people from saving images. The fact is, this system doesn’t work: anyone with any technical knowledge can bypass it in seconds. This isn’t FetLife’s fault—if your browser can display an image, you can save it—but FetLife has done nothing to inform or warn users of that fact, leading many to believe that their images are safe and can’t be saved. Many people have uploaded images, and set them public, which they wouldn’t have if they’d known they could be saved.
• And, finally, FetLife gives the impression of being “private,” while it really isn’t. Anyone on the Internet can make an account and see anything on the site, and so you shouldn’t post anything to it you wouldn’t want anyone on the Internet to see. This is the point Maymay was trying to make with his proxy, but FetLife’s reaction to it is the opposite of what it should be. By effectively saying “we fixed the problem; all of your information is safe,” they’re giving people the impression that what they post here is private. What they should have done is reminded people that anyone at all could (and still can) do what Maymay did, and reminded users to treat FetLife as public, not private. Their reaction is one that will lead to users of the site being less safe, but thinking that they’re safer.

Conclusion

It’s pretty clear to me that FetLife wasn’t designed with security in mind at all, and that the developers of the site don’t care much at all about the actual security of the site, just about the perception of security. This kind of attitude is harmful: it means that the users of the site often aren’t educated about actual problems and complexities, and have false expectations about how much personal information they are potentially exposing. FetLife really needs to take security more seriously, but also needs to take honest communication about it more seriously, and to stop pretending to be really secure when they know they aren’t.