Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2569 posts at DZone. You can read more from them at their website. View Full User Profile

OWASP Top 10 Web Security Vulnerabilities

04.21.2010
| 21064 views |
  • submit to reddit
Web security has been a major topic of concern this year with the alleged Chinese-based attacks on GMail users, and more recently the infiltration of Apache's and JBoss' JIRAs.  In 2010, with a growing reemphasis on security, the Open Web Application Security Project (OWASP) has updated their list of the ten most serious web application vulnerabilities.  This list has only been updated in 2004 and 2007.  

1.  Injection

Using almost any source of data, an attacker can send a simple piece of code that exploits the syntax of a targeted interpreter.  Injection can lead to data loss, corruption, or complete host takeover.  To prevent injection, the use of interpreters must separate untrusted data from commands and queries.  An SQL call, for example, should use bind variables and avoid dynamic queries.

2.  Cross-Site Scripting (XSS)

This has been one of the biggest security vulnerabilities on the web for some time now.  The Hibernate and Apache JIRAs were recently compromised by cross-site scripting attacks.  It allows attackers to hijack a user's current session and either steal information or insert hostile content.  Static and dynamic tools can find some XSS problems automatically, but because each application builds output pages as JavaScript, ActiveX, Flash, Silverlight, etc., automated detection is insufficient.  Manual code review and penetration testing is needed.  To prevent XSS, your application must keep untrusted data separate from active browser content.

3. Broken Authentication and Session Management

Attackers can use flaws or leaks in the authentication or session management functions (e.g. passwords, session IDs) to impersonate users.  To combat this vulnerability, developers must have access to a single set of authentication and session management controls.  Credentials must be protected if they are stored using hashing or encryption.  Session IDs cannot be exposed in the URL or to session fixation attacks.



4.  Insecure Direct Object References.
This technique is used by an attacker who is already an authorized user.  They simply change a parameter value to refer a system object to another object to gain access to other data and compromise it.  All object references must have proper defenses by asking for authorization to specific resources and limiting indirect references to values authorized for the current user.  

5.  Cross-Site Request Forgery (CSRF)

In this attack, a forged HTTP request is used to trick victims into submitting them.  Image tags, XSS, and many other techniques are used to trick users.  Attackers use this to have hostile data manipulation performed on the victim's account.  The simplest test for this vulnerability is to check each link and form to see if they contain an unpredictable token for each user so that attackers can't forge malicious requests.  Unpredictable tokens should be included in the body or URL of each HTTP request and be unique for every user session and request.

6.  Security Misconfiguration

Default accounts, unused pages, unpatched flaws, and directories can all be accessed by attackers to gain unauthorized access.  Appropriate security hardening should be performed across the entire application stack to prevent this attack.  Software (including ALL code libraries) should be kept up-to-date and unnecessary ports, services, pages, accounts, etc. should be removed.  The security settings in development frameworks such as Spring, Struts, and ASP.NET should be configured properly.  

7.  Insecure Cryptographic Storage

Typically, hackers won't break through the cryptography directly.  Instead they'll find keys, get cleartext copies of data, or find channels that automatically decrypt.  To protect encrypted data, you must encrypt it in every area where it is stored long-term.  Decrypted copies of the data and keys must be protected by requiring authorization.

8.  Failure to Restrict URL Access

This vulnerability is so easy to exploit that it must not be ignored.  If the security hole exists, an attacker (authorized user, or possibly not) could simply modify a URL to access a privileged page and possibly escalate their privileges further.  Developers must verify every single page and make sure external security mechanisms or code level protections are configured properly for each page.  Policies should be highly configurable to minimize hard coded issues, and enforcement mechanisms should deny access by default by requiring specific grants for users.

9.  Insufficient Transport Layer Protection

If user network traffic is not monitored properly, an attacker can expose data and steal accounts.  A bad SSL setup can even facilitate MITM or phishing attacks.  The easiest solution is to require SSL for the entire site or at least on private pages.  The SSL provider should support only strong algorithms and the secure flag should be on all cookies.

10.  Unvalidated Redirects and Forwards

In this method, an attacker links to an unvalidated redirect and tries to trick users into clicking the link.  Since the link is to a valid site users are more likely to be tricked.  The attacker targets unsafe forwards to bypass security checks.  The simplest solution is to avoid using redirects and forwards altogether.  You can also have them calculate the destination without involving user parameters.  If these two solutions can't be implemented, then make sure that the supplied values for parameters are valid and authorized for the user.

For a complete overview on the subject of web security, you should download the document - The Ten Most Critical Web Application Security Risks for free at OWASP.org.

Images Credit: OWASP