Secure Coding Secure Communications | Secure Coding Guide

Secure Communications and Cookies - What is required?

Applications hosted outside Salesforce or which send or receive important information from other sites must use HTTPS. Any cookies set by your application for authentication, authorization, or which contain private or personally identifiable information must set the Secure flag to ensure they are only sent over HTTPS.

When the server sets cookies without the Secure attribute, the browser will send the cookie back to the server over either HTTP or HTTPS connections.

For applications that are available over both HTTP and HTTPS, users that enroll or sign-in through Salesforce.com must be directed and restricted to use of the secure site only.

On your web server, disable weak cipher suites and vulnerable versions of SSL/TLS. Salesforce.com requires exclusive use TLS 1.0 or greater. TLS 1.0 will not be acceptable beyond March 1, 2017. Disable all null, export, 40-bit or DES cipher suites.

Sample Vulnerability

Failure to set the Secure flag for security-critical cookies is the most common vulnerability in this category. Simply setting a cookie over an HTTPS connection does not prevent it from being returned over HTTP unless the Secure flag is set. Even if your site does not have an HTTP version, malicious parties on the network may be able to steal session cookies.

(There are several ways to achieve this. For example, the attacker may insert references to HTTP URLs to your application into sites that your users are likely to visit. Assume your application is https://app.example.com, and your users frequent a discussion forum/blog at http://exampleappblog.com. ExampleAppBlog allows commenters to include limited HTML in their posts, including img tags. A commenter inserts HTML into one of their comments like the following:

1<img src="http://app.example.com/example-logo.png" />

When a user authenticated to app.example.com views this comment, their browser will fire off a request for example-logo.png over an insecure HTTP connection. Since the app.example.com cookie was not set Secure, the browser will include the cookie over this connection — exposing it to the network.)

If you are connected to an insecure public wireless network in your favorite coffee shop and open your browser to log in to your website CMS management which allows HTTP and HTTPS connections. A malicious attacker sitting on the same network can then perform a MiTM (Man in The Middle) attack on the clients that are connected to the insecure wireless network. If you used HTTP to login to your site and do not have the Secure flag enabled, the attacker will be able to steal your cookie, Even if you are using HTTPS in some cases an attacker may be able to downgrade your connection to HTTP using an attack called SSLStriping.

Is My Application Vulnerable?

If your application is available over both HTTP and HTTPS versions with the same login, it may not meet requirements. After logging in, change the “https” in the URL bar of the browser to “http”. If you are still logged in, your application is vulnerable.

All applications should follow the simple test procedures below to determine if they follow best practices.

How Can I Test My Application?

A simple way to examine cookie status is to use the View Cookies Firefox extension, written by Edward Martin. Simply install the add-on, restart Firefox and log in to your application normally. Under the Tools menu, select Page Info and click on the Cookies icon. You will see a list of all the cookies sent to the page, and the last column will identify if the Secure flag was set with the cookie.

Cookies list for page

Session cookies that authenticate a user to the application must always be marked Secure.

Examine the contents of any cookies not identified as secure. Do they contain information which is sensitive, personally identifiable (such as an email address), or which influences the behavior of the application? For any such cookies the server must set the Secure flag.

You can easily test web server configuration for HTTPS using the online tool provided by SSL Labs at https://www.ssllabs.com/ssldb/. Simply type in the URL for your server to get a detailed report.

If your assessment shows severe errors in the SSL Labs assessment, they must be corrected before your site can be integrated with AppExchange.

Be aware that SSL Labs publishes a list on their SSL server test page of the 10 most recent worst-rated sites. If your site scores poorly, it may show up on that list for a while. Of course, if your site scores well, it may appear on the list of recent best-rated sites.

An alternative SSL testing tool is SSLScan from Titania.

How Do I Protect My Application?

Apex and Visualforce Applications

Avoid loading any resources over http, instead load all resources over https. This includes images. Note that all scripts must be loaded from static resources. This applies to sites, including Experience Cloud sites, as well as Lightning Components or Visualforce pages.

General Guidance

Try to use HTTPS exclusively for your web application. It is difficult to properly secure sites that use HTTP for some features or pages. If HTTP is necessary, make the HTTP-accessible features unauthenticated or create a different session identifier for that portion of the site that is not tied to the secure session identifier. If your site or application has secure and insecure modes, Salesforce.com users must be automatically opted-in to use the secure version exclusively.

