Security and Compliance
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 Zoom must be encrypted using a strong encryption cipher and use a unique initialization vector per 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.
Connections to databases where user content is provided within a query must be parametrized to prevent the exploitation of SQL Injection [D01] vulnerabilities.
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 limited 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. The 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 the response.
Many web and application servers enable HTTP-level caching by default, and you may need to disable this caching at the server level.
Transport and Content Security
Zoom takes the security of our user content seriously, and requires that our partners transport Zoom user content over SSL/TLS at every hop. When connecting to systems other than Zoom 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.
Cookie Security: Cookies provide several mechanisms to enhance the security of your users.
The Secure cookie attribute [C1] instructs the browser never to 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.
The path cookie attribute [C3] instructs the browser only to 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 specific 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 sends 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.
Before 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 operation. 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.
The Web Application Security Consortium has a reasonably 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.
The following fields should never be logged in clear text, and should be encrypted at all times when at rest:
- OAuth/Security Tokens
- File contents
- User Personally Identifiable Information, or PII (Credit Cards, SSN’s or National Identifiers, etc)
- Encryption keys and secrets
Logging and Error Handling
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.
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 before 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 can 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].
When possible, use the web framework’s built-in authorization and session management capabilities. Building your 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 before allowing any state change 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.
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.
[D01] http://projects.webappsec.org/SQL-Injection [D02] http://en.wikipedia.org/wiki/Advanced_Encryption_Standard [D03] http://en.wikipedia.org/wiki/SHA-2 [D04] http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation [D05] http://en.wikipedia.org/wiki/Umask [D06] http://www.freebsd.org/doc/handbook/permissions.html [D07] http://en.wikipedia.org/wiki/Initialization_vector [D08] http://en.wikipedia.org/wiki/Salt_%28cryptography%29 Caching data: Restrict usage of HTTP level caching
[CD1] http://www.mobify.com/blog/beginners-guide-to-http-cache-headers/ Secure transport, and serving up content
[SSL01] https://www.owasp.org/index.php/Testing_for_Weak_SSL/TSL_Ciphers,_Insufficient_Transport_LayerProtection%28OWASP-EN-002%29 [SSL02] http://projects.webappsec.org/Insufficient-Transport-Layer-Protection Cookie Security
[C1] https://www.owasp.org/index.php/SecureFlag [C2] https://www.owasp.org/index.php/HttpOnly [C3] https://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_path Input and output validation
[I1] http://projects.webappsec.org/Improper-Input-Handling [I2] http://projects.webappsec.org/Improper-Output-Handling [I3] http://projects.webappsec.org/Information-Leakage [I4] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project [I5] http://projects.webappsec.org/XML-Injection [I6] http://projects.webappsec.org/XML-External-Entities [I7] http://projects.webappsec.org/XQuery-Injection [I8] http://projects.webappsec.org/XPath-Injection [I9] http://projects.webappsec.org/OS-Commanding Utilizing your framework’s security capabilities
[SC01] http://www.madirish.net/199 [SC02] http://www.cgisecurity.com/csrf-faq.html [SC03] http://projects.webappsec.org/Cross-Site+Scripting