While changes to Facebook’s user license agreement have been in the news of late, another issue continues to nag Facebook and other social networks-the security of applications developed by third parties.
The question of what to do with potentially malicious applications created by third parties for use on social networking sites is underscored by the recent findings of security researchers Nir Goldshlager and Rafel Ivgi.
“The SQL injection we discovered is in two different applications in apps.facebook.com,” explained Goldshlager, who works for Citadel Technologies in Israel. “One of the servers is running as root. This means we can write files into the machine and with a high chance of executing code on it as root. In any case it is possible to obtain the same information about the users, as the application is able to get and insert new and even malicious information into the database.”
On the subject of Facebook security, officials said fixing third-party applications is up to the developer.
“Developer applications are hosted on third-party servers,” Ryan McGeehan, of Facebook’s security team, told eWEEK. “When security-related bugs arise in third-party applications-it’s the developer’s responsibility to get them fixed, as their code does not live on Facebook systems.”
When Facebook receives reports about vulnerabilities in third-party applications, officials notify the developers immediately. In some cases, Facebook also disables or sandboxes applications until the developer has corrected the issue.
Facebook Users Should Be Wary
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.”