Security Guidelines

Security Best Practices

Users connect to Box using mobile, API, and web application integrations. This article provides a set of security guidelines specific to websites integrating with the box APIs or embedding box on their website. For a list of guidelines specific to mobile, please visit our iOS security guidelines, and Android security guidelines pages

Collecting, Sharing, and Storing Data

Collecting and sharing data

Prior to obtaining any information about or from your users, complete these tasks:

  1. Publish a privacy policy to inform them about how their information will be collected, shared, and transferred.
  2. Consult with your company’s privacy officer or representative for further information regarding privacy requirements.

Storing Data

Information about the user or content from the user should be stored in an encrypted or hashed format.

Password and token storage guidelines

  • User tokens (including all OAuth tokens) used for authentication to box must be encrypted using a strong encryption cipher and use a unique initialization vector per account.
  • When verifying users passwords for authentication purposes, passwords should be stored using a strong one-way hashing algorithm with a unique salt [D08] for that account.
  • When storing passwords used to connect to other systems, the password should be encrypted using a strong encryption cipher using a unique initialization vector [D07] and secret for that account.

User data storage guidelines

  • All user content should be encrypted using a unique initialization vector [D07] per file/db row using a strong cipher.

Storage medium specific guidelines

  • Database
    • Connections to databases where user content is provided within a query, must be parametrized to prevent the exploitation of SQL Injection [D01] vulnerabilities.
  • Filesystem
    • All user content stored on the filesystem (including temporary files) must restrict permissions of the files/directories created and ensure that the following permissions are restricted to only the necessary groups/users.
    • Umask Permission Level [D05]
    • Directory Permissions [D06]
    • File Permissions [D06]
    • Temporary files should be periodically deleted to ensure that remnant data is not accidentally left behind.

Recommended Encryption/Hashing Storage Ciphers

  • Encryption: AES 256 [D02] in CTR or CBC mode [D04]
  • Hashing: Sha256 (SHA-2) [D03]

Caching Data: Restrict usage of HTTP level caching

The HTTP Protocol specifies several mechanisms [CD1] to support caching at the browser and proxy level. A best practice is to avoid caching user PII/content at either the browser or proxy level by using HTTP headers [CD1] to instruct the browser, and any intermediate proxies, not to save the contents of a response.

Note: Many web and application servers enable HTTP-level caching by default, and you may need to disable this caching at the server level.

Secure transport, and serving up content

Box takes the security of our user content seriously, and requires that our partners transport Box user content over SSL/TLS at every hop. When connecting to systems other than Box or serving up content to your users it’s important to ensure the guidelines below are adhered to.

Weak Cipher Support

The encryption ciphers supported by the server may allow an attacker to eavesdrop on the connection. Verify the following guidelines:

  • When serving up content to your users [SSL01], only strong ciphers are enabled.
  • When connecting to other remote systems ensure that your client does not connect using a weak cipher if the server supports it.

Mixed content

When serving up content to your users over SSL, it’s important that you do not include content served over HTTP such as Images, JavaScript, Flash, or CSS. By mixing HTTP content with HTTPS content, you expose your users to man in the middle attacks and eliminate the security benefits [SSL02] that SSL/TLS provides.

Cookie Security

Cookies provide several mechanisms to enhance the security of your users.

  • Secure Flag: The Secure cookie attribute [C1] instructs the browser to never send a cookie over a non-SSL connection. Use this attribute for session related cookies (at a minimum). If possible, set this attribute for all cookies on your website.
  • HttpOnly Flag: The HttpOnly cookie [C2] attribute instructs the browser to disable cookie access from the DOM. This prevents flash, VBScript, and JavaScript from accessing the cookie/s. If a vulnerability such as cross-site scripting is discovered in your domain, this attribute prevents the theft of existing user sessions. When possible, add this attribute to all cookies.
  • Cookie Paths: The path cookie attribute [C3] instructs the browser to only send cookies to the specified path. If this attribute is not set, or is set to /, then the cookie is sent to all paths. If your domain contains multiple sub-directory paths, and certain cookies are not required outside of a particular directory, consider setting cookie paths to prevent leakage to other portions of your website.
  • Cookie domain scope: The domain cookie attribute [C3] instructs the browser on the domains to which a cookie should be sent. For example, b.site.com can set a cookie for *.site.com. When this occurs, the browser send whatever cookie is set on b.site.com to all .site.com sites. Unless you have an explicit need to have a cookie cross domains, explicitly set the domain name attribute to the current domain.

