Technical

10 Dangerous Web Vulnerabilities

Chris Coley

1. Injection

Injection attacks attempt to use application code to access or corrupt a database, network configuration, or operating system content. Typically, injection attacks are accomplished via a web request (often a form submission) in which submitted data is not properly validated en route to the receiving environment.  An unvalidated, malicious request can contain embedded code intended to execute on a database, a network, or an operating system configuration file.  Such a request can allow access to a remote user or it can simply wreak havoc on the system.

Proper defense against injection attacks includes implementation of rigorous validation of input on both the client and the server of any web application.

2. Cross-Site Scripting (XSS)

Often used in conjunction with phishing, social engineering, and other browser exploits, XSS attacks inject malicious HTML or client-side scripts into web pages viewed by other users, thereby bypassing access controls that browsers use to make sure requests are from the same domain (same origin policy).

By these means, an attacker can gain elevated access privileges to sensitive page content, session cookies, and a variety of other client-side objects through an XSS attack. Some XSS attacks can be tracked to DOM-based or local cross-site script vulnerabilities within a page's client-side script itself, often called non-persistent or reflected XSS vulnerabilities.

3. Session Fixation

Session Fixation is an attack technique that forces a user's session ID to an explicit value. Depending on the functionality of the target website, a number of techniques can be utilized to "fix" the session ID value. These techniques range from Cross-Site Scripting exploits to peppering the web site with previously made HTTP requests. After a user's session ID has been fixed, the attacker will wait for that user to login. Once the user does so, the attacker uses the predefined session ID value to assume the same online identity.

Without active protection against Session Fixation, the attack can be mounted against any website that uses sessions to identify authenticated users. Web sites using session IDs are normally cookie-based, but URLs and hidden form fields are used as well. Unfortunately, cookie-based sessions are the easiest to attack. Most of the currently identified attack methods are aimed toward the fixation of cookies.

Session Fixation is one of many consequences of improper authentication management, along with weak credentials, brute force allowance, and information leakage.

4. Using Components with Known Vulnerabilities

Modern web applications are built using collections of plugins, libraries and frameworks that all run with the same access levels as the core application code. Vulnerabilities in these components are some of the most common ways that attackers gain access to sites because the vulnerabilities are widely disclosed and common plugins or libraries can be running on millions of websites, creating a very enticing target for attackers.

5. Information Leakage

Camouflage should be "standard issue" for web applications. The first task of a web attacker (a cyber criminal, internal or external) is to determine your operating system, Web server, application server and database platforms.

The most successful attacks are often targeted attacks, so removing or obfuscating the signatures of your technology platforms -- both obvious ones like the server name header or file extensions in HTTP, or the TCP/IP window size, as well as more subtle signatures, like cookie names, ETag formats, HTTP header order, or services running on IP/port combinations -- is an important type of countermeasure in itself.

Obfuscation can either dissuade intruders from attacking your website or application altogether or force them to make incorrect assumptions that lead them to try the wrong types of attacks (for instance, a Linux/UNIX hack on a Windows system). In turn, this makes it easier for firewalls and IDS systems to better identify and block those attacks directly.

6. Remote File Inclusion (RFI)

Remote File Include (RFI) is an attack technique used to exploit "dynamic file include" mechanisms in web applications. When web applications take user input (URL, parameter value, etc.) and pass them into file include commands, the web application might be tricked into including remote files with malicious code.

Almost all web application frameworks support file inclusion. File inclusion is mainly used for packaging common code into separate files that are later referenced by main application modules. When a web application references an include file, the code in this file may be executed implicitly or explicitly by calling specific procedures. If the choice of module to load is based on elements from the HTTP request, the web application might be vulnerable to RFI.

7. Brute Force

A, B, C, D, Admin Access... A brute force attack, sometimes called a dictionary attack, is a method of defeating a cryptographic authentication/authorization scheme by trying a large number of possible answers. The best example is exhaustively working through all possible keys in order to discover a password combination.

Like a zero day attack, brute force attacks are often used to find open, unprotected directories or to break authentication and authorization layers. Effective request throttling, tracking, and limiting the frequency of Web requests per second to a particular login file or directory often defeats this form of automated attack.  The continued success of brute force attacks reaffirms the need for all web applications to implement proper monitoring and logging regimes.

8. Cross-Site Request Forgery

Cross-site request forgery (CSRF or XSRF), also known as a one click attack or session riding, is an exploit very similar to an XSS attack. Rather than an attacker injecting unauthorized code into a website, a cross-site request forgery attack only transmits unauthorized commands from a user that the website or application considers to be authenticated.

At risk are websites and applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. These attacks are characteristic vulnerabilities of asynchronous request-based applications, an extremely common trait on the modern web. A user that is authenticated by a cookie saved in their web browser could unknowingly send a trusted HTTP request to a site thereby causing an unwanted action (for instance, withdrawing funds from a bank account).

9. Insecure Storage

Web applications that do not use appropriate encryption for sensitive information such as social security numbers and credit card information leave users open to compromise in the event of an attack.

Organizations should take stock of the threat landscape and make sure sensitive data is protected both in transit and at rest.  Further, all storage, whether in production environments or in backups, should be encrypted with the keys managed and stored separately.

Furthermore, user credentials must always be salted and hashed before storage with a secure, one-way hashing algorithm.  PINT has unfortunately seen too many plaintext passwords in new customers’ databases to end this post without making this point…an encrypted database doesn’t do any good if anyone can just log in!

10. Insufficient Logging & Monitoring

Logging and monitoring may seem redundant, but they serve unique purposes. Without appropriate monitoring and alerts, attacks or breaches may go unnoticed for a long time. On several occasions, PINT inherited web applications and discovered ongoing breaches that were leaking sensitive data, typically unknown to the previous developers or stakeholders.

Detecting breaches is only half the fight however, and identifying how the attacker breached your application is vital to preventing it from happening again. Without detailed logging that extends back to before the attacker gained access, all you have to look at is symptoms of the core issue, and you may not be able to determine exactly what the attacker did or what other breaches may exist in the application.

Tell us about your project