Developers are often concerned about the performance impact of using HTTPS, and try to limit their use of it on performance grounds. However, a holistic review of an application’s performance will only rarely show HTTPS as the cause of significant performance problems. Many or even most web applications are far from optimally efficient, even over HTTP. For performance guidance, see:

Keep session cookie expiration times low (10 – 20 minutes). Do not store secret information like a user’s password in cookies and do not store information about user privilege levels (e.g. admin=true) as it may be subject to tampering.

Applications should not use or support URL rewriting for session management and should follow best practices for avoiding session fixation attacks, such as always issuing a new session identifier cookie on successful login. See:

http://en.wikipedia.org/wiki/Session_fixation

For additional information on secure session management, see:

http://www.owasp.org/index.php/Broken_Authentication_and_Session_Management

ASP.NET

Applications built with ASP.NET can secure their cookies using the application web.config or do so programmatically.

To configure secure cookies, use the requireSSL property of the httpCookies element of the system.web element, e.g. :

1<httpCookies domain="www.example.com" requireSSL="true" />

If setting cookies programmatically, use the HttpCookie.Secure property. See: http://msdn.microsoft.com/en-us/library/system.web.httpcookie.secure.aspx.

For information on configuring SSL for your web server or web site, see the following guidance:

Java

When creating cookies programmatically, the javax.servlet.http.Cookie API allows servlets and JSP pages to set the Secure flag for application-specific cookies using the call setSecure(true). Unfortunately, there is no standardized way to communicate to the container that cookies such as JSESSIONID or JSESSIONIDSSO should be set securely. Most containers will automatically set the secure flag when a session is created over an HTTPS link, but you should verify this using the test procedures detailed above.

To enable SSL in J2EE applications, use the web.xml configuration file. For each <web-app> entry, ensure that a <security-constraint> element exists with a <user-data-constraint>. In the <user-data-constraint>, set the following:

1<transport-guarantee>CONFIDENTIAL</transport-guarantee>

This signals the container that user data must be kept confidential and implies the use of HTTPS for this application. Some additional configuration may be required to support SSL — see the documentation specific to your web container.

Apache Tomcat 5.5: http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html
Apache Tomcat 6.0: http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html

The GlassFish application server supports configuration of this in versions 2.1 and 3.0, using the following syntax in sun-web.xml

1<?xml version="1.0" encoding="UTF-8"?>
2  <sun-web-app>
3    <session-config>
4      <cookie-properties>
5        <property name="cookieSecure" value="[true|false|dynamic]"/>
6      </cookie-properties>
7    </session-config>
8  </sun-web-app>

The upcoming version of the Servlet Specification (Servlet 3.0) will provide additional support for programmatic configuration of session cookie security using the new javax.servlet.SessionCookieConfig class.

PHP

Always set the boolean parameter secure to true when calling setcookie. This value is set to false by default.

Use session_regenerate_id when logging in users to prevent session fixation attacks.

For more guidance on PHP security, see:

http://phpsec.org/projects/guide/4.html

Ruby on Rails

Always set the boolean parameter secure to true when creating a new CGI::Cookie object. This value is set to false by default.

Use reset_session when logging in users to prevent session fixation attacks.

For more guidance on Ruby on Rails security, see:

Configuring Web and Application Servers for Strong SSL Cipher Suites

Microsoft IIS

For all versions of IIS on all versions of Windows Server 2003 or below, SSL and TLS protocol and cipher suite support is configured in the Windows Registry. For instructions on modifying the configuration under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL, see the following article from Microsoft Support: http://support.microsoft.com/kb/245030.

On Windows Server 2008 and Windows Server 2008 R2, SSL cipher suites are configured via Group Policy. Start gpedit.mscand go to Administrative Templates → Network → SSL Configuration Settings. Scroll to the bottom of the Help section for the property and follow the instructions on “How to modify this setting”. See http://msdn.microsoft.com/en-us/library/bb870930(VS.85).aspx for additional information.

Apache

Use the SSLCipherSuite directive with mod_ssl to configure available cipher suites. Use only HIGH ciphers and disable SSLv2. For complete configuration information, see http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslciphersuite.