Insecure Direct Object Reference

Number 4 on OWASP's Top 10 is Insecure Direct Object Reference.

What does this mean?
References to items like files, directories, database records, and keys are sometimes included in URL or form parameters. This is bad practice since a hacker could easily change the parameters, gaining access to files or directories that they should not be able to access. If a reference must be included as a URL parameter, a check should be in place to ensure that the user is actually allowed to view the content.

Who is vulnerable?
Any web application is potentially vulnerable.

How can it be prevented?
OWASP provides some good points on their site:

• Avoid exposing your private object references to users whenever possible, such as primary keys or filenames.
• Validate any private object references extensively with an "accept known good" approach.
• Verify authorization to all referenced objects

Follow the link below for more information.

References:

• OWASP Top 10: Insecure Direct Object Reference
  

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

Malicious File Execution

Malicious file execution ranks at #3 on OWASP's top 10 list.

What is Malicious File Execution?
Malicious file execution is a server-side web application vulnerability. It occurs when hostile input is processed by the server. This input may include file stream functions or external object references, which can lead to remote code execution and even complete system compromise.

Who is vulnerable?
Any web application that takes user input is potentially vulnerable. This hack is most prevalent in PHP when SMB file wrappers are used.

How can I prevent it?
The best way to prevent this attack is through proper input validation (as usual). It is also good practice to NEVER use user-supplied input as any part of a file name for a server resource. Also be sure that the server is behind a firewall.

Resources

• OWASP - Malicious File Execution

Clickjacking

Clickjacking is a client vulnerability that malicious websites can exploit.

What is Clickjacking?
Clickjacking occurs when a person visits a web page and clicks on something that they believe is part of the website they are visiting, while in reality they are actually clicking on a different web page that they cannot see. This is done by loading a web page over another one using an iframe, but the top page is made completely invisible. Buttons on the bottom page are strategically placed so that they coincide with actions on the invisible page. Clickjacking has been used to delete all contacts in a user's web mail address book, make a myspace profile completely public, as well as many other things. Click the following link to see an example of clickjacking. Clickjacking Example

How Can I Prevent It?
To my knowledge, there is no native prevention built into any web browsers. However, you can download a plugin for FireFox called NoScript. I currently use it, and it will warn you when you click on something that you cannot see. Also, clickjacking usually needs a user to be logged into a website in order to be vulnerable. It is a good practice to click "log out" when you are finished using a website, and doing that would prevent many of these clickjacking exploits from harming you. Web applications

Resources

• Wikipedia - Clickjacking
• ZDNet Security Blog