OWASP Top 10 Vulnerabilities Review

This article was originally posted at the Clearent Developer Blog.

My company, Clearent, is subject to an annual PCI audit. A part of that audit is being secure against the OWASP Top 10 Web Application Vulnerabilities.  I thought this would be a good time to review that list.

The OWASP.org PDF is the best source of information if you are creating web applications.  Below is a listing of the 10 vulnerabilities and a brief explanation of them.

Top Ten Web Application Vulnerabilities:

1. Injection: This vulnerability covers all kinds of injection attacks, including SQL injection.  Applications need to ensure that user-entered data can’t modify execution paths of the application itself.  It is important to guard against data coming into the application, as well as data being retrieved by the application.
2. Broken Authentication and Session Management: Quite often developers create all of their application’s functionality themselves, and introduce bugs.  Authentication and Session management are no different.  If possible, use tried-and-true third party applications to handle these functions.
3. Cross-Site Scripting (XSS): XSS is a nasty vulnerability that typically hijacks a user’s browser to access a malicious website or to steal data.  Applications generally protect against this flaw by properly escaping data entered through the browser.
4. Insecure Direct Object References: This vulnerability typically happens when a developer exposes file names, unique identifiers or other “internal” data that would allow an attacker to directly manipulate the system, bypassing data validation checks.
5. Security Misconfiguration: Not locking down systems, changing default passwords, or keeping software up-to-date causes this vulnerability.  All of these things seem obvious, but if they are obvious to us, they are obvious to attackers as well.
6. Sensitive Data Exposure: Simply put, many applications expose things like credit card numbers and tax IDs.  This information must be closely guarded.
7. Missing Function Level Access Control: Applications should ensure that an action a user takes in a web application is one the user has been granted access to.  This check should occur in the web application and on the server side portion of the application as well.
8. Cross-Site Request Forgery (CSRF): This attack uses a user’s browser to submit requests on the user’s behalf without the user being aware of it.  Application frameworks are getting smarter about this vulnerability and make it easy for developers to thwart this attack.
9. Using Components with Known Vulnerabilities: Many applications utilize external frameworks, libraries, or applications.  Care needs to be taken to ensure these third-party packages don’t have flaws that can be exploited.
10. Unvalidated Redirects and Forwards: It is common to use HTTP redirects and forwards to control the flow of an application.  These redirects and forwards can be used to send a user to a malicious site and cause harm.

This listing is not an exhaustive explanation of the vulnerabilities and their remedies, but it is a good introduction to the concepts of web application security. You can learn more about Clearent’s PCI Certification and Compliance by following the link.

OWASP Vulnerability 10 - Unvalidated Redirects and Forwards

This article was originally published on the Clearent Developer blog.

In a previous post, I provided a high-level overview of the OWASP (Open Web Application Security Project) Top 10 web security vulnerabilities.  Ensuring that these security vulnerabilities don’t exist in a web application is a critical part of being PCI compliant.  This is the first of ten posts going into more detail on each of the vulnerabilities.

Number 10 on the list is Unvalidated Redirects and Forwards.  Quite often, modern web applications use HTTP redirects and forwards to control the flow of their application.  A vulnerable system can be used to redirect users to malicious sites or to download malicious code.  A system may be vulnerable if it uses query string parameters passed in the URL to redirect their application.  Here is an example of a URL that is vulnerable:

https://www.example.com/pagewithredirect.asp?link=someothersite.com

A simple, brute-force approach to preventing this vulnerability is to use a white list for redirects and forwards.  This approach codifies an “approved” list of valid URLs that can be used in an HTTP redirect or forward.  The application would verify any URL against this list.  If an application must use query string parameters to pass URLs for redirection, it is recommended to use a white list for the permitted values in that parameter.  The application should ensure that the value passed in is in the white list before actually issuing the redirect.

A similar approach to a white list is to map the allowed URLs that can be accepted as a parameter.  For instance, the browser may see

https://www.example.com/pagewithredirect.asp?link=desired_site

When the page pagewithredirect.asp parses the link parameter, it would then look up “desired_site” from a mapping and use the URL associated with the “desired_site” key.

Most modern web applications are built on top of an application framework such as MVC in a .NET application or Spring in a Java application.  These frameworks utilize a routing system that dictates how HTTP redirects are issued.  These frameworks do not use user-entered data to change the browser navigation.  They use application-defined paths that are traversed by the routing system.  In this way, applications built on top of these frameworks prevent malicious users from causing an application to route a user to a malicious site.

As we have seen, preventing Unvalidated Redirects and Forwards is fairly straightforward.  In future posts, we will do a deeper dive on the other security vulnerabilities.