Web Vulnerabilities

The OWASP Top 10 - Most Critical Web Application Security Risks RC2 are a list of the 10 most dangerous current Web application security flaws, along with effective methods of dealing with those flaws.

The Open Web Application Security Project (OWASP) is a non-profit organization dedicated to providing unbiased, practical information about computer and Internet application security. Project members include a variety of security experts from around the world who share their knowledge of vulnerabilities, threats, attacks and countermeasures.

1.Injection

Injection flaws, such as SQL, OS command, ORM and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter in executing the unintended command or accessing data without proper authorization.

As explained in the OWASP “Top 10” guide, injection flaws are quite easy to discover by analyzing the code, but frequently hard to find during testing sessions when systems are already deployed in production environments.

How to determine if you are vulnerable

The best way to determine if your applications are vulnerable to injection attacks is to search the source code for all calls to external resources (e.g., system, exec, fork, Runtime.exec, SQL queries, or whatever the syntax is for making requests to interpreters in your environment). Note that many languages have multiple ways to run external commands. Developers should review their code and search for all places where input from an HTTP request could possibly make its way into any of these calls.

The prevention of injection flaws has to be addressed in the coding phase. OSWAP suggests keeping untrusted data separate from commands and queries.

2.Broken Authentication

Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities (temporarily or permanently).

How to determine if you are vulnerable

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.

3. Sensitive Data Exposure

Many web applications and API do not properly protect sensitive data, such as financial, healthcare and PII. The most common flaw is simply not encrypting sensitive data. When crypto is employed, weak key generation and management, and weak algorithm usage is common, particularly weak password hashing techniques. Browser weaknesses are very common and easy to detect, but hard to exploit on a large scale. External attackers have difficulty detecting server side flaws due to limited access and they are also usually hard to exploit.

How to determine if you are vulnerable

The first thing you have to determine is which data is sensitive enough to require extra protection. For example, passwords, credit card numbers, health records, and personal information should be protected. For all such data:

Is any of this data stored in clear text long term, including backups of this data? Is any of this data transmitted in clear text, internally or externally? Internet traffic is especially dangerous. Are any old / weak cryptographic algorithms used? Are weak crypto keys generated, or is proper key management or rotation missing? Are any browser security directives or headers missing when sensitive data is provided by / sent to the browser?.

4. XML External Entity (XXE)

XXE Injection Attacks or XML External Entity vulnerabilities are a specific type of Server Side Request Forgery or SSRF attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser.

XXE attacks can precipitate Denial of Service (DoS), allow a malicious hacker to extract sensitive data or in worst case scenario remote access to local and remote files and services (Remote Code Execution).

How to determine if you are vulnerable

Many web applications that accept and respond to XML requests are vulnerable to XML External Entity (XXE) attacks due to default XML parser settings. Removing the vulnerability is as simple as configuring the parser to not allow external entities to be defined. The exact methods for configuring the parsers vary. Methods for several parsers are included on the XML external processing OWASP site.

5. Broken Access Control

Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access to other users' accounts, view sensitive files, modify other users' data, change access rights, etc.

How to determine if you are vulnerable

The most important step is to think through an application’s access control requirements and capture it in a web application security policy. We strongly recommend the use of an access control matrix to define the access control rules. Without documenting the security policy, there is no definition of what it means to be secure for that site. The policy should document what types of users can access the system, and what functions and content each of these types of users should be allowed to access. The access control mechanism should be extensively tested to be sure that there is no way to bypass it. This testing requires a variety of accounts and extensive attempts to access unauthorized content or functions.

If the access control documentation does not exist, then the website is most likely vulnerable.

The code that implements the access control policy should be checked. Such code should be well structured, modular, and most likely centralized. A detailed code review should be performed to validate the correctness of the access control implementation. In addition, penetration testing can be quite useful in determining if there are problems in the access control scheme.

6. Security Misconfiguration

Security misconfiguration is simply that – incorrectly assembling the safeguards for a web application. These misconfigurations typically occur when holes are left in the security framework of an application by systems administrators, DBAs or developers. They can occur at any level of the application stack including the platform, web server, application server, database, framework and custom code.

Attackers find these misconfigurations through unauthorized access to default accounts, unused web pages, unpatched flaws, unprotected files and directories and more. These security misconfigurations can lead an attacker right into the system and result in a partially or even totally compromised system.

How to determine if you are vulnerable

In many cases this is one of the easiest vulnerabilities to exploit. For example, if a system admin forgets to delete a default account with admin privileges, all an attacker has to do is to simply google the default credentials to login.

