Complete and Detailed OWASP Cheat Sheet, Cheat Sheet of Web Application Development

Download Complete and Detailed OWASP Cheat Sheet and more Cheat Sheet Web Application Development in PDF only on Docsity!

OWASP Cheat Sheets

Martin Woschek, owasp@jesterweb.de

April 9, 2015

Contents

Contents

These Cheat Sheets have been taken from the owasp project on https://www.owasp. org. While this document is static, the online source is continuously improved and expanded. So please visit https://www.owasp.org if you have any doubt in the accuracy or actuality of this pdf or simply if this document is too old. All the articles are licenced under the Creative Commons Attribution-ShareAlike 3. Unported^1. I have slightly reformatted and/or resectioned them in this work (which of course also is CC BY-SA 3.0).

(^1) http://creativecommons.org/licenses/by-sa/3.0/

Part I.

Developer Cheat Sheets (Builder)

1. Authentication Cheat Sheet

• Increased popularity of sub-addressing by providers such as Gmail (commonly using + as a token in the local-part to affect delivery)
• New gTLDs with long names (many regular expressions check the number and length of each label in the domain)

Following RFC 5321, best practice for validating an email address would be to:

• Check for presence of at least one @ symbol in the address
• Ensure the local-part is no longer than 64 octets
• Ensure the domain is no longer than 255 octets
• Ensure the address is deliverable

To ensure an address is deliverable, the only way to check this is to send the user an email and have the user take action to confirm receipt. Beyond confirming that the email address is valid and deliverable, this also provides a positive acknowledgement that the user has access to the mailbox and is likely to be authorised to use it.

Address Normalisation

As the local-part of email addresses are, in fact - case sensitive, it is important to store and compare email addresses correctly. To normalise an email address input, you would convert the domain part ONLY to lowercase. Unfortunately this does and will make input harder to normalise and correctly match to a users intent. It is reasonable to only accept one unique capitalisation of an otherwise identical address, however in this case it is critical to:

• Store the user-part as provided and verified by user verification
• Perform comparisons by lowercase(provided)==lowercase(persisted)

1.2.2. Implement Proper Password Strength Controls

A key concern when using passwords for authentication is password strength. A "strong" password policy makes it difficult or even improbable for one to guess the password through either manual or automated means. The following characteristics define a strong password:

1.2.2.1. Password Length

Longer passwords provide a greater combination of characters and consequently make it more difficult for an attacker to guess.

• Minimum length of the passwords should be enforced by the application. - Passwords shorter than 10 characters are considered to be weak [3].

While minimum length enforcement may cause problems with memorizing passwords among some users, applications should encourage them to set passphrases (sen- tences or combination of words) that can be much longer than typical passwords and yet much easier to remember.

• Maximum password length should not be set too low, as it will prevent users from creating passphrases. Typical maximum length is 128 characters.

1. Authentication Cheat Sheet - Passphrases shorter than 20 characters are usually considered weak if they only consist of lower case Latin characters.

• Every character counts!! - Make sure that every character the user types in is actually included in the password. We’ve seen systems that truncate the password at a length shorter than what the user provided (e.g., truncated at 15 characters when they entered 20). - This is usually handled by setting the length of ALL password input fields to be exactly the same length as the maximum length password. This is particularly important if your max password length is short, like 20- characters.

1.2.2.2. Password Complexity

Applications should enforce password complexity rules to discourage easy to guess passwords. Password mechanisms should allow virtually any character the user can type to be part of their password, including the space character. Passwords should, obviously, be case sensitive in order to increase their complexity. Occasionally, we find systems where passwords aren’t case sensitive, frequently due to legacy system issues like old mainframes that didn’t have case sensitive passwords. The password change mechanism should require a minimum level of complexity that makes sense for the application and its user population. For example:

• Password must meet at least 3 out of the following 4 complexity rules - at least 1 uppercase character (A-Z) - at least 1 lowercase character (a-z) - at least 1 digit (0-9) - at least 1 special character (punctuation) — do not forget to treat space as special characters too
• at least 10 characters
• at most 128 characters
• not more than 2 identical characters in a row (e.g., 111 not allowed)