Input and output validation

Validating Input

Prior to performing any type of action against data submitted by the user, the first step is to ensure the user is properly authorized to perform the action. Next perform several forms of validation against the data they submit. The Web Application Security Consortium has written a lengthy article on the subject that is highly recommended [I1]. We also recommend reviewing the OWASP Top Ten [I4], another good starting point for issues that may occur during the input process.

Validating output

The Web Application Security Consortium has a fairly comprehensive article [I2] on the locations data can be reflected, attacks that may be possible, and approaches to verifying and sanitizing data. They also have an article on preventing information disclosure [I3] which may provide an attacker with information about your users, environment, or application.

Parameter passing concerns

An extension of input and output validation issues involve the interaction with other applications, and systems. As mentioned briefly above, SQL Injection [D01] exploits the concatenation of user influenced data into a SQL statement, which can allow a malicious user to pass their own queries to the database. Similar attacks also impact XML based query languages such as XQuery [I7] and XPath [I8].

This type of issue can also occur when passing arguments to external applications, and may result in system-level command execution (also known as OS commanding [I9]). When constructing XML, there are several attacks [I5][I6] that can occur when an attacker is able to influence the structure of an XML message.

Logging and Error Handling

Logging

Logging is necessary to identify potential issues within your application.When logging information, do not log data belonging to the user or their sessionid in clear-text. The following fields should never be logged in clear text, and should be encrypted at all times when at rest.

  • OAuth/Security Tokens
  • Passwords
  • File contents
  • User Personally Identifiable Information, or PII (Credit Cards, SSN’s or National Identifiers, etc)
  • Encryption keys and secrets

Error Handling

It’s normal for your application to have error conditions, and it’s important to communicate the right level of information back to the user. Your application should handle all errors prior to passing data back to the user, and should never display content such as stack traces, system path information, or other information about the system or framework.

Even if the errors are handled, it’s possible that you are still providing useful information which can be used to determine the existence of user accounts, or other sensitive information. A common scenario is described in the Differences in page response behaviors’ section of WASC’s Information Leakage [I3] article. Here, an attacker is able to identify registered users based on error response behavior and they can later perform phishing attacks against them.

Utilizing your framework’s security capabilities

Modern web frameworks provide security capabilities, either enabled by default, or as an extension. The three most common capabilities involve authorization, protection against Cross-site Request Forgery, and auto escaping to prevent Cross-site Scripting attacks [SC03] .

Authorization

When possible, use the web framework’s built-in authorization and session management capabilities. Building your own framework is risky and can open you to attacks such as session fixation, predictable session IDs, session expiration vulnerabilities, session destruction concerns, and various other attacks.

Cross-site request forgery

CSRF [SC02] is a common site vulnerability. To prevent CSRF, a nonce is typically sent with every request by the user and verified on the server side prior to allowing any state changing action. Creating an anti-CSRF framework can be extremely complicated. It is strongly advised to use an existing anti-CSRF framework, or extension to handle this for you.

Cross-site Scripting

Many frameworks support automatically HTML entity encoding variables being outputted to the user. Identifying the right context for escaping content can get complicated. Use an existing framework since the possibility for making a mistake is high.

Configuration best practices

PHP’s configuration file provides settings that can further lock down your application. By taking advantage of these capabilities [SC01] you can prevent the exploitation of vulnerabilities within your code. Review your framework’s security documentation to see what security capabilities can be toggled via configuration changes.

References

Collecting, Sharing, and Storing Data

Caching data: Restrict usage of HTTP level caching

Secure transport, and serving up content

Cookie Security

Input and output validation

Utilizing your framework’s security capabilities

Security Guidelines