Facebook - Revision history

Jeff Williams: Update HTML tags so they aren't interpreted when editing the page in some browsers

2010-03-23T23:51:25Z

Update HTML tags so they aren't interpreted when editing the page in some browsers

Jmanico: /* Signature Verification */

2010-03-19T06:37:54Z

‎Signature Verification

Jmanico: /* Signature Generation */

2010-03-19T06:36:54Z

‎Signature Generation

Jmanico: /* Cross Site Scripting (XSS) */

2010-03-19T06:35:33Z

‎Cross Site Scripting (XSS)

Jmanico: /* Considerations for Flash Applications */

2010-03-19T06:31:15Z

‎Considerations for Flash Applications

Jmanico: /* Considerations for Flash Applications */

2010-03-19T06:29:45Z

‎Considerations for Flash Applications

Jmanico: /* Secure transport using SSL */

2010-03-19T06:27:25Z

‎Secure transport using SSL

Jmanico: /* Secure transport using SSL */

2010-03-19T06:27:04Z

‎Secure transport using SSL

Jmanico: /* Secure transport using SSL */

2010-03-19T06:26:46Z

‎Secure transport using SSL

Jmanico: /* Administrative Functionality */

2010-03-19T06:25:43Z

‎Administrative Functionality

@@ Line 156: / Line 156: @@
 Protecting against CSRF attacks using the Facebook Signatures
 The Facebook signatures can provide protection from CSRF attacks, but they cannot be relied upon in all circumstances. The Facebook signatures are computed in a similar way to the recommended CSRF protection token algorithm; the signature is a cryptographic hash of the request parameters and a server side secret. Note that the use of the HMAC_sha1 hashing algorithm is significantly stronger than the MD5 hashing algorithm used by Facebook, which has been proven to be vulnerable to some attacks1. While the signature is an adequate CSRF protection token, there are a couple very important caveats to keep in mind if the Facebook signature is used as a CSRF protection mechanism:
- Facebook signatures cannot protect against CSRF attacks when sent as cookie values. CSRF protection tokens provide no protection when sent as cookie values.
+* Facebook signatures cannot protect against CSRF attacks when sent as cookie values. CSRF protection tokens provide no protection when sent as cookie values. (See http://www.win.tue.nl/hashclash/rogue-ca/) because the browser will automatically send cookie values with the request, thus the attacker does not need to guess the value, and the structure of the request remains predictable. Facebook Connect applications send the signatures as cookie values, rather than request parameters. Therefore, it is important to remember that these applications will have to provide a separate CSRF protection mechanism. This caveat highlights one of the reasons to implement a separate CSRF protection system that is designed specifically for this class of vulnerabilities. This way, code can be ported to different types of Facebook (and non-Facebook) applications and will still be protected from this class of attack.
-http://www.win.tue.nl/hashclash/rogue-ca/
+* The Facebook signature is not sent with all requests. The Facebook signature is not always available for use as a CSRF protection token. If this is your chosen method to provide CSRF protection, you must analyze your application you must analyze your application for areas where the server side state is being updated, but the Facebook signature is not sent with the request parameters. These requests will have to be protected through a separate CSRF protection mechanism.
 === Cross Site Scripting (XSS) ===
@@ Line 166: / Line 164: @@
 <pre>
-<?php
+< ?php
 echo(“Your username is:”.$_GET[“username”]);
 ?>
@@ Line 174: / Line 172: @@
 <pre>
-<script>alert(document.cookie);</script>
+< script>alert(document.cookie);< /script>
 </pre>
@@ Line 181: / Line 179: @@
 <pre>
 Your username is:
-<script>alert(document.cookie);</script>
+< script>alert(document.cookie);< /script>
 </pre>
 When the browser renders this page, the script tag that was entered as the username will be written to the source of the page. The browser will parse it as HTML and the script will be executed. The malicious user can then exploit this vulnerability against other users by creating a request such as the following:
-http://example.com/displayUserName.php?username=<script>alert(document.cookie);</script>
+http://example.com/displayUserName.php?username=< script>alert(document.cookie);< /script>
 The attacker must then convince their victims to load the malicious request in a browser with an active session on the vulnerable site. The attacker may do this by disguising the link with a tinyURL service and putting it in a place logged in users are likely to visit, such as a forum, or by posting it on a Facebook page. When victims load the malicious request in their browser, the attacker injected script will execute and the user’s session cookie will be revealed to the attacker (in a real world scenario the script would contain something much more malicious than an alert box). For example, the SAMY MySpace worm was propagated by exploiting an XSS vulnerability2. The attacker could also use an XSS vulnerability to rewrite the source of the page so that it becomes a convincing phishing page, or a page which prompts users to install malware. Even cautious users may be tricked, as the page originates from a domain which they trust. This attack can be used in many different ways to compromise the user’s browser and session, and is also usually very easy to exploit.
@@ Line 193: / Line 191: @@
 <pre>
-<?php
+< ?php
 if(ctype_alnum($username)) ($_GET[“username”])){
 $username = htmlentities($username);
@@ Line 220: / Line 218: @@
 ===== FBML/FBJS applications =====
-In an XSS attack on FBML applications, the injected data will be written directly to the source of the page in the apps.facebook.com domain. However, as part of the Facebook sandboxing method for FBML applications, any injected script will be translated to FBJS. This means that an attacker cannot send the traditional XSS payload which, for example, uses JavaScript to access the user session. However, the attacker can still easily inject arbitrary FBML tags. When an attacker can inject FBML, they can do things like inject an FB:SWF tag (<fb:swf /> ), which embeds a SWF in the application canvas page. Whenever a SWF is loaded in the application canvas, Facebook will automatically pass it all of the Facebook parameters, including the session secret, as flashvars. The attacker can then send the flashvars back to their server and then use this information to access the application and perform actions on behalf of the user.
+In an XSS attack on FBML applications, the injected data will be written directly to the source of the page in the apps.facebook.com domain. However, as part of the Facebook sandboxing method for FBML applications, any injected script will be translated to FBJS. This means that an attacker cannot send the traditional XSS payload which, for example, uses JavaScript to access the user session. However, the attacker can still easily inject arbitrary FBML tags. When an attacker can inject FBML, they can do things like inject an FB:SWF tag (< fb:swf /> ), which embeds a SWF in the application canvas page. Whenever a SWF is loaded in the application canvas, Facebook will automatically pass it all of the Facebook parameters, including the session secret, as flashvars. The attacker can then send the flashvars back to their server and then use this information to access the application and perform actions on behalf of the user.
 === Considerations for Flash Applications ===
@@ Line 236: / Line 234: @@
 <pre>
-<cross-domain-policy>
+< cross-domain-policy>
-<allow-access-from domain="*"/>
+< allow-access-from domain="*"/>
-</cross-domain-policy>
+< /cross-domain-policy>
 </pre>
@@ Line 249: / Line 247: @@
 <pre>
-<cross-domain-policy>
+< cross-domain-policy>
-<allow-access-from domain="foo.example.com"/>
+< allow-access-from domain="foo.example.com"/>
-<allow-access-from domain="bar.example.com"/>
+< allow-access-from domain="bar.example.com"/>
-</cross-domain-policy>
+< /cross-domain-policy>
 </pre>

@@ Line 122: / Line 122: @@
 Signature verification using the application secret must never be done on the client side, as this would expose the secret. Always perform signature verification using server code.
 The signature verification process is different depending on the type of Facebook application:
- Platform applications – In platform applications, Facebook will send the signature and other parameters as part of the GET or POST request. The application should grab the Facebook parameters from the request parameters, and recalculate the expected signature value using the signature generation algorithm, or the built in function from the Facebook client in use.
- Facebook Connect Applications – For Facebook Connect applications the Facebook parameters are sent as cookies. To verify these parameters, the application must extract the values from the cookies and perform the verification using the signature algorithm. The Facebook PHP client supports cookie based signature verification and is well-tested. The verification method must be checked in any unofficial libraries you may decide to use. Facebook Connect applications do not need to verify the signature very often. The most common scenario which requires verification of the Facebook cookies is when the session is being transferred from the client side to use server side libraries. When this occurs, the application must verify the cookies sent with the session transfer request. Otherwise, a malicious user could tamper with their cookies in order to trick the server into believing they were another user. More information on server side integration with Facebook Connect applications can be found here: http://wiki.developers.facebook.com/index.php/Using_Facebook_Connect_with_Server-Side_Libraries .
+==== Platform applications ====
 === Signature Generation ===

@@ Line 129: / Line 129: @@
 Signatures must be generated in order to call sensitive APIs and in order to re-calculate the signature as part of the verification process. The Facebook PHP library includes functions for performing signature generation. For server side code, the application should generate the signature using these API functions or by re-implementing the signature generation algorithm.
 For client side code such as Flash, JavaScript, mobile and desktop applications, which cannot use the application secret directly, there is an alternate secret used to generate the signature: the session secret. The session secret can be used to call many APIs, but there are some API functions that can only be called with the application secret. In this case, the client side application should create a simple, server-hosted proxy which makes the necessary API calls and relays the result back to the client side application. Depending on the type of application, there are several different options for retrieving the session secret.
- Desktop and iPhone Applications – Desktop and iPhone applications should either use a Session proxy (http://wiki.developers.facebook.com/index.php/Session_Proxy) to create a session and retrieve the session secret, or embed a Web browser in the application in order to use Facebook Connect to start the session. In order to obtain the
-user session in the traditional manner, an iPhone or Desktop application would have to call auth.getSession. However, calls to auth.getSession must be signed with the application secret. The application secret must never be hardcoded in the source of an iPhone application. Attackers can easily decompile Objective C and thus the secret can be discovered by anyone who downloads the application. Therefore, this API method is not safe for direct use in iPhone applications. The same is true for Desktop applications using Adobe Air or .NET.
+==== Desktop and iPhone Applications ====
 The session proxy is simply a callback to an application server which then makes the auth.getSession call on the server and returns the resulting session variables back to the iPhone application. Ensure that the call to auth.getSession is made at an HTTPS endpoint, as this is required to protect the session secret from being revealed to network attackers when it is sent back to the application.
 The other option is use the Facebook Connect API via a Web browser embedded in the application. In this case, the application developer must direct the embedded browser to Facebook login pages with specific URL parameters which direct Facebook to return the session information. One of these parameters contains the URL to which the user will be redirected after they successfully login. The session secret can then be retrieved from this URL and passed back to the application. The session secret can then be safely stored on the user’s system until they close the application. More detailed information can be found at http://wiki.developers.facebook.com/index.php/Authorization_and_Authentication_for_Desktop_Applications
- Facebook Connect Websites – When making API calls using the JavaScript client library, Facebook Connect web applications should generate the signature for API calls using the session secret, in much the same way that desktop applications do. The session secret will be passed to the application callback URL after the user has authorized the application. More detailed information on this process can be found here: http://wiki.developers.facebook.com/index.php/Authorization_and_Authentication_for_Desktop_Applications
+The other option is use the Facebook Connect API via a Web browser embedded in the application. In this case, the application developer must direct the embedded browser to Facebook login pages with specific URL parameters which direct Facebook to return the session information. One of these parameters contains the URL to which the user will be redirected after they successfully login. The session secret can then be retrieved from this URL and passed back to the application. The session secret can then be safely stored on the user’s system until they close the application. More detailed information can be found at [http://wiki.developers.facebook.com/index.php/Authorization_and_Authentication_for_Desktop_Applications http://wiki.developers.facebook.com/index.php/Authorization_and_Authentication_for_Desktop_Applications]
- Flash – Flash applications will be passed the Facebook parameters as flashvars from their hosting page. The hosting page must validate the signature on the server side before passing it to the SWF object, as the application secret cannot be safely stored in the SWF. This is due to the fact that SWFs can be downloaded by an attacker and easily decompiled in order to retrieve any secrets used in the ActionScript. The ActionScript API can then use the session secret passed in these variables to generate signatures for further API calls.
 === Cross Site Request Forgery (CSRF) ===

@@ Line 153: / Line 153: @@
 XSS attacks are one of the most common and dangerous web application vulnerabilities. An XSS vulnerability exists when user controlled data is written directly to the page source without sufficient input validation or output encoding applied. A common example of this vulnerability is a web page which takes values from request parameters and includes them directly in HTML or JavaScript without validation or sanitization. Consider an example PHP page from an application which displays a username passed in via GET request parameters. The source of this page contains the following code:
 <?php
 echo(“Your username is:”.$_GET[“username”]);
 ?>
 Now imagine that a malicious user tampers with the request parameters and enters the following string in the username field:
 <script>alert(document.cookie);</script>
 The source of the resulting page will then contain:
 Your username is: <script>alert(document.cookie);</script>
 When the browser renders this page, the script tag that was entered as the username will be written to the source of the page. The browser will parse it as HTML and the script will be executed. The malicious user can then exploit this vulnerability against other users by creating a request such as the following:
 http://example.com/displayUserName.php?username=<script>alert(document.cookie);</script>
 The attacker must then convince their victims to load the malicious request in a browser with an active session on the vulnerable site. The attacker may do this by disguising the link with a tinyURL service and putting it in a place logged in users are likely to visit, such as a forum, or by posting it on a Facebook page. When victims load the malicious request in their browser, the attacker injected script will execute and the user’s session cookie will be revealed to the attacker (in a real world scenario the script would contain something much more malicious than an alert box). For example, the SAMY MySpace worm was propagated by exploiting an XSS vulnerability2. The attacker could also use an XSS vulnerability to rewrite the source of the page so that it becomes a convincing phishing page, or a page which prompts users to install malware. Even cautious users may be tricked, as the page originates from a domain which they trust. This attack can be used in many different ways to compromise the user’s browser and session, and is also usually very easy to exploit.
 So how should the developer have prevented this vulnerability? The developer should have validated and sanitized the value before writing it to the source of the page. The corrected code would look as follows:
 <?php
 if(ctype_alnum($username)) ($_GET[“username”])){
@@ Line 172: / Line 190: @@
+}
 ?>
-http://en.wikipedia.org/wiki/Samy_%28XSS%29
+</pre>
 The conditional statement use the built in PHP function ctype_alnum to verify that the string entered contains only alphanumeric characters. The htmlentities function is a built in PHP function which output encodes un-trusted data so that it is safe to use in the HTML context, so “<” becomes “&lt;” and “>” becomes “&gt;”. The user controlled data from the GET request is now safe to write to the source of the page.
 Prevent XSS attacks by using a combination of input validation and output encoding. Most class libraries include functions for performing output encoding. While output encoding provides strong protection against XSS, it is best to perform data validation before encoding. The validation and encoding should always be performed on the server side, and should be done using a whitelist of known good data. Instead of searching the data for bad characters, check that the string matches the expected format based on the type of input. For example, if the user controlled data is a postal zip code, validate that the data is numeric, rather than searching the data for “<” characters. It is always harder to enumerate the possible bad data, than to enumerate the possible good data. Validating user controlled data before use is simply the correct way to write code, and along with helping to prevent XSS vulnerabilities, will make the application run more smoothly as a whole. Output encoding can then be used for further protection, catching any data that could not be cleaned during input validation.
 Cross Site Flashing (XSF)
 Flash applications can also be vulnerable to a similar issue to XSS.
-When your Flash application uses functions which invoke JavaScript or retrieve URLs, you must check the data you pass to these functions. If the data is user controlled, than an attacker can enter malicious JavaScript or pass a malicious URL. Sometimes, the attacker may be able to load their own malicious SWF inside of the application due to such dangerous use of the loadMovie function. A common mistake is to pass data from flashvars to these dangerous functions. For more information see the following resource: http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html
+When your Flash application uses functions which invoke JavaScript or retrieve URLs, you must check the data you pass to these functions. If the data is user controlled, than an attacker can enter malicious JavaScript or pass a malicious URL. Sometimes, the attacker may be able to load their own malicious SWF inside of the application due to such dangerous use of the loadMovie function. A common mistake is to pass data from flashvars to these dangerous functions. For more information see the following resource: [http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html]
 XSS in Facebook Applications
 XSS attacks in Facebook applications are unusual due to the use of FBML, FBJS, XFBML, and the Facebook proxy.
- XSS in Facebook iFrame applications. In an XSS attack, the injection occurs in the domain of your application. If the injection is possible due to a lack of input validation and output encoding in the application code, then the attacker can execute arbitrary HTML and JavaScript; and in some cases XFBML. The injected code can be used to steal any Facebook cookies which are set when using Facebook Connect code. These cookies reveal the user session key.
- FBML/FBJS applications. In an XSS attack on FBML applications, the injected data will be written directly to the source of the page in the apps.facebook.com domain. However, as part of the Facebook sandboxing method for FBML applications, any injected script will be translated to FBJS. This means that an attacker cannot send the traditional XSS payload which, for example, uses JavaScript to access the user session. However, the attacker can still easily inject arbitrary FBML tags. When an attacker can inject FBML, they can do things like inject an FB:SWF tag (<fb:swf /> ), which embeds a SWF in the application canvas page. Whenever a SWF is loaded in the application canvas, Facebook will automatically pass it all of the Facebook parameters, including the session secret, as flashvars. The attacker can then send the flashvars back to their server and then use this information to access the application and perform actions on behalf of the user.
+===== XSS in Facebook iFrame applications =====
 === Considerations for Flash Applications ===

@@ Line 196: / Line 196: @@
 A dangerously configured crossdomain.xml is as follows:
 <cross-domain-policy>
 <allow-access-from domain="*"/>
 </cross-domain-policy>
 This dangerous configuration allows access from any domain, effectively enabling Flash content on any site to attack your application. This would allow an attacker to host your SWF on their site, and although the SWF’s domain of origin is now the attacker’s, the SWF can still make calls back to its original domain because of the badly configured crossdomain.xml file in place. This gives the attacker control of the flashvars the SWF uses, and would allow the attacker to, for example, provide a different value for the fb_sig_user parameter and other Facebook
@@ Line 207: / Line 209: @@
 For example, consider a SWF whose domain of origin is sometimes foo.example.com, and sometimes bar.example.com, but it always needs to call back to code on example.com. The policy file hosted at example.com should then look like this:
 <cross-domain-policy>
 <allow-access-from domain="foo.example.com"/>
 <allow-access-from domain="bar.example.com"/>
 </cross-domain-policy>
 This will allow the SWF to be hosted at either the foo or bar sub domains, but will not allow it to be hosted at the attacker’s site. Furthermore, it will not allow arbitrary domains access to the server through crossdomain requests.

@@ Line 208: / Line 208: @@
 === Secure transport using SSL ===
-The HTTPS protocol provides the ability to transport information securely over the network using public key cryptography. The protocol provides confidentiality and integrity guarantees. When communicating over HTTPS, one can have some confidence on who they are talking to and that the data sent cannot be successfully tampered with. Without using HTTPS there can be no such guarantee. Facebook does not serve its own content over HTTPS. However, it is still possible to leverage the security benefits of an HTTPS site using Facebook Connect. The following guide discusses how to use Facebook Connect with an SSL site: [http://wiki.developers.facebook.com/index.php/Facebook_Connect_Via_SSL].
+The HTTPS protocol provides the ability to transport information securely over the network using public key cryptography. The protocol provides confidentiality and integrity guarantees. When communicating over HTTPS, one can have some confidence on who they are talking to and that the data sent cannot be successfully tampered with. Without using HTTPS there can be no such guarantee. Facebook does not serve its own content over HTTPS. However, it is still possible to leverage the security benefits of an HTTPS site using Facebook Connect. The following guide discusses how to use Facebook Connect with an SSL site: [http://wiki.developers.facebook.com/index.php/Facebook_Connect_Via_SSL http://wiki.developers.facebook.com/index.php/Facebook_Connect_Via_SSL].
 Areas of an application which deal with financial transactions, such as online payments, must use HTTPS to protect their communications. If you are writing a Facebook application that has a payments component, consider the following recommendations for integrating securely with Facebook.

@@ Line 208: / Line 208: @@
 === Secure transport using SSL ===
-The HTTPS protocol provides the ability to transport information securely over the network using public key cryptography. The protocol provides confidentiality and integrity guarantees. When communicating over HTTPS, one can have some confidence on who they are talking to and that the data sent cannot be successfully tampered with. Without using HTTPS there can be no such guarantee. Facebook does not serve its own content over HTTPS. However, it is still possible to leverage the security benefits of an HTTPS site using Facebook Connect. The following guide discusses how to use Facebook Connect with an SSL site: http://wiki.developers.facebook.com/index.php/Facebook_Connect_Via_SSL .
+The HTTPS protocol provides the ability to transport information securely over the network using public key cryptography. The protocol provides confidentiality and integrity guarantees. When communicating over HTTPS, one can have some confidence on who they are talking to and that the data sent cannot be successfully tampered with. Without using HTTPS there can be no such guarantee. Facebook does not serve its own content over HTTPS. However, it is still possible to leverage the security benefits of an HTTPS site using Facebook Connect. The following guide discusses how to use Facebook Connect with an SSL site: [[http://wiki.developers.facebook.com/index.php/Facebook_Connect_Via_SSL]].
 Areas of an application which deal with financial transactions, such as online payments, must use HTTPS to protect their communications. If you are writing a Facebook application that has a payments component, consider the following recommendations for integrating securely with Facebook.
- Ensure that all sensitive API calls use HTTPS endpoints for client side applications. When making sensitive API calls, ensure that they are sent over HTTPS by calling them from an HTTPS endpoint. For example, the function auth.getSession returns the user’s session secret, which can be used to make sensitive API calls on behalf of the user. For client side applications, the session secret is used in place of the application secret, and therefore must be guarded carefully. Calls to auth.getSession should be made to an HTTPS endpoint, so that it will be returned to the client application over a secure connection. The same applies for other sensitive server side APIs.
- Ensure that sessions with the secure site are initiated over HTTPS. When a Facebook platform application which is served over HTTP needs to direct the user to a secure site (for example to start a financial transaction), it is crucial that the session be initiated over HTTPS. A common mistake is to direct the user to the secure site using HTTP, and then internally redirect to the HTTPS connection after, without changing the session identifier. This is dangerous as it reveals the session identifier in the clear, before redirecting to the HTTPS site. In the best case, the secure site should not be accessible over HTTP at all.
+==== Ensure that all sensitive API calls use HTTPS endpoints for client side applications ====
- Set the Secure flag on all sensitive cookies. Setting the Secure flag on cookies tells the browser to only send the cookie over an HTTPS connection. This will keep sensitive cookies from being revealed to network attackers. Not setting the Secure flag severely undermines the protections provided by HTTPS, as the secure session can still be compromised.
+When making sensitive API calls, ensure that they are sent over HTTPS by calling them from an HTTPS endpoint. For example, the function auth.getSession returns the user’s session secret, which can be used to make sensitive API calls on behalf of the user. For client side applications, the session secret is used in place of the application secret, and therefore must be guarded carefully. Calls to auth.getSession should be made to an HTTPS endpoint, so that it will be returned to the client application over a secure connection. The same applies for other sensitive server side APIs.
 === Administrative Functionality ===

@@ Line 218: / Line 218: @@
 Because the Facebook platform is different than traditional application platform, securing administrative functionality can be confusing, and some compromises have to be made. Developers of a Facebook application can set certain users to be administrators and
 moderators of the application. There are certain API functions that can only be called by administrators. These functions provide the ability to perform administrative actions for the Facebook application, such as banning and unbanning users, setting application properties, and retrieving information about the applications usage statistics. It is tempting to include these functions in the same application canvas as the normal user functionality. Unfortunately, this design goes against the principle of least privilege. It is a best practice to keep the administrative functionality as separate as possible from the normal user application. For Facebook applications, the following recommendations should be considered in order to secure administrative functionality.
- Require HTTPS. Any administrative pages must be served only over HTTPS in order to protect from local network attackers. This should be followed even if the administrative portion of the application is served only internally, to protect from rogue insider attacks. The application can still use the Facebook API by using Facebook Connect with SSL to authenticate and then transferring the session to the server side in order to make admin API calls which require the application secret. The session transfer process is described in detail here: http://wiki.developers.facebook.com/index.php/Using_Facebook_Connect_with_Server-Side_Libraries.
- Host administrative functionality on a different domain than the normal application. It can be tempting to host the administrative portion of the application on the same domain as the rest of the application. One common scenario is to check if the Facebook ID sent with the request is an administrator’s ID and then to display the corresponding administrative functionality in the same Facebook canvas page as the rest of the application. This is not recommended as it can allow for XSS attacks to have a more devastating effect, and can make it easier for an attacker to discover the administrative pages in order to perform CSRF attacks. Instead, the administrative functionality should be hosted on an entirely separate domain. The application can still use the Facebook API by using Facebook Connect and transferring the session to the server side API for calls which require the application secret.
+==== Require HTTPS ====
- Make endpoints available internally only. The application should only be available on the internal network. As a rule, administrative interfaces should never be available from the internet. Internal only hosting will greatly increase the difficulty of attacking the application, as the attacker will first have to gain access to the internal network.
+Any administrative pages must be served only over HTTPS in order to protect from local network attackers. This should be followed even if the administrative portion of the application is served only internally, to protect from rogue insider attacks. The application can still use the Facebook API by using Facebook Connect with SSL to authenticate and then transferring the session to the server side in order to make admin API calls which require the application secret. The session transfer process is described in detail here: http://wiki.developers.facebook.com/index.php/Using_Facebook_Connect_with_Server-Side_Libraries.
- Require additional authentication – The administrative portion of the application can use Facebook Connect to log into the application via Facebook credentials. However, Facebook sessions are not secured over HTTP, so there is a potential for hijacking an administrators session. If an administrator’s session is hijacked by an attacker, they may be able to use that session to access the administrative functionality. In order to provide further protection, require administrators to log into the application using separate credentials.