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

Cross Site Scripting (XSS)

Another highly exploited web application vulnerability is Cross Site Scripting, or XSS. This weakness is ranked at number 1 on OWASP's Top 10.

What is Cross Site Scripting?
XSS is a type of injection hack - HTML injection to be exact. It occurs when malicious JavaScript is submitted to a web application at point that will allow it to be reprinted on a page. The JavaScript becomes embedded in a page created by the web app and subsequently runs in a user's browswer. Since the script has access to any cookies created by the web app since the script actually came from a page generated by the app. This means that cookie information (like session data) could be sent to the hacker, allowing them to act as you in the application effectively stealing your identity. If an ecommerce site like ebay or Amazon.com was vulnerable to this kind of attack (note - there is no known current vulnerability), an attacker could potentially order merchandise using your credit card and ship it to themselves.

Who is vulnerable?
Any web application that takes user input and re-displays it is potentially vulnerable.

How Can These Attacks be Prevented?
As with SQL injection, the best way to prevent this hack is to validate all user input. If validation is done on the client side, it must also be done on the server side since it is easy to bypass anything that is completed client side. It is also good to run output through functions like htmlentities() or htmlspecialchars() in PHP. Java is a little more difficult. OWASP suggests that you use a struts output mechanism like , but it is definitely not safe to use <%= %> outside of a properly encoded output mechanism. See the resources below for more ways to protect your application.

Resources

• Security Now episodes 85 and 86
• CWE/SANS Top 25
• XSS - OWASP
  

SQL Injection

Injection flaws are ranked at number 2 on OWASP's Top 10 2007 list for the most common web application vulnerabilities, and SQL injection is the most commonly exploited injection flaw.

What is SQL Injection?
SQL injection is a type of hack that can be performed when a web application accepts input from a user (such as a user name or password). Instead of typing valid data, the hacker will use characters that are part of the SQL syntax. This way, the hacker can construct his or her own database query, and maybe gain more information about the database that can be used for more harmful attacks. Sometimes it is even possible to log into a system using SQL injection. I found a video example of this on YouTube, and you can view it below.

Video Example


Who is Vulnerable?
Any web application that uses user input as part of a database query is susceptible to a SQL injection hack.

How Can These Attacks be Prevented?
Although SQL injection vulnerabilities are still relatively common , it is easy to fix them. The first rule of thumb is to ALWAYS validate user input on the server side. As the above video demonstrates, client side JavaScript data validation is not enough because users can get around it if they really want to. Second, a query containing user input should never be executed without first being prepared in some way. In Java, this means using a PreparedStatement object. If the web application is written in PHP with a MySQL database, use the mysql_real_escape_string() function. Last, the web server needs to be configured so that error pages do not reveal information about the inner workings of the web application (i.e. table names, row names). Hackers would love to get their hands on this type of information.

Resources

• OWASP - Injection Flaws
• Examples of SQL injection attacks
• More examples
• Security Now Episode 87 - SQL Injection
  

MD5

As long as we're still on the subject of cryptography, I thought I would go into a little more detail on what MD5 is and how it can be used.

First it is important to understand what a hash is. A hash is a sort of fingerprint for computer data, and it is composed of a predetermined number of alphanumeric characters. You can determine a hash for any type of data (i.e. text, files like Word documents, images, etc.). A hash could look like this: 5eb63bbbe01eeed093cb22bb8f5acdc3

So how do you find a hash? You have to run a mathematical algorithm on the data from which you would like a hash to be determined. When the algorithm is run, the data are processed with many different mathematical operations that are extremely difficult to undo, and a hash value is created. An algorithm will always produce a hash of the same size every time, no matter how much or how little data are used as input. Different algorithms produce different sized hashes. The example below demonstrates the hash values for two commonly used algorithms. It shows the hash value that was calculated when "Hello world" was the input and when "Hello world!" was the input.

MD5
Hello world: 3e25960a79dbc69b674cd4ec67a72c62
Hello world!: 86fb269d190d2c85f6e0468ceca42a20

SHA-1
Hello world: 7b502c3a1f48c8609ae212cdfb639dee39673f5e
Hello world!: d3486ae9136e7856bc42212385ea797094475802

As you can see from the example, just adding "!" to the end of the input completely changed the hash values. This is important, because we want the hashes to be unpredictable. Also, the longer a hash is, the more secure it is.

So MD5 is an algorithm used to produce hash values. But how can it be used?

One use is to check file integrity after transfer. If you download a large file from the internet, there is a greater chance that some of the file did not transfer correctly, making the file corrupt. If the site you downloaded the file from provides an MD5 hash of the file, you could run the file through MD5 and see what hash value you get. If it matches the provided hash, your file is intact.

MD5 is also used for password storage. Instead of storing a user's password as plain text in a database, it is a better idea to hash it first. This way, anyone with access to the database cannot see all of the passwords. I actually implemented this last week on the Tutoring System. The database stores the hash values of passwords instead of the actual password. When a user logs into the system, the password they entered is hashed using MD5 and then the hash value is compared to the value in the database.

On a final note, I thought that it was important to mention that MD5 is not as strong as some other hashes. Newer applications requiring a high level of security should use an algorithm like SHA-256.

Resources:

• OWASP Top 10 2007 - A8
• Paj's Home - Cryptography- create hash values with JavaScript
• Wikipedia - MD5

Cryptography Overview

The main purpose of this entry is to provide an overview of securing a web application using encryption. Episode 181 of the Security Now podcast was a great resource, and it goes more into depth.

According to Steve Gibson, there are three main things we want in a secure connection between a client and a host over the internet:

1. Confidentiality of communication
2. Protection against message modification
3. Endpoint authentication

So what do all these mean?

Confidentiality of communication means that nobody who intercepts our network traffic will be able to figure out what we are doing. According to the 2007 OWASP Top 10 Web Application Vulnerabilities, insecure communications 9th most common vulnerability. This can be fixed through encryption (either symmetric or asymmetric). If encryption is not used, anyone intercepting the traffic could easily see and understand the information that is being sent between the client and host.

Protection against message modification means that there are safeguards against accepting a message that has been altered by a hacker. For example, a hacker could potentially intercept a message requesting a payment to be sent to Paypal. They could repeat this message causing multiple payments, or even alter it to be a different amount. Hashes are a good way to protect against this. They are a somewhat like a finger print, and if the message changes at all, the hash would change.

Endpoint authentications means that you know that you are communicating with the right server. This is achieved through certificates, which I blogged about previously.

SSL (Secure Socket Layer) is a common protocol that includes all of this. Using SSL is a quick way to secure many aspects of a web application.

Resources

• Security Now Episode 181
• OWASP - Insecure Communications
  

Certificates

Today I listened to episode 179 of the Security Now podcast. Here's a brief summary:

The main theme was certificates, which are used to encrypt information sent over the internet. For example, banks use certificates to encrypt the data sent to and from your computer when you are performing online banking functions. These certificates are issued to organizations by certification authorities, or CAs, and they can always be traced back to a root CA (like VeriSign). Through a complicated process, some people were able to create a counterfeit certificate that could be traced back to a root CA. This means that their certificate would be trusted by all browsers, plus they could issue new certificates that would be trusted. Now this process was not easy to complete, but it shows that certificates are not completely secure.

So how can I apply this to a web application? Well it is still smart to use certificates to send passwords and other sensitive information over the internet, but there is nothing that I can do to prevent others from creating conterfeit certificates. The web would have to discontinue use of MD5 encoded certificates (which was the encryption that was used on the "cracked" certificate) and use something even more secure.

Semester Plan

(Initial Draft)

• Stay up to date with current security issues and solutions through online sources (like OWASP and TWiT's "Security Now" podcast).
• Explore the most commonly exploited security risks in depth, and learn how to protect a system from them.
• Apply the security solutions to the MIS Tutoring System web application.
  
• Create a list of security "best practices" and update it throughout the semester.
• Prepare some of the information gathered for use in Dr. Piercy's courses.

Dr. Piercy - Let me know your thoughts!

The Beginning

Since this is my first post, I'll give you a little background on me and the purpose of this blog.

My name is Jacob Prosser, and I am currently a 4th year Senior in my final semester at the University of Georgia. I am pursuing a B.B.A. through the Terry College of Business, and my major is Management Information Systems. In August, I will begin a full-time job at PricewaterhouseCoopers as an IT consultant.

This blog is part of my MIST 5990 directed study course with Dr. Craig Piercy. I plan on studying web application security, and my posts to this blog will reflect what I have learned.