As application’s require more complex password policies, they need to be very clear about what these policies are.

• The required policy needs to be explicitly stated on the password change page - be sure to list every special character you allow, so it’s obvious to the user

Recommendation:

• Ideally, the application would indicate to the user as they type in their new password how much of the complexity policy their new password meets - In fact, the submit button should be grayed out until the new password meets the complexity policy and the 2nd copy of the new password matches the 1st. This will make it far easier for the user to understand and comply with your complexity policy.

Regardless of how the UI behaves, when a user submits their password change re- quest:

1. Authentication Cheat Sheet

1.2.7.1. SSL Client Authentication

SSL Client Authentication, also known as two-way SSL authentication, consists of both, browser and server, sending their respective SSL certificates during the TLS handshake process. Just as you can validate the authenticity of a server by using the certificate and asking a well known Certificate Authority (CA) if the certificate is valid, the server can authenticate the user by receiving a certificate from the client and validating against a third party CA or its own CA. To do this, the server must provide the user with a certificate generated specifically for him, assigning values to the subject so that these can be used to determine what user the certificate should validate. The user installs the certificate on a browser and now uses it for the website. It is a good idea to do this when:

• It is acceptable (or even preferred) that the user only has access to the website from only a single computer/browser.
• The user is not easily scared by the process of installing SSL certificates on his browser or there will be someone, probably from IT support, that will do this for the user.
• The website requires an extra step of security.
• It is also a good thing to use when the website is for an intranet of a company or organization.

It is generally not a good idea to use this method for widely and publicly available websites that will have an average user. For example, it wouldn’t be a good idea to implement this for a website like Facebook. While this technique can prevent the user from having to type a password (thus protecting against an average keylogger from stealing it), it is still considered a good idea to consider using both a password and SSL client authentication combined. For more information, see: [4] or [5].

1.2.8. Authentication and Error Messages

Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration. An application should respond (both HTTP and HTML) in a generic manner.

1.2.8.1. Authentication Responses

An application should respond with a generic error message regardless of whether the user ID or password was incorrect. It should also give no indication to the status of an existing account.

1.2.8.2. Incorrect Response Examples

• "Login for User foo: invalid password"
• "Login failed, invalid user ID"
• "Login failed; account disabled"
• "Login failed; this user is not active"

1. Authentication Cheat Sheet

1.2.8.3. Correct Response Example

• "Login failed; Invalid userID or password"

The correct response does not indicate if the user ID or password is the incorrect parameter and hence inferring a valid user ID.

1.2.8.4. Error Codes and URLs

The application may return a different HTTP Error code depending on the authenti- cation attempt response. It may respond with a 200 for a positive result and a 403 for a negative result. Even though a generic error page is shown to a user, the HTTP response code may differ which can leak information about whether the account is valid or not.

1.2.9. Prevent Brute-Force Attacks

If an attacker is able to guess passwords without the account becoming disabled due to failed authentication attempts, the attacker has an opportunity to continue with a brute force attack until the account is compromised. Automating brute- force/password guessing attacks on web applications is a trivial challenge. Pass- word lockout mechanisms should be employed that lock out an account if more than a preset number of unsuccessful login attempts are made. Password lockout mech- anisms have a logical weakness. An attacker that undertakes a large number of authentication attempts on known account names can produce a result that locks out entire blocks of user accounts. Given that the intent of a password lockout sys- tem is to protect from brute-force attacks, a sensible strategy is to lockout accounts for a period of time (e.g., 20 minutes). This significantly slows down attackers, while allowing the accounts to reopen automatically for legitimate users. Also, multi-factor authentication is a very powerful deterrent when trying to prevent brute force attacks since the credentials are a moving target. When multi-factor is implemented and active, account lockout may no longer be necessary.

1.3. Use of authentication protocols that require no password

While authentication through a user/password combination and using multi-factor authentication is considered generally secure, there are use cases where it isn’t con- sidered the best option or even safe. An example of this are third party applications that desire connecting to the web application, either from a mobile device, another website, desktop or other situations. When this happens, it is NOT considered safe to allow the third party application to store the user/password combo, since then it extends the attack surface into their hands, where it isn’t in your control. For this, and other use cases, there are several authentication protocols that can protect you from exposing your users’ data to attackers.

