I recently started using Facebook and Buzz along with Twitter as public publishing tools. Facebook still sells itself as being for your friends and people you know, which is still completely false. Everything you post on Facebook is public-regardless of your privacy settings, and permanent-regardless of whether you delete it from your wall, but that's besides the point.

The issue I'm writing about today is one where Facebook allows any website to post to your wall as you without your consent (ie: identity theft), as long as you're signed into Facebook. Most people are permanently signed in even when all Facebook tabs and windows are closed by means of a session cookie your browser saves for weeks. Today in my newsfeed there was a link to a video of the tsunami in Japan.

When you click on the link you get taken to a fake youtube page, and are told to verify your age to watch the video. Clicking on the "Verify my age" link takes you to an annoying ad for a malware toolbar, while secretly using your Facebook account to post the link to your own wall and like it. Clicking anywhere else takes you to other sites that infect your computer with viruses and malware.

This malware spreading site happens to be using a live analytics service called amung.us and if you look at the ping response you can see that there are constantly around 10,000 people on the site over the five minutes I kept hitting refresh.

The fake youtube site isn't hacking Facebook or your account, it's simply taking advantage of a gaping security hole in Facebook's API. Any website can embed a hidden Like button, and if you happen to be logged into Facebook on that computer that website can post anything to your wall.

How does it work?

A website loads a hidden Like button on their page, which is just an iframe calling http://www.facebook.com/plugins/like.php with some GET variables. The website uses Javascript to trigger the click action of the Like button posting anything they feel like to your profile without your consent or knowledge. Your friends see the link, trust you, click on it and begin spreading it themselves.

How can Facebook easily prevent it?

Liking a 3rd party webpage should popup a little box that asks for your pin number. Your pin number should be set in your Facebook account settings and be a 4 digit number separate from your password that you're prompted to change every month. This way posting content is a conscious effort on your part, and 3rd parties can't use hidden Like buttons to post to your wall.

I've talked a lot about their unpleasantly ghostly Privacy Policy and Myspace-esk TOS, you know the ones that sign away equal rights and entitlement to your identity indefinitely just by using their site. But I haven't talked about the intrinsic insecurity of a social network like Facebook.

Fact: A significant amount of computer users exhibit insecure behaviour online. They don't use strong passwords, they don't opt for https://, they don't work on virus/keylogger free computers, and they answer spam emails(shocking I know).

Fact: Facebook contains not just a list of all your friends, but all your friends' friends, and a record of your interactions with them. Your social network and scene.

Think about it like this: If someone gains access to your email account, they can see your contact list, and they can see how you talk to your contacts. If they have a lot of time on their hands they can read huge volumes of emails and piece together your relationships.

On Facebook, they can see your list of friends, family, your communication with them, but more importantly their communication with each other. A schematic of your social life heavy with descriptions of how you know each person. Assuming you've toggled your privacy settings back so only your friends can see your stuff, and did so before google indexed your profile and friends list. Every one of your Facebook friends is an attack vector for all the personal info you've posted and that your friends and family have posted that doesn't even relate to you. More clearly A is an attack vector for B, A<->B, C, and B<->C.

In addition 3rd party Facebook app developers also have access to your social circle and information. Your Buddy wants to try an app from some developer he doesn't know? Well they just grabbed your entire social network and know a LOT about you and all your friends.

On Facebook, you are not the only one responsible for keeping your information safe. Anyone you friend is. Would you trust your Facebook friends with your Facebook username and password?

It's given birth to a new breed of highly personalized spam. Imagine getting an email from someone you don't know offering you cheap Viagra and even using your first name. Sounds like a scam right? Sounds like if you clicked on the link you'd probably get a virus or some kind of malware installed on your system right? Right.

Now imagine getting an email from Sarah your old girlfriend, where she talks about something you did the other night at a party (which you posted a photo of on Facebook being careful to only let your friends see) and then telling you she wants you to see a funny youtube video. You click on the link and guess what? It wasn't Sarah at all! "What?!", you say? How's that possible?

The Spammer, we'll call him Spammer, gains access to Jim(your buddy)'s Facebook account because a) he accidentally typed in FaceBack.com without realizing it and tried to login. His credentials were phished and the Spammer was in his account within 30 seconds, or b) Jim(same Jim) adds an application where the 3rd party developer wrote a bunch of code that scrapes all of Jim's and your information and emails it to him(the Spammer) as a .zip file when it's done. The Spammer goes ahead and looks through Jim's friends list, then through yours. Looks through your photos and descriptions of each of your contacts. Looks at Sarah's profile and write's down her email address, attaches the photo to an email, the email spoofs Sarah's email address(this is astoundingly easy without her login credentials from any computer connected to the internet) and adds an html link that looks like this in code:

<a href="http://sitewithavirus/silentkeylogger"> http://youtube.com/v=harmlessvideo</a>

and to you looks like this:

http://youtube.com/v=harmlessvideo

Clicking on the link will obviously take you to the virus and not to youtube and if you use Internet Explorer, or the Spammer is using a zero-day exploit for one of the other browsers, you're fucked due to arbitrary code execution.

A site that gives anyone other than you access to a super detailed schematic of your social circle is inherently insecure. Facebook should not expose your real life social circle to anyone even other people in that circle. But they do and will because a large part of their user retention plays on social needs for acceptance/approval/jealousy/etc. which requires exposing that information to people you normally wouldn't and in a permanent public manner that you normally wouldn't.

You probably found this because you're trying to make a socket connection from Flex/Flash and getting the following error:

SecurityError: Error #2123: Security sandbox violation:

Adobe went through a number of phases making the rules for serving and checking Policyfiles stricter. There are different security sandboxes. If you publish your flex/flash application on domain.com, and the application attempts to load content from domain2.com, it will look for a Cross Domain Policy File at domain2.com/crossdomain.xml to get permission. It does this automatically, however you could specify the location of the Cross Domain Policy File in your flex application using the following method:

Security.loadPolicyFile("http://domain.com/remote_content/crossdomain.xml")

A Cross Domain Policy File only has authority to grant access to content below it in the folder hierarchy. So a policy file in /remote_content/ can't grant access to content in the root folder, and in addition a Policy File at the domain root can override any other policy file. It has maximal authority. Subdomains are considered separate domains - which as a side note most search engines see subdomains that way too.

Now that's Cross Domain Policy Files, In general Adobe Air applications operate in one of the local system sandboxes and has thus have access to content on any domain. This post is about Socket Policy Files. When you access regular web content you're generally connecting to your server on port 80 and being served content by Apache or whatever web server you happen to be running. When you do this you're using http protocols under the hood and never have to deal directly with that crazy stuff. If you want to make a raw socket connection to your server you will need to serve up a Socket Policy File on a specific port.

First I just want to stress the difference between a Cross Domain Policy File and a Socket Policy File. For some reason my dyslexia and the ton of misleading, vague, and now out of date and incorrect information I kept thinking they were the same thing. Second there is no way as far as I'm aware to serve a Socket Policy File with Apache.

The default port for flex/flash to search for a socket policy file on port 843. There are several places on the web that talk about being able to connect to higher port numbers without a Socket Policy File, well that doesn't seem to be the case anymore. Just assume that any raw socket connection from a flex/flash client requires a Socket Policy File.

You can serve the Socket Policy File from the port you're connecting to, but this is tricky considering the manner in which Flex/Flash goes about loading the Socket Policy File and rewriting the service to serve this up, especially if you're using server software built by someone else, means it's just better to keep the Socket Policy File Server as a separate always running entity on the system.

Now in the simplest implementations you need a process either written in python, perl, c++, php cli, or whatever. It needs to be listening on port 843. It has to wait for - very specifically - the following string<policy-file-request/> followed by a NULL byte. Upon receiving that it needs to serve up the policy file which needs to at least have allow-access-from domain set to *, and to-ports set to *. You should use the links at the end of this post to familiarize yourself with the differences between and all options you can specify in Policy Files. It's easiest to keep the Policy File as an actual file, instead of adding the text of the file to your custom server code. And that's it!, now you can go on with a better idea of what information out there is out of date or not.

Here are some important links to help you on your journey:

Adobe on setting up a Socket Policy File Server

Adobe on Policy File changes for flash 9 and 10

Adobe on the structure of Policy Files

An intro to Sockets

Working PHP Cli Socket Policy File Server