Most Critical Web Application Security Vulnerabilities

Most Critical Web Application Security Vulnerabilities

The Open Web Application Security Project (OWASP) is dedicated to helping organizations understand and improve the security of their web applications and web services. Web application security has become a hot topic as companies race to make content and services accessible though the web. At the same time, hackers are turning their attention to the common weaknesses created by application developers.

When an organization puts up a web application, they invite the world to send them HTTP requests. Attacks buried in these requests sail past firewalls, filters, platform hardening, and intrusion detection systems without notice because they are inside legal HTTP requests. Even “secure” websites that use SSL just accept the requests that arrive through the encrypted tunnel without scrutiny. This means that the web application code is part of the security perimeter. As the number, size and complexity of your web applications increases, so does perimeter exposure.

The following are the most significant web application security vulnerabilities.

A1) Injection: In a code injection attack, attackers insert malicious code into an entry field for execution. SQL injection is the most common injection attack. SQL injection is possible when user input fields allow SQL statements to query the database directly.

SQL injection attacks can ruin a database. Using SQL injection, attacker can: Spoof identity, tamper with existing data, void transactions, change account balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server.

Applications include many built-in features to protect against injection attacks. Here are few examples:

Validated input – validates user input by default, using basic edit checking. This ensures that the content entered via the UI is appropriate for each field.

White-lists and black-lists – Lets you add configurable white-lists to your applications. These can further restrict user input, and prevent applications from processing malicious character combinations.

Bind Variables – Takes the advantage of bind variables (parametrized queries) when running SQL queries. Bind variables reduce the risk of injection when constructing the queries that include user input.

A2-Broken Authentication and Session Management: This security risk stems from improper implementation of authentication and Session Management function. It lets attackers assume user identities and perform any action that user could perform. Privileged accounts are frequent targets of this attack.

This vulnerability gives attackers full access to a user’s account, or all accounts in a system. Once attacker gains access, they can do anything the victim could do, such as: place orders, alter data, add/remove data, and more.

Both code review and penetration testing can be used to diagnose authentication and session management problems. Carefully review each aspect of your authentication mechanisms to ensure that user’s credentials are protected at all times, while they are at rest (e.g., on disk), and while they are in transit (e.g., during login). Review every available mechanism for changing a user’s credentials to ensure that only an authorized user can change them. Review your session management mechanism to ensure that session identifiers are always protected and are used in such a way as to minimize the likelihood of accidental or hostile exposure.

Defining and documenting your site’s policy with respect to securely managing users credentials is a good first step. Ensuring that your implementation consistently enforces this policy is key to having a secure and robust authentication and session management mechanism.

Some critical areas include:

Password Strength – passwords should have restrictions that require minimum size and complexity for the password. Password Use – Users should be restricted to a defined number of login attempts per unit of time and repeated failed login attempts should be logged. Passwords provided during failed login attempts should not be recorded, as this may expose a user’s password to whoever can gain access to this log. The system should not indicate whether it was the username or password that was wrong if a login attempt fails. Password Change Controls - A single password change mechanism should be used wherever users are allowed to change a password, regardless of the situation. Users should always be required to provide both their old and new password when changing their password (like all account information).

Password Storage - All passwords must be stored in either hashed or encrypted form to protect them from exposure, regardless of where they are stored. Hashed form is preferred since it is not reversible.

Protecting Credentials in Transit - The only effective technique is to encrypt the entire login transaction using something like SSL.

Session ID Protection – Ideally, a user’s entire session should be protected via SSL. If this is done, then the session ID (e.g., session cookie) cannot be grabbed off the network, which is the biggest risk of exposure for a session ID.

A3 Cross-Site Scripting (XSS) Flaws: Cross-site scripting (XSS) lets attackers inject client-side script into Web pages viewed by other users. An XSS vulnerability arises when Web applications take data from users and dynamically include it in Web pages without first properly validating the data.

With XSS, an attacker can perform malicious actions, such as: take over a user account, spread viruses, remotely control the user’s browser, scan/exploit intranet appliances and applications, and more.

The best way to protect a web application from XSS attacks is ensure that your application performs validation of all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a rigorous specification of what should be allowed. The validation should not attempt to identify active content and remove, filter, or sanitize it.

A4 Insecure Direct Object References: A Direct Object Reference occurs when a developer exposes a reference to an internal implementation object in the URL string. When a file, directory, database key or internal ID number is visible in a URL, your data is at risk. Hackers can manipulate vulnerability to gain access to user’s sensitive data.

With this vulnerability, an attacker could access and manipulate organization’s data, such as: access customer account information, charge online purchases to user’s credit card, leak sensitive corporate data and