1.3.1. OAuth

Open Authorization (OAuth) is a protocol that allows an application to authenticate against a server as a user, without requiring passwords or any third party server that acts as an identity provider. It uses a token generated by the server, and provides how the authorization flows most occur, so that a client, such as a mobile application, can tell the server what user is using the service. The recommendation is to use and implement OAuth 1.0a or OAuth 2.0, since the very first version (OAuth1.0) has been found to be vulnerable to session fixation.

1. Authentication Cheat Sheet

authentication framework. UAF works with both native applications and web appli- cations. U2F augments password-based authentication using a hardware token (typically USB) that stores cryptographic authentication keys and uses them for signing. The user can use the same token as a second factor for multiple applications. U2F works with web applications. It provides protection against phishing by using the URL of the website to lookup the stored authentication key.

1.4. Session Management General Guidelines

Session management is directly related to authentication. The Session Management General Guidelines previously available on this OWASP Authentication Cheat Sheet have been integrated into the Session Management Cheat Sheet on page 126.

1.5. Password Managers

Password managers are programs, browser plugins or web services that automate management of large number of different credentials, including memorizing and filling-in, generating random passwords on different sites etc. The web application can help password managers by:

• using standard HTML forms for username and password input,
• not disabling copy and paste on HTML form fields,
• allowing very long passwords,
• not using multi-stage login schemes (username on first screen, then password),
• not using highly scripted (JavaScript) authentication schemes.

1.6. Authors and Primary Editors

• Eoin Keary eoinkeary[at]owasp.org

1.7. References

1. https://www.owasp.org/index.php/Authentication_Cheat_Sheet
2. https://tools.ietf.org/html/rfc
3. http://csrc.nist.gov/publications/nistpubs/800-132/ nist-sp800-132.pdf
4. http://publib.boulder.ibm.com/infocenter/tivihelp/v5r1/index. jsp?topic=%2Fcom.ibm.itim.infocenter.doc%2Fcpt%2Fcpt_ic_ security_ssl_authent2way.html
5. http://www.codeproject.com/Articles/326574/ An-Introduction-to-Mutual-SSL-Authentication
6. http://en.wikipedia.org/wiki/Security_token

2. Choosing and Using Security Questions

Cheat Sheet

Last revision (mm/dd/yy): 04/17/

2.1. Introduction

This cheat sheet provides some best practice for developers to follow when choos- ing and using security questions to implement a "forgot password" web application feature.

2.2. The Problem

There is no industry standard either for providing guidance to users or developers when using or implementing a Forgot Password feature. The result is that developers generally pick a set of dubious questions and implement them insecurely. They do so, not only at the risk to their users, but also–because of potential liability issues– at the risk to their organization. Ideally, passwords would be dead, or at least less important in the sense that they make up only one of several multi-factor authenti- cation mechanisms, but the truth is that we probably are stuck with passwords just like we are stuck with Cobol. So with that in mind, what can we do to make the Forgot Password solution as palatable as possible?

2.3. Choosing Security Questions and/or Identity Data

Most of us can instantly spot a bad "security question" when we see one. You know the ones we mean. Ones like "What is your favorite color?" are obviously bad. But as the Good Security Questions [2] web site rightly points out, "there really are NO GOOD security questions; only fair or bad questions". The reason that most organizations allow users to reset their own forgotten pass- words is not because of security, but rather to reduce their own costs by reducing their volume of calls to their help desks. It’s the classic convenience vs. security trade-off, and in this case, convenience (both to the organization in terms of reduced costs and to the user in terms of simpler, self-service) almost always wins out. So given that the business aspect of lower cost generally wins out, what can we do to at least raise the bar a bit? Here are some suggestions. Note that we intentionally avoid recommending specific security questions. To do so likely would be counterproductive because many de- velopers would simply use those questions without much thinking and adversaries would immediately start harvesting that data from various social networks.

2.3.1. Desired Characteristics

Any security questions or identity information presented to users to reset forgotten passwords should ideally have the following four characteristics: