Contents 1 Single Sign On Security 2 What is it? 3 Vulnerability Description 4 Is my application vulnerable? 5 How can I test my application? 6 How do I protect my application?

Single Sign On Security

 

What is it?

Single sign on issues arise for developers integrating with Force.com when either the API Partner Server URL is not validated or SSL is not used when a non-native application calls back to an external server with a user’s session id. This may result in exposure of the API Session ID or Salesforce data to an attacker.

Vulnerability Description

Many composite Force.com applications implement a form of Single-Sign-On (SSO) between Force.com and the external application. This transaction requires a minimum of two parameters in order to authenticate the external application. The first parameter is the API Session ID (SID), which is considered sensitive and is equivalent to a login and password. The SID is generated on a per session basis when a user logs in. The second is the API Partner Server URL (SOAP Endpoint). The API Partner Server URL is the URL of the SOAP endpoint that is associated with the user’s instance of Salesforce. Applications will then utilize the SID to represent that user in future API requests and the SOAP Endpoint to communicate with the appropriate API server.

There are two main security concerns that should be taken into consideration for single sign on transactions in this situation.

1. Because the SID is equivalent to a password steps should be taken to protect it from interception in transit. SSL (HTTPS) should be enforced for any transactions that transmit the SID, and the certificate should be evaluated to ensure that it is a valid salesforce.com certificate. This includes pages that could transmit the SID through the Referrer header. The API Session ID should never be transmitted to 3rd party sites such as Google Analytics.

2. The API Partner Server URL (SOAP Endpoint) is used to authenticate the application using the SID. An attacker can spoof the URL that includes the API Partner Server URL and SID and simply change the API Partner Server URL to a non-Salesforce server. The attacker, thus imitating a Salesforce endpoint can use this to steal any data that is sent to the malicious server. In order to prevent authentication and data transmission through a rogue endpoint, the API Partner Server URL should be validated to be a legitimate Salesforce.com SOAP Server.

Below is the regular expression to validate legitimate API Partner Server URL servers:

• https://[^/?]+\\.(sales|visual\\.)force\\.com/services/(S|s)(O|o)(A|a)(P|p)/(u|c|m)/.*

To summarize the above regular expression, it ensures that the URL starts with ‘https://’, followed by a character other than ‘/ ‘ or '?' for 1 or more times, followed by a ‘.’, followed by ‘sales’ or ‘visual.’ followed by ‘force.com/services/SOAP/’, followed by ‘u’ or ‘c’ or 'm', followed by ‘/’. This will allow:

• https://*.salesforce.com/services/SOAP/u/
• https://*.salesforce.com/services/SOAP/c/
• https://*.visual.force.com/services/SOAP/u/
• https://*.visual.force.com/services/SOAP/c/

 

Is my application vulnerable?

If your application does not enforce SSL or does not validate the API Partner Server URL you application is vulnerable.

How can I test my application?

Some testing for single sign on vulnerabilities can be performed in a black-box manner, however, in depth code review should be performed on any functionality that relates to single sign on, or handles API Session IDs. For black box testing the use of an intercepting proxy or similar solution is recommended. The Salesforce product security team provides a web application to test for soap endpoint validation issues. The following steps can be used to test Salesforce single sign:

1. Capture the single sign on request using a proxy tool such a Burp. The URL should use a format similar to the following: https://AppExchange_Offering.example.com/default.aspx?SfdcUrl=[API Partner Server URL]&SfdcSessionId=[API Session ID]

There may be other parameters that are required for the application, or the format or method may vary slightly, but this is a basic example.

The first item to check should be the use of SSL. This URL is using SSL.

2. Next replace the API Partner Server URL with the address of the testing endpoint. We will use the fake test endpoint below:

http://security.force.com/ssocheck?action=send&token=[unique token]

It should be noted that the token parameter that is highlighted in bold is selected by the tester and should be unique for each test performed. The use of obvious tokens such as “ssotest”, “testing123”, etc may result in inaccurate results. Once the URL is accessed the token is locked.

The URL should look like the following:
https://AppExchange_Offering.example.com/default.aspx?SfdcUrl=http://security.force.com/ssocheck?action=send&token=[unique token]&SfdcSessionId=[API Session ID]

3. Finally check the site to see if the application has attempted single sign on with the fake endpoint.

You may check if the application has accessed the fake endpoint that we modified by checking the following URL:

http://security.force.com/ssocheck?action=validate&token=[unique token]

Again please note that this URL is contains the unique token that we chose in step 2.

If you are presented with a green checkmark as shown above the application did not access the endpoint and is properly validating the API Partner Server URL.

If you are presented with a red X as shown above the endpoint was accessed and the application is not properly validating the API Partner Server URL before attempting single sign on.

It is important to note that some applications do not access the API Partner Server URL immediately upon receipt of the single sign on request. Some applications require a specific action to be performed such as initiating a synchronization before communication is attempted.

How do I protect my application?

Steps should be taken as described in the text above to protect your application.