5 Major Web App Vulnerabilities

An article was recently posted on ZDNet.com highlighting vulnerabilities in 5 commonly used web applications. Here is a summary of the issues.

Apache Geronimo Application Server
Currently, hackers can obtain sensitive information through several vulnerabilities. These include:

• Directory Transversal - Hackers can potentially upload any file they desire into any directory on the server. The issue was fixed in version 2.1.4.
• Cross-site Scripting (XSS) - Hackers can inject script into the URL. See my post on XSS for more information. The issue was fixed in version 2.1.4.
• Cross-site Request Forgery - An attacker could potentially perform administrative functions through this vulnerability. It has also been fixed in version 2.1.4.

SAP cFolders
There are several XSS and HTML injection vulnerabilities. The exist because user supplied data is not properly validated by the application. These problems could allow a hacker to perform administrative tasks since a hacker could easily steal the administrative cookie from a user. These issues have been solved by SAP in newer versions of the software. Information on the vulnerable versions is not available.

CS Whois Lookup
This application has a vulnerability that allows remote command execution. Once again, this stems from a failure to properly sanitize user supplied data. The only tool a hacker needs to exploit this issue is a web browser. Right now, there are no patches available.

phpMyAdmin
phpMyAdmin is a widely used database front-end written in php. In versions before 3.1.3.2, a hacker can inject and remotely execute malicious code on the web server. Newer versions of the software have corrected this flaw.

Novell Teaming
Several attacks are possible through user-enumeration and XSS vulnerabilities. A hacker could steal cookie-based authentication information from a user. The user must click on a malicious URI for this to happen. Version 1.0.3 is vulnerable and possibly others as well.

Most of these issues can be avoided by properly validating any input data on the server-side. JavaScript validation is never enough - hackers can easily get around JavaScript controls. Also, it is very important to keep software up to date. Always install the newest patches and versions since security issues are often resolved through them.

Resources

• Five 'must-secure' Web app vulnerabilities
  

Information Leakage and Improper Error Handling

Number 6 on OWASP's Top 10 is "Information Leakage and Improper Error Handling".

What does this mean?
Information leakage happens when a web application reveals information that should be protected. This can consist of data over the application's internal workings, configuration, or users, which can lead to privacy issues. If a hacker finds information about how a web application works, it is much easier for them to attack it.

Improper error handling occurs when unnecessary information is revealed to a user during an error. Error handling refers to a web application's programmed response to an error (i.e. incorrect username or password, no results in a search, file not found, etc.). Error pages often contain debugging information so that the programmer can better understand the problem, but this also means that a hacker could gain a better understanding of the application.

Who is vulnerable?
Any web application is potentially vulnerable.

How can it be prevented?
The first step to protecting a web application against this threat is through proper error handling practices. Errors should never reveal stack traces, SQL statements, or any configuration information. It is also bad practice to have different errors display for a single function. For example, an error page displays when a username that is not in the database is entered, but a different error page displays when an incorrect password is entered. Next, a standard error handling architecture should be implemented. Tools are available to test against this type of threat, including OWASP's WebScarab. More tips on securing against this threat are availalbe on OWASP's web site.

Resources

• OWASP's Top 10 - Information Leakage and Improper Error Handling
  

Insecure Communications

I touched on this topic in my "Cryptography Overview" post, but I thought that I should go into more detail since "insecure communications" ranks at number 9 on OWASP's top 10.

What does "Insecure Communications" mean?
In order for a web application to work properly, messages must often be sent between the application server and the client (user). It is also very common for messages to be sent between the application sever and other servers. When the data in these messages are sensitive (user names, passwords, social security numbers, credit card numbers, etc.), the method of communication must be secured. If it is not secured, a third party could easily "listen in" on the communications and extract the sensitive data from them.

Who is vulnerable?
Any web application that transmits sensitive data is at risk.

How can it be prevented?
The most common method of securing communications is though the use of SSL (Secure Socket Layers). This transmission method creates an encrypted connection between two parties. The data are encrypted on one end, sent, and decrypted on the other end. Anyone who "listens in" on the communications will find the encrypted data meaningless.

SSL should be used whenever sensitive data are being transmitted. For example, user login pages need to use SSL to prevent a username and password from being intercepted. Also, it is very important for ecommerce websites to use SSL when a person's name, address, and credit card number are collected. The Payment Card Industry Security Standards Council requires that SSL or an equivalent are used for any transmission of credit card information. You can check that SSL is being used on a website by checking the URL at the top of your browser. If it starts with "https://", then your connection is secured with SSL.

It is important to recognize that even the web applications that implement SSL are still at risk. Hackers can abuse applications that can be forced out of SSL or that fall back on insecure communications when a secure connection cannot be established.

Resources

• OWASP - Insecure Communications
  

Failure to Restrict URL Access

Number 10 on OWASP's Top 10 is "Failure to Restrict URL Access".

What does "failure to restrict URL access" mean?
Access to pages with administrator functions or private data is often not properly restricted. For example, it is commonly found that the only protection of these restricted pages is that a link to them is not provided to unauthorized users. However, if an unauthorized user knows or guesses the URL, then they will have full access to the page, giving them the ability to harm the system or view confidential data. Attacks on this vulnerability are usually called "forced browsing", where an attacker guesses links and uses brute force methods to find unprotected pages. According to OWASP, some of the most common flaws in web applications that allow these attacks include:

1. "Hidden" or "special" URLs that are only displayed for users with the proper privlidges, but they can be accessed by any users if they know the pages exists.
2. Access is often left open to "hidden" files, like static XML or system generated reports, in hope that security through obscurity will hide them.
3. Code that enforces an access control policy, but it is out of date or insufficient.
4. Code that determines privileges on the client side rather the server side (JavaScript).

An example of #4 being exploited can be found here: MacWorld 2007 Attack

Who is vulnerable?
Any web application is potentially vulnerable.

How can it be prevented?
Access control should be enforced on every web page. It is wrong to check a user's authorization once during the process but not on subsequent steps. This is because a hacker could just skip the step with the check. Also, you should never assume that users will not be aware of hidden URLs or APIs. Last, access should be blocked for file types that the system should never serve (i.e. pdf, php, html).

For more info, check the OWASP page on this topic.

Resources

• OWASP - Failure to Restrict URL Access