However, there can of course be more difficult alternatives of this vulnerability type that require more knowledge. All misconfigurations do not result in a possible full takeover, but may be used as part of a bigger attack.

The only way to discover security misconfigurations is to start looking over the system. Are there any default accounts left, and if so, have the passwords been changed? Are there any unnecessary feasures installed/enabled that can be removed? Accounts, unnecessary priviliges, ports, etc.

As it is one of the most common issues; does the error handling reveal overly informative error messages to users?

When it is possible to enforce better security in a framework, are those options chosen?

7. Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) remains one of the most common and deadly security vulnerabilities currently found in web-applications. XSS is an injection attack which is carried out on Web applications that accept input, but do not properly separate data and executable code before the input is delivered back to a user’s browser.

XSS attacks differ from other application-layer attacks in that an attacker does not target a victim directly. Instead, an attacker exploits a vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.

Like all injection attacks, XSS takes advantage of the fact that browsers cannot tell valid markup from attacker-controlled markup -- they simply execute whatever markup text they receive. In an XSS attack, the hacker injects a client-side script into web pages viewed by other users.

Javascript is the most widely used scripting language used to mount XSS attacks, primarily because Javascript is fundamental to most browsing experiences. However, XSS attacks also utilize VBSCript, ActiveX or any other executable active content.

How to determine if you are vulnerable

One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. A simple test is to take a current parameter that is sent in the HTTP GET request and modify it and view the response in yo8r browser.

Unfortunately, XSS vulnerabilities are difficult to prevent simply because there are so many vectors where an XSS attack can be used in most applications.

In addition, whereas other vulnerabilities, such as SQL injection or OS command injection, XSS only affects the user of the website, making them more difficult to catch and even harder to fix. Also unlike SQL injection, which can be eliminated with the proper use of prepared statements, there’s no single standard or strategy to preventing cross-site scripting attacks.

In order to be truly vigilant against XSS and other common, debilitating vulnerabilities, like the rest of the OWASP Top 10, it’s important to use a mix of code review, automated static testing during development and dynamic testing once the application is live, in addition, of course, to using secure coding practices that will help prevent vulnerabilities like cross-site scripting in the first place.

8. Insecure Deserialization

Serialization is a technique that many programming languages use to transfer complex data structures over the network and between computers.

It’s a process in which a programming object (such as a Java object) is essentially broken down into a series of bytes to make it easier to transport and then reassembled back into an object at the other end. The disassembling process from an object into a sequence of bits is called serialization, while the reassembly from the bits back to an object is called deserialization or unserialization.

The problem lies in the fact that many applications that accept serialized objects do not validate or check untrusted input before deserializing it. This gives attackers an opening to insert a malicious object into a data stream and have it execute on the app server.

For example, the attacker can send an executable, or a malware or may gain a complete command over the remote server. A recent blog post by FoxGlove Security described remotely executable exploits against several major middleware products including WebSphere, WebLogic, and JBoss.

How to determine if you are vulnerable

This is a tough one. The first thing a firm needs to do is find all the places in their programming code where they are using deserialization on untrusted data and harden it against the threat. Unfortunately, searching the code is only a partial solution, because frameworks and libraries from Java to C++ that are included in their applications might also create this exposure.

9. Using Components with Known Vulnerabilities

It is very common for web services to include third-party libraries and frameworks. Unfortunately, some of these added components could be used to compromise the security of systems using the added software. When this happen it falls under this OWASP category, independently of what kind of component is vulnerable.

This kind of threat occurs when the components such as libraries and frameworks used within the app almost always execute with full privileges. If a vulnerable component is exploited, it makes the hacker’s job easier to cause a serious data loss or server takeover.

The component with a known vulnerability could be the operating system itself, the CMS used, the web server, some plugin installed or even a library used by one of these plugins.

How to determine if you are vulnerable

To determine whether your application is vulnerable it is important to keep abreast of the security status of the components that it uses. Vulnerabilities are reported to central clearing houses such as CVE and NVD. Attackers are able to identify a weak component through scanning or manual analysis of a web application. Therefore, it is important that your firm regularly scan their web applications for vulnerabilities.

10. Insufficient Logging & Monitoring

The time to detect a breach is frequently measured in weeks or months. Insufficient logging and ineffective integration with security incident response systems allow attackers to pivot to other systems and maintain persistent threats.

How to determine if you are vulnerable

A Penetration-Test and its corresponding log generation will help your firm better understand any possible signals they missed due to the vulnerability exploitation. This is a very important step in understand the system requirements for a logging and monitoring software package