Jouko Pynnonen posted a message to the Full-Disclosure mailing list today, citing multiple “script injection” vulnerabilities within Facebook. I’m not sure if this is a surprise to anybody out there, it’s certainly not to me, as numerous web applications have major problems with Cross-site Scripting vulnerabilities, but I think this is important to note due to the widespread use of Facebook.

Facebook and other social networks that are heavily populated are increasingly drawing the eye of security researchers and hackers alike, as due to the heavy amount of traffic they receive, they provide an excellent attack deployment point. In fact, there will be a wonderful talk this year at Black Hat Las Vegas 2008 on attacking Social Networks, called “Satan is on My Friends List: Attacking Social Networks“, by Shawn Moyer and Nathan Hamiel. Combining Cross-site Scripting (XSS) with several pieces of research uncovered in the last year (see research by Billy Rios, Rob Carter, and myself on Protocol/URI Handler Abuse [slides/whitepaper], research on attacks against the same origin policy [see here and here], and the new hotness “Ghost in my Browser” based research kicked of by Manuel Caballero, sirdarckcat, Aviv Raff, etc.), a deployment vector like a persistent XSS on Facebook is extremely attractive to attackers.

Read on…

The following message was posted by Pynnonen to the Full-Disclosure mailing list, describing the vulnerabilities:

Hello,

This is a summary of various Facebook security issues found and reported since June 13, 2008. Two of the vulnerabilities still remain on the site, so no details of them are disclosed here. The rest have been fixed.

Any of these could be exploited to take over the victim’s web browser temporarily to e.g. read inbox messages, forcibly install FB applications, manipulate friend lists, post messages as the victim user, etc. Any of these would also allow creation of a self-propagating JavaScript virus/worm.

Most of the issues require the victim user to click on a profile box or visit a canvas page of an application in order to trigger the injected JavaScript. Issues 2) and 3) don’t require mouse clicks.

The vulnerabilities were tested with two browsers: Firefox 3 (Linux + Windows) and Internet Explorer 7.

1) Escaping JS sandbox with literal Function constructor referenceImpact:execution of unrestricted JS on canvas pages or profiles (mouseclick required on profile pages)Description:The JS sandbox denies references to Function.constructor but using a literal such as “function f() { }” in the code and refering to its constructor with the “bracket syntax” was possible.

The example below uses this method and calls the constructor with astring argument, then calls the resulting Function object.

4) Escaping JS sandbox with literal Number referenceImpact:execution of unrestricted JS on canvas pages or profiles (mouseclick required on profile pages)Description:Using the “bracket syntax” to reference the __parent__ property of a floating point number to get a Window object reference, then calling its eval() to run arbitrary code. IE doesn’t support the property.Browsers: FFReported: June 18, 2008Fixed: yesExample:

5) Injecting JS in video attachmentsImpact:execution of unrestricted JS when a inbox, wall or forum message is viewed (mouseclick required)Description: When sharing video content with the http://www.facebook.com/sharer.phpform, some input fields can be modified e.g. with JavaScript. The example below can be typed in the address bar to inject JS in a message.Browsers: FF, IEReported: June 20, 2008Fixed: yesExample: