The developers of the two applications referred to by Goldshlager and Ivgi have both been contacted by Facebook, and remediation began immediately, McGeehan said. Neither application should be accessible, and the applications will be reviewed before they are enabled, he added.
Still, the issue of third-party applications is a sticky one for social networking sites, which by their very nature encourage people to share. If developers aren't creating secure code, or, worse yet, are intentionally building malicious applications, users could be at risk. To help address this, Facebook requires that developers agree to comply with policy guidelines prohibiting malicious activity before they can build on the site's platforms.
"We recommend that users add applications from companies or developers that they trust," McGeehan said. "This is similar to how we recommend that users only add people they trust in real life. We also recommend that developers follow development standards for Web applications, such as the standards set by the Open Web Application Security Project ... to avoid vulnerability. Users can also check out our help page for more information on applications."
In addition to the SQL injection bugs, Goldshlager and Ivgi also found a cross-site scripting vulnerability that has since been fixed. That vulnerability was in the Facebook pages mechanism. The duo found that a user can create a new page with arbitrary HTML code in the page's name.
The code will only be displayed as text, and will not be exploitable until a new message is created in the discussion section of the page and a reply is made to that message. The first reply to the topic will execute the arbitrary code-which is the page's name itself-because it does not filter the HTML code, Goldshlager explained. The situation allows hackers to create a permanent XSS situation inside Facebook that can take over the session of any user browsing that page.
"This is a complex case of input validation in a Web application, since the user's input is always filtered to avoid executing free HTML code except from the one case of a reply to a topic in that Facebook page with the [malicious] page name," Goldshlager said. "Facebook fixed the vulnerability by filtering the user input [the page's name] also in the page where the first topic reply is displayed."