Salesforce Developer Security Introduction

salesforce-developer-security

// Salesforce - Developer - Security:

All applications enrolled in the ISVForce or Force.com Embedded Partner Programs 
must go through a mandatory periodic security review. The Security Review has 
been developed to assess the security posture of partner offerings, to ensure 
that applications published on the AppExchange follow industry best practices 
for security, and to promote trust.

Our review is a point-in-time assessment and aims for breadth, meaning we do not 
test for every vulnerability and issue in every partner app. It is up to 
partners to test applications thoroughly through manual testing, code review, 
and automated scanning to ensure vulnerabilities are addressed.

Security Review is a benefit to you. Passing this hurdle is one indication that 
you are ready for taking your application to market and demonstrates to your 
customer that your app is trustworthy in the enterprise space.

Submitting your application for Security Review is achieved through the 
Salesforce Partner Community Publishing Console. The video below walks you 
through accessing and filling out the information required for Security Review.

http://sforce.co/2gceDkU

You may initiate the Security Review wizard from either the Packages tab or a 
Listing. However, if you have an API only app with no managed package, you must 
create a Listing in order to initiate Security Review.

In Step 4 - Components, tell us about all of the components of your application 
architecture. Attach architecture, installation, setup, walk-through, or other 
documentation that will assist the Security Review team in understanding your 
application in Step 6 - Reports.

In Step 5 - Test Environments, provide test environments for all components of 
your application that run in a server environment (e.g. in the cloud). Provide 
installation links and access information for any mobile apps or client apps, 
such as browser plug-ins or desktop apps.

In Step 6 - Reports, your security scan reports should have no issues above 
Informational or Code Quality levels except for false positives. If you have 
false positives, provide a false positives explanation document.

Tip: If you use external solutions not owned by you, you still have to provide 
scan reports for those components. In some cases this will also mean that you 
will need to obtain permission from the third party to allow the Security Review 
team to test their solution.

1. Do not stop at 10.
2. Subscribe to various security news service to stay up-to-date to latest security 
    attacks.
3. Use tools such as Nexus, Snort
4. Use code scanner

[[code]]
// Salesforce - Developer - Security:

For applications developed on the Salesforce platform, there are two basic ways 
a user will use to authenticate themselves:

1. UI login
2. API login

The platform login page URL has several formats:

1. https://login.salesforce.com - Login to an org on any instance.

2. https://[customDomain].my.salesforce.com - Login to a specific org with 
   custom domain enabled.

3. https://[instance].salesforce.com - Login to an org that is in a specific 
   instance.

Regardless of the entry login page used, the login flow is the same:

1. User enters username and password into the login page, and click the "Login .."
   button.  The username and password are submitted as part of the body of the 
   post message.

2. The server responds to the successful login POST with an HTTP 302 GET 
   redirect message. The target of this redirect is the login servlet on the 
   instance where the username resides. Included in the target url is the url 
   parameter sid, which contains a temporary one time use sessionid.

3. The login servlet (frontdoor.jsp) responds to the GET request by exchanging 
   the one time sid with a permanent sid, stored as a secure cookie scoped to 
   instance.salesforce.com. The response is also an HTTP 302 GET redirect, this 
   time targeted to the content domain. Once again, the parameter sid is 
   included, this time with a one time sessionid for the content domain.

4. The content domain servlet (/secur/contentDoor) responds to the second HTTP 
   302 GET with an HTTP 200. As part of the response, the one time sid url 
   parameter is exchanged for a long lived second sid cookie scoped to the 
   content domain. A client side redirect then sends the user to the 
   authenticated home page, /home/home.jsp.

At this point, login is complete and two long lived sid cookies have been stored 
by your browser for the main domain and the content domain. 

In the above flow, we use many redirects and temporary session IDs to establish 
valid session ids for each sub domain accessible by the user.  Part of 
Salesforce's security model is to divide orgs into seperate subdomains with 
dedicated functions. Below is an example breakdown for an org residing on a na1 
instance:

1. na1.salesforce.com: Most functionality will reside on this subdomain.  

2. c.na1.content.force.com - This domain typically serves files and attachments 
   for the org.

3. c.na1.visual.force.com - This domain serves visualforce pages in the org.

4. [ManagedPackagePrefix].na1.visual.force.com - This domain serves visualforce 
   pages that are part of a managed package installed on the org.

As a result of this architecture, users must establish sessions across each of 
these domains, which is accomplished via the redirections during the login 
process. One could argue that this process could be simplified by creating a 
single session id at login whose domain was set to *.salesforce.com or 
*.force.com. However that method does not help enforce subdomain restrictions. 
If you remember during the login flow each session id that was created was 
scoped to a specific subdomain. By doing this salesforce ensures that a session 
compromised in one domain will not lead to a compromise in another, esstentially 
limiting the impact of what an attacker can do with the compromised session.

During login a session id is sent as a URL parameter during the redirect to 
each target domain. In general this is not considered a security best practice, 
because even though HTTPS is used meaning the HTTP requsts are encrypted in 
transit, URL parameters can still be exposed in many other locations including 
browser history and web server logs. To mitigate this risk, salesforce sends a 
single use session id that is only used for the redirection. The sub-domain / 
instance which receives the single use session id validates the session, and 
then generates a new long lived session id for that specificly for that 
sub-domain, which is stored in a cookie.

Salesforce maintains all sessions server side, and uses the sid cookie on the 
client as the exchange mechanism of session id information between server and 
client. There are two important security features that developers should be 
aware of concerning cookies: 

1. Secure Flag: The "secure" attribute instructs browsers to only send the 
   cookie for HTTPS requests. This prevents the accidental exposure of senstive 
   data when transmitting data over an unsecured channel. This is enabled for 
   all salesforce session cookies.

2. HTTPOnly attribute: A cookie with the "HttpOnly" attribute prevents access to 
   the cookie via non-HTTP methods, such as calls from JavaScript.   The primary 
   security benefit for enabling this is to mitigate to a certain extent the 
   impact of Cross Site Scripting (XSS) vulnerabilities (covered later in the 
   class), which are often used by attackers to access a user's cookies using 
   javascript. However the benefit is minimal as this vulnerabilities can also 
   be used to perofrm HTTP requests as the user to perform operations and access 
   data. As a result, by default, this setting is disabled for the session 
   cookie.

[[/code]]
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License