Last week we introduced the CWE Top 25 Most Dangerous Programming Errors in Part 1 of a 4 part series. This week we will discuss the first nine, which have been categorized in a group called “Insecure Interaction Between Components”. Being the first nine, they are also the top 9, or the top most prevalent errors on the list.
As mentioned last week, we will discuss these errors within the confines of web-based applications. Being the top 9, you may think these errors will be more complication and harder to defend against than errors further down the list. In fact, the opposite is true. These top 9 are the most prevalent, sure – but they are also the easiest to defend against. As you go through this break-down, pay close attention to the first 2 errors covered, as there will be a recurring theme in the remainder of this discussion.
Insecure Interaction Between Components
These weaknesses are related to insecure ways in which data is passed between separate components within web applications, to include the user’s browser (the client component).
#1 CWE-20: Improper Input Validation
Input validation is the practice of sanitizing (validating) data before passing that data on to another component within a web application’s framework. The most basic example of this is form-field validation used on many web-based forms. For example, leaving a Required Field empty, then clicking on the form’s submit button will often result in a pop-up message or other similar error indicating that the field is required and must be filled in before proceeding.
The problem with the above example is that many times Javascript is used to perform this function, with no server-side equivalent to ensure that the data wasn’t tampered with prior to reaching the web server. This type of manipulation of data is possible because HTML, Javascript and others are processed within the user’s browser (rather than the server) and can be manipulated by the user as they see fit. Simply put, client-side validation cannot be trusted, since it cannot be controlled. Applications relying on client-side validation alone are at great risk to being hacked, defaced or otherwise harmed.
Proper input validation is critical for web applications to operate as designed and -as such- is not correctable with a magic PHP, Java, or ASP function. Input validation requires that the developers of the application put every effort into checking externally-supplied data at each step in it’s processing. This is often done using pre-built Regular Expression Patterns to ensure that the supplied data is the correct type, length and format.
Example:
Let’s assume that we have a form that requires the user to enter their 5-digit zip code. We would use a similar PHP function to ensure that the supplied data is an integer with a length of 5 as such:
preg_match("/^[0-9]{5}$/", $form_zipcode)
where $form_zipcode is the form-variable.
Similar code exists for ASP, Java and others, but you can see that depending on the data your applications expects from the user, this can become very unique to your specific needs, although most foreseeable patterns have already been written into code snippets that you can use within your organization. More information and examples can be found here.
#2 CWE-116: Improper Encoding or Escaping of Output
The terms “Output Encoding” and “Output Escaping” are often interchanged, and can be misleading. For the purpose of this discussion, we will refer to this error as Output Escaping.
Output escaping is the practice of sanitizing data for use by other components. This could be data displayed in the user’s browser or passed to a SQL Query, for example. The root of this problem lies in the way in which computers process data. Much of the data processed by web applications is in “human-readable” form. This human readable data could be in any number of different languages, and contain special characters, which could have special meaning to HTML or SQL. Output escaping is the process of converting this data into a standard format used by the receiving process, so that data is always processed as intended.
The easiest example would be with HTML and the greater than and less than brackets, or “>” and “<” respectively. These characters are protected HTML characters used in the processing of HTML data, so allowing these characters to be displayed as such by the user's browser would effectively break the HTML code written by the developer of the site. Escaping of this data is performed by converting these characters to their equivalent 'HTML Entity'.
There are 5 specific characters that must always be converted to their equivalent entity. These are the greater than and less than symbols, the ampersand, the single quote and the double quote. The equivalent HTML entities are as follows:
>
<
&
"
'
You can see very easily from the above example why the ampersand has special meaning in HTML, but the above 5 are the most crucial. There are many other characters that also have equivalent HTML entities and best practices suggest that all data be “escaped” properly.
Lack of output escaping is the largest contributor to Cross-site scripting attacks.
Example:
Let's assume that we have a form field that allows a user to enter any data they wish – for example, in a blog-submission form, which may require the user to use the above special characters. Output escaping would dictate that we sanitize or convert this data into HTML equivalents, as demonstrated below in this PHP example.
$cleandata = htmlentities($data, ENT_QUOTES, UTF-8);
The above example takes the variable called $data and performs an embedded function called “htmlentities” to escape all applicable characters into their HTML entity equivalents, specifically in the UTF-8 character set.
#3 CWE-89: Failure to Preserve SQL Query Structure (SQL Injection)
SQL Injection is the act of tricking a web application into executing add-on commands to an intended SQL Query. There are many methods of performing SQL Injection (and we wont go into them here), but the basic types are Blind and Error-based SQL Injection.
A common thread we'll see with these errors from here on out is that the individual errors are typically not capable of being manipulated by themselves, and almost always come back to lack of Input Validation and lack of Output Escaping.
Example:
Let's assume that we have a form field that allows a user to search for records in a database by entering a search term, such as their userid (in the case of login forms).
A typical SQL query on the backend would look something like:
'SELECT * from Users where username = $user';
If the user enters (for example) mike' or 1=1, the above SQL query would return all records in the database (because 1=1 is always true). Its obvious from this example (if successful) that the application failed to do 2 critical things: Input Validation and Output Escaping. If the web application had checked to make sure that special characters were not part of the username, this attack would not be allowed as the data would not pass validation, hence not be passed to the SQL query.
Well what happens in the instance where the user's name contains a valid special character (O'Reilly for example). This is where output escaping would be critical to ensure that the single quote was escaped in a fashion understood by the target database.
#4 CWE-79: Failure to Preserve Web Page Structure (Cross-Site Scripting)
Cross-Site Scripting's name doesn't do it justice. Cross Site Scripting (or XSS) is an attack whereby special HTML characters are input by the user (attacker) to manipulate the processing of the HTML code itself.
As we discussed in #2, the special characters “<” and “>” are used by HTML and Javascript to process code blocks. If a user is able to enter anything they wish, and that data is processed and echoed back to the user, they can essentially re-write the entire code to do whatever they wish.
Example:
Let's assume that we have a form field that allows a user to enter text, such as a blog submission form. If the user enters <script>alert('you have been hacked')</script> and the application is not escaping the output, then this data will be processed by the user's browser as HTML code (as opposed to displaying text) and a Javascript pop-up box with the message “you have been hacked” would pop-up in anyone's browser reading the blog entry.
However, if output escaping is properly performed the above text will be converted to the following:
<script>alert('you have been hacked')</script>
The above text would simply display the HTML characters in the user's browser, as opposed to being executed by the browser.
Although the above example is overly simplified, the same principle is exploited to perform very complicated XSS attacks including credential theft and worse.
#5 CWE-78: Failure to Preserve OS Command Structure (Command Injection)
Command Injection follows closely with SQL Injection, rather than executing “add-on” SQL Queries, the attacker executes “add-on” system commands.
Of course, calling system applications from within your web application's code is not generally recommended, but there are many instances where the application is required to make calls to external applications upon processing user-supplied data.
If the application fails to perform proper Input Validation and Output Escaping....hopefully you get he picture :)
#6 CWE-319: Cleartext Transmission of Sensitive Information
This one sounds like it should be a “no-brainer” but believe me when I say that this is the single most common error that I continue to see with public web applications. This doesn't always mean that a site doesn't have an SSL-secured version running on TCP port 443, rather than standard HTTP running on TCP port 80.
Very often, an organization will install an SSL certificate and bring online the “secure” version of their application, but will leave the unsecured version still running. All the user needs to do is change the “https://” to “http://” in their browser to bypass this one.
Even more common, is that by default Apache, IIS and other web applications allow the use of insecure SSL ciphers such as SSLv2, or allow the user's browser to negotiate which encryption protocol and cipher it wants to use. This is a “no-no”, but shame on the vendors for making the default operation insecure, and force the system administrator to jump through hoops. (The good news is that it's relatively easy to fix). The general rule of thumb is only allow SSLv3 or TLSv1 on your SSL-enabled web applications.
The issue of insecure communications doesn't just apply to the interaction between the web application and the user, but also between the web application and the database server, or the web services engine. Any communication of sensitive data should be via an encrypted data stream only, unless you want to be the next “Heartland” press release.
If you would like specifics on how to configure your web servers to only allow cryptographically sound algorithms, shoot me an email and I'll forward you the appropriate information.
#7 CWE-352: Cross-Site Request Forgery (CSRF)
CSRF is a relatively “new” concept in the press, although it's a very basic exploit of bad programming. CSRF is the exploitation of URLs within an application that accept that an authenticated user is a valid user, and allows the automatic processing of commands based on this assumption of trust.
For example, let's say we have a URL on our site that allows a user to change their password:
http://example.site.com/cgi-bin/chPass.cgi?username=mike&newpass=vulnerable
The above example assumed that user “mike” is the user calling this script and performs the password change. Well, using other attack methods, such as XSS, an attacker could trick user “mike” into clicking on a link or viewing a page with an embedded image that calls this script. If user “mike” still has a valid session on example.site.com, the attacker would have just tricked Mike into changing his password to a value set by the attacker.
This may seem like an overly simple example, but Google just recently fixed a similar Password Changing CSRF vulnerability that was published quite some time ago (their vulnerability required that the attacker know the current password to change it to a new value) but a valid flaw nonetheless.
The basic protection strategy is to utilize POST form data, rather than URLs (GET) to perform actions like this. Additionally, adding a measure of human interaction to ensure that the request is indeed coming from the valid user, rather than a malicious script.
#8 CWE-362: Race Condition
A Race Condition is a situation where an application fails to properly maintain state data between various components, which can lead to the application getting “confused” and potentially allowing data from one state to be accessed by another.
A basic example is that of a single-threaded e-Commerce checkout application where one-user's cart accidentally gets pushed into another user's session because of timing issues.
Although commonly exploited Race Conditions are far more complicated than this basic example, they do occur quite frequently, often resulting in data leakage or a denial of service to the web application itself. I wont belabor the point here, but if you would like more information on this error, shoot me an email and I can get you some more pertinent information.
#9 CWE-209: Error Message Information Leak
Another “no-brainer” information leakage via error messages is a very useful way for an attacker to mount injection attacks against your application. By default, web servers, such as IIS, Apache and Tomcat show “error pages” that reveal way too much information to a would-be attacker.
For example, IIS by default shows the version of the ASP.NET framework being used, and if remote_errors are enabled, much much more. Apache and Tomcat have similar problems out of the box, and should never be put into production until custom, generic error messages are configured to handle exceptions in the execution of your web applications.
As with other “no-brainers” this one is really easy to fix and shame on the vendors for using the verbose messages by default. What user cares if you're running ASP.NET 1.5, unless they are getting ready to hack you?
Some Free Web App Security Testing Tools & Resources
