OWASP Top 10 Web Vulnerabilties

A1: Injection
This refers to SQL injection attacks, which are typically unchecked user queries that can execute SQL-database commands at the back end. While there are many flavors of sql, such as MsSQL, and MySQL which all deal with different language sets, the same attacks generally effect them all. Such attacks include, entering comment characters to truncate the rest of a query, or adding an OR statement, to take a modified execution path. These types of attacks, which have immediate results on the database, are known as First Order Injection Attacks. Other attacks can take advantage of parametrized statements to set up what are called Second Order Injection Attacks; Second Order Attacks will be stored within the database until they are called later, upon which time the Second Order Attacks will execute as output from the database. Injection attacks can be devastating (For example LizaMoon), and are considered to be one of the most prevalent vulnerabilities on the web.

A2: Cross-Site Scripting (XSS)
Cross Site Scripting is typically an attack between users of a web application. Using Javascript or another client side languages, attackers able to execute commands within the victims browser to bypass access controls such as SOAP, or Simple Object Access Protocal. To simplify: An attacker can write a custom script, get a victim to visit that URL, then a payload will execute in the victim's browser, that could send the victim's cookie back to the attacker, allowing the attacker to session-jack the victim. This is just one flavor of XSS, and there are many ways to carry out these attacks. An attacker can leave malicious scripts on a page, or feed them directly, sometimes you don't even click a link. XSS attacks can be delivered through banners and ads aswell. Its all about what content the website allows user's to post, without strict sanitation, the website can become a danger to it's own users.

A3: Broken Authentication and Session Management
This vulnerability refers to how log-ons and credentials are handled. Are all credentials being transmitted with encryption all the time? This typically requires proper PKI be in place from beginning to end, not just once the user starts their session. For example, unless the website has https:// established before you enter your credentials, you are susceptible to extremely easy session management attacks, such as FireSheep. This also means the application ends your session in a timely fashion, as the longer you are logged in (and unware) the easier it is to compromise your session. That is why as a user you should A) Always check your certificates B) Always log out when you are done C) Never check the 'stay logged in' or 'remember me' functionality.

A4: Insecure Direct Object References
This vulnerability refers to access controls in regards to when a user is accessing a document stored by the web application. If this document can be accessed by someone else by entering the url or a special parameter, then it is susceptible to this type of attack. Object parameters should never be sent in the URL or header of a request, and authentication checks should be made every time. Although automated tools don't check for these kinds of vulnerabilities, they are easy for a curious attacker to find and exploit. They typically result in a loss of confidentiality, but could lead to even more escalations, so be careful what data you trust a web application with.

A5: Cross-Site Request Forgery (CSRF)
Much like a XSS attack, CSRF exploits both the trust a user has for a web application and for their browser. These vulnerabilities will execute client side code via an infected URL, then ride the victim's session on a known but separate website to perform transactions for the attacker.
Because the attacks are carried out from a seemingly legitimate source, they are often not detected by the 2nd site in the attack.

A6: Security Misconfiguration
Misconfiguration that allow attackers to capitalize on web application developer assumptions.


A7: Insecure Cryptographic Storage
The website may be using outdated crypto algorithms, or may not be applying encryption. The web application may also be storing the keys in an insecure location, rendering the encryption useless.

A8: Failure to Restrict URL Access
This vulnerability affects access controls in web applications. Is the page supposed to be viewable by everyone, or do you need authentication? Authentication checks should be performed everytime the page is requested, and if the user is not authorized they should receive a HTTP status code of 401


A9: Insufficient Transport Layer Protection
This vulnerability exists when the web application dosn't use proper encryption protocols. This vulnerability also exists if users can sniff traffic, or find out detailed information about your data transmissions. These vulnerabilities are common in applications that use their own encryption or certification schemes.

A10: Unvalidated Redirects and Forwards
This vulnerability is prevalent whenever a user can link from your page to a malicious page an attacker controls. Especially if the attacker can spoof the destination of the page, they can get unsuspecting users to navigate there based off the user's trust in the original page.