OWASP Top Ten 2010 Web App Risks

"OWASP was started in September 2000 with its mission to create an open source community where people could advance their knowledge about web application and web services security issues by either contributing their knowledge to the education of others or by learning about the topic from documentation and software produced by the project. At the time the web application security market was just emerging and certain vendors were pedaling some significant marketing claims around products that really only tested a small portion of the problems web applications were facing and service companies were marketing application security testing that was really left companies with a false sense of security."

The OWASP Top Ten List represents a broad consensus about what the most critical web application security flaws are, as determined by a variety of security experts from around the world. This information is very useful for determining if a web application being secure code. The OWASP survey has added extra weight as it has become a recommendation or required best practice from a number of highly regarded sources.The major companies all using the OWASP top 10 as a guide in their web application development.

The OWASP Top 10 web Application Risks as of 2010 list, are

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

This has been one of the biggest security vulnerabilities on the web for some time now.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

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.

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.

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 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

Web apps that redirect or forward users to other URLs without proper validation of input data used to make such decisions may be vulnerable to attacks that redirect users to phishing or malware sites.