VSAQ

Warning — possible medium-risk issue

Please help protect users from themselves by enforcing certain minimum password requirements. It's up to you to determine the details of these requirements, but they should account for the sensitivity of the information and should conform to industry standards.

Warning — possible medium-risk issue

Setting the HttpOnly attribute is a very simple defense-in-depth mechanism. We highly recommended making use of it.

Warning — possible medium-risk issue

If you don't specify a session timeout, an attacker who has stolen a session ID once will have a permanent back door to the application. Be sure to implement a timeout — even if it's fairly long, it's still better than no timeout at all).

Warning — possible medium-risk issue

Unless sessions are invalidated on logout, an attacker who has stolen a session ID will have access to the user's data until the session expires. Make sure all logout actions invalidate the session ID.

Warning

You didn't select a strategy for protecting against cross-site scripting.

Warning — possible medium-risk issue

Escaping user input on each page individually is a fairly dangerous strategy: it's very easy to miss something. We recommend using a templating system that automatically escapes user input, ideally in a context-sensitive fashion. Some examples are listed below. Note that not all of these are context-sensitive, so you may still need to do manual escaping (or explicitly tag a variable in the template) when the context is something other than HTML.

• Django (Python)
• Google CTemplates (C++)
• Jsilver (Java)
• Closure/Soy (Javascript, Java)
• JQuery (JavaScript)
• Smarty (PHP)

Warning — possible medium-risk issue

Unfortunately, due to error-correcting behavior and browser quirks, getting HTML sanitization right is very difficult. The sanitization code has to build an in-memory representation of the DOM, and then serialize that to a known-safe format. Some libraries do this correctly, so we highly recommended using a well-tested library.

Warning — possible medium-risk issue

Not setting both a content type and a character set often leads to cross-site scripting vulnerabilities. For example, if the application outputs JSON but sets the content type to text/html, this might result in XSS because JavaScript/JSON escaping is different from HTML escaping. We recommend that you thoroughly audit your code for pages that don't set the content type correctly.

Warning — possible medium-risk issue

Hosting and serving user-provided content is almost guaranteed to introduce XSS vulnerabilities. Because of various browser quirks, countermeasures (such as setting a Content-Disposition: attachment header) do not provide full protection. We recommend serving user-provided content on a domain separate from all domains that have authentication cookies. However, this approach introduces another problem, if access to the content is intended to be authenticated. You can solve this by using short-lived random tokens, or by serving each document from a separate domain. If you use the latter approach, each domain should have a unique set of authentication cookies, valid only for the one document that's served from the domain.

Warning — possible medium-risk issue

We recommend that you thoroughly audit your code for DOM-based XSS vulnerabilities, and put procedures in place so that future code is also protected.

Warning — possible medium-risk issue

Manually escaping SQL (or related) queries is error-prone and very difficult to do consistently. Here are a couple of examples:

• PHP provides the function mysql_escape_string for escaping user input that will be used in a database query. Unfortunately, that function does not take into account the character set of the connection, so it may still be possible to smuggle in user input that will be interpreted as part of the SQL query. Applications should use mysql_real_escape_string instead.
• In SQL, numbers do not need to be surrounded with quotation marks when used in a statement. For example, SELECT username WHERE id=123 is perfectly valid. But if user-provided input that will be used as a number is not confirmed to be actually numeric, the resulting code will be vulnerable to SQL injection (even if the input is escaped).

We highly recommend using something like prepared statements, or using an ORM layer consistently throughout the application. Make sure you have procedures in place to enforce your approach (such as static tests when code is checked into the repository).

Warning — possible medium-risk issue

Enabling Java in the browser exposes users to a variety of security issues. We strongly discourage requiring Java.

Warning — possible medium-risk issue

Storing uploaded files on the file system can be dangerous. Here are a few issues that can occur:

• Path traversal: The names of uploaded files must be carefully sanitized to prevent attackers from uploading files with paths in the name, such as ../../../../some_existing_file.html. Files like these can end up in the wrong directory.
• Null bytes: The names of uploaded files must be examined for null bytes, which can cause file names to be truncated (e.g., a file called evilfile.exe[0x00].gif might become evilfile.exe when stored on disk).
• Interpretation: Files on the file system are much more likely to end up being interpreted. For example, if an attacker manages to store an uploaded file somewhere underneath the web root and names it evilfile.php, it might be executed as PHP code by the web server.

To prevent issues like these, store user-uploaded content in a database instead. If your application stores files on the file system, be sure to implement careful handling, validation, and sanitization of uploaded files.

Warning — possible medium-risk issue

Some web servers are configured by default to allow double file extensions. For example, if a user uploads a file called malicious.php.gif, it might actually be executed as PHP code upon retrieval. Because you store uploaded files on the file system, this issue may affect your application. Make sure your web server uses only the last extension (i.e., the part after the right-most dot in the file name) when determining how to process the file.

Warning — possible medium-risk issue

Re-encoding files uploaded by users is usually a very good approach. However, note that because the decoding and re-encoding works on untrusted user input (and because parsing is difficult and error-prone), it's best to perform these operations in a sandbox. That way, even if an attacker successfully exploits a vulnerability in the parser, the effects would be constrained to the sandboxed environment. Various sandboxing APIs are available, such as the Seccomp library for Linux.

You could also run the decoder/encoder on an isolated virtual machine that's regularly reset to a predefined state. Note, however, that a successful attacker would still be able to observe all incoming and outgoing files, unless the reset happens after each individual file operation.

Even with a sandboxed encoder, some attacker-provided content may survive the re-encoding. For example, in images, the EXIF metadata may be left intact. If this occurs and the content type is incorrectly set (or browser content-sniffing behavior kicks in), cross-site scripting vulnerabilities can result.

Warning — possible medium-risk issue

Unit tests have become quasi-standard for testing the functionality of software at a low level. Although this questionnaire focuses on security, the functional correctness of the application is also important. Particularly for web applications, where it is difficult (often impossible) to fall back to a previous version, functional bugs can cause problems with both integrity and availability. Consider implementing unit tests.

Warning — possible medium-risk issue

Scalable security depends on engineers doing their part — and common-sense, low-overhead unit tests are one of the most cost-efficient defenses available. Unit tests can help validate security parameters and avoid regressions that reintroduce security bugs. We strongly recommend including security checks in your unit tests.

Warning — possible medium-risk issue

Exceptions and crashes often indicate an underlying security problem. Monitoring the deployed application can go a long way toward quickly identifying and subsequently fixing vulnerabilities. In carefully designed software products, exceptions should be a fairly rare occurrence; it therefore usually does not introduce significant overhead to monitor for them.