How to Test for Injection Vulnerabilities

Injection Vulnerabilities

An injection attack typically occurs when input has not been validated. Injection attacks will provide some form of input and attach additional malicious data to perform some other or additional input or command. Injection attacks use an input medium to do something that the developer of the feature did not and would not normally expect. As you can see there seems to be a common form to all these types of vulnerabilites, input validation. Input validation is the number 1 security vulnerability in most applications. If input was validated a huge portion of security vulnerabilities would be solved.

There are numerous types of injection attacks and vulnerabilities. Each injection attack has differing ways on how to test for the injection vulnerability.

• CRLF Injection
• LDAP Injection
• SQL Injection
• XSS Injection
• Javascript Injection

CRLF Injection

CRLF Injection is typically used in HTTP Response Splitting. In the HTTP specification there is a spec stating that the HTTP header is to be split from the data portion of the packet. This formatting split is defined by a carriage return and line feed, or called a \r\n.

Basically by injection a \r\n somewhere in the HTTP header you can split an HTTP packet into 2 different packets. 1 packet will have the malicious payload, while the other packet holds the valid information. HTTP Response Splitting is a vulnerability in the HTTP spec and as such a web server or proxy server will need to know how to handle and protect against these types of attacks and vulnerabilities.

HTTP Response Splitting can lead to the follow types of vulnerabilites.

• XSS or Cross Site Sripting vulnerabilites
• Proxy and web server cache poisoning
• Web site defacement
• Hijacking the client's session
• Client web browser poisoning

LDAP Injection

LDAP Injection attacks are not as common as the other types of injection attacks, but if your product uses an LDAP server this must be tested. An LDAP Injection could occur anywhere that the underlying code could use some type of input for any ldap searches, queries, or any other ldap function.

Example of what an LDAP injection attack could look like

Take for example, a page that has a search box to search for users in an application. This search box could ask for a username. The underlying code would take this search query information and generate the LDAP query that will be used to search the ldap database.

For example

<input type="text" size=20 name="name">Enter the name to search for</input>

Following the LDAP search query syntax, a developer attempts to narrow down the ldap query for performance. And the underlying code might perform something similar to the following

String ldapSearchQuery = "(cn=" + $username + ")";
System.out.println(ldapSearchQuery);

If the variable $username is not validated to be an accurate and valid possible username, an ldap injection could be possible. Take for example the following types of situations

• What if the user puts an * for the search. This will return every username in the ldap database
• What if the user puts in an joe)(|(password=*). This will create a ldap search query like (cn=joe)(|(password=*) ) Which would return the users joe password.

There are all sorts of other possibilities as to what could be used with ldap injection vulnerabilities. If you are testing a software application that uses an ldap server on the backend, you must become familiar with the ldap searching syntax and what the possible ldap searches you can perform with it.

SQL Injection

SQL Injection vulnerabilites are quite common and very dangerous. An SQL injection vulnerability can only occur with a software application that fronts a database. Which just happens to be a very common occurance. SQL Injection attacks deal with the same problem of input not being validated. With a bit of understanding of the web application and a sniffer trace, a malicious user could create an SQL statement that was not intended and "trick" the web application to return or perform some other SQL command rather than the intended command.

The first thing that will need to be done is to understand how the web application interfaces with the backend database. Either you will have the design documents to work with or you can use a sniffer utility to determine what is occuring.

See the Tools sniffer applications for more information on types of sniffer applications.

If a site is vulnerable to SQL injection a large number of other problems could occur. This is a simple and easy vulnerability to exploit. All an attacker needs to know is SQL and have some understanding about how the information is passed.

Example:

To understand how a SQL injection vulnerability could occur, imagine the following situation. For example say your website has a method to search for users. A usersearch page is created which could include something like the following.


<form method="post" action="searchuser.php">
<input type="text" name="username">
<input type="submit" value="Search" name="search">
</form>

This html snippet passes in the username to the dynamic page searchuser.php. The searchuser.php will take the username and add it to an SQL statement. Take for example the following php code snippet.


sqlResult = statement.executeQuery("SELECT * FROM users WHERE username = '" + $username + "';");

Think about this statement and see if you can figure out what is the problem. You might say the $username should be validated before it is added to the SQL statement. That is exactly what should be done. A malicious user could attach additional SQL statements to the username. This could be done by passing is something like.


admin' OR 1=1 --

Think about what the SQL statement would look like.


SELECT * FROM users WHERE username = 'admin' OR 1=1 --';

Notice this will either select the admin account or it will before 1=1 which will result in true. Which in SQL terms this will return the entire users table. Which the users table could contain all sorts of other additional sensitive information. This is just one example of what type of attack could be performed with SQL injection.

XSS Injection

Cross Site Scripting vulnerabilities are sometimes referred to XSS or CSS vulnerabilities. Typically XSS is preferred over the use of CSS. CSS typically refers to the Cascading Style Sheet commonly used in website design. XSS vulnerabilities are a dangerous type of attack. Especially since the sudden infusion of the Internet and all the many web applications that are on the Internet. Typically a website that uses dynamic content are the only websites that can have a Cross Site Scripting vulnerability, which is the majority of websites out there today. There are two types of XSS attacks. Reflected and stored.

What is a Reflected Cross Site Scripting vulnerability

The malicious user has discovered that a field within a website or web application holds a XSS vulnerability. This malicious user then crafts a way to use the vulnerability to execute something malicious to some unknown user. Reflected XSS vulnerabilities occur when a unknowing user is directed to a web application that has a XSS vulnerability, by the malicious user. Once the unknowing user gets to the web site or application the malicious user's attack is executed.

The attack is crafted by a series of url parameters that are sent via a url. The malicious user then sends his/her malicious url with the url parameters to unknowing users. This is typically sent by email, instant messages, blogs or forums, or any other possible methods.

You think that the unknowing user would not click on some link that looked like it does something bad. But the reflected attack can occur using javascript that once an email is opened or even the website is viewed the attack is executed. Additionally the attack is typically url encoded, hex coded, or some other encoding method to try and make the url appear as something valid.

What is a Stored Cross Site Scripting vulnerability

A Stored Cross Site Scripting vulnerability occurs when the malicious user can store some attack which will be called at a later time upon some other unknowing user. The attack is actually stored in some method to be later executed.

The storage of a method could involve a database, or a wiki, or blog. Basically the malicious user has stored some type of attack, that when an unknowing user will encounter this, the attack will be executed. The stored method actually not only has the problem of incorrect checking for input validation, but also for output validation. Even if data has been sanitized upon input, it should also be checked for in the output process. By checking and validated the output, you could also uncover unknown issues during the input validation process.

Stored Cross Site Scripting vulnerabilities typically are more dangerous than reflected. The reason being is that the reflected attack is a dynamic attack, while the stored attack can just be set once. That does not mean that you should only test for Stored Cross Site Scripting vulnerabilities. Both should be tested for and both should be fixed. XSS vulnerabilities and attacks are very common today and you don't want your software application to ship will one or more of these types of vulnerabilities.

There is another method that a Stored Cross Site Scripting vulnerability could be executed. If a database is shared with other applications, be warned, another application could stored a cross site scripting attack and your application could use the same content. If you have no ability to test or verify that the data stored by the other application is validated, then remember your application must validate the output of the message. If the application does not validate the output then even though you have validated your input, your application could still be vulnerable.

Remember to always check all methods that data could be stored and retrieved. Just because input is validated, does not mean that some other method or application could store malicious data which your application could recall.

How to test for XSS Injection vulnerabilities

You can determine if a web-based application is vulnerable to XSS attacks very easily. A simple easy test is to take a current parameter that is sent in the HTTP GET request and modify it. Take for example the following request in the browser address URL bar. This url will take a name parameter that you enter in a textbox and print something on the page. Like "Hello George, thank you for coming to my site"

http://www.yoursite.com/index.html?name=george
And modify it so that add an extra some additional information to the parameter. For example try entering something similar to the following request in the browser address URL bar.

http://www.yoursite.com/index.html?name=<script>alert('You just found a XSS vulnerability')</script>
If this pops up an alert message box stating "You just found a XSS vulnerability", then you know this parameter is vulnerable to XSS attacks. The parameter name is not being validating, it is allowing anything to be processed as a name, including a malicious script that is injected into the parameter passed in. Basically what is occurring is normally where the name George would be entered on the page the </script></script> message is instead being written to the dynamic page. The alert message just is an example of how to test for the XSS vulnerability. A malicious hacker would be much more devious to this type of security vulnerability.

There are many, many different methods to test for XSS vulnerabilities. This only describes a few of the different methods to test for a XSS vulnerability.   

http://ha.ckers.org/xss.html

Javascript Injection

JavaScript is a widely used technology within websites and web based applications. JavaScript can be used for all sorts of useful things and functions. But along with this comes some additional security issues that need to be thought of and tested for. JavaScript can be used not only for good purposes, but also for malicious purposes.

Using JavaScript an individual can modify and change existing information within a form. It can be used not only to change form input tags, but also the cookie's that are currently set in the browser, and any other value within a website or web application. Any type of parameter manipulation that you want to perform can typically be done with Javascript injection.

To execute any javascript within a current session, a user would enter the specific javascript commands within the browser's url bar minus the http://. All javascript commands must start with the javascript: tag followed by any javascript command that will be executed. All javascript is ended with a ; so a user could enter multiple javascript commands, as long as each command ended with the ;

JavaScript cookie modification

Using JavaScript a user can modify the current cookie settings. This can be performed with some basic JavaScript commands. To view the current contents of your current cookie/s, use the following JavaScript command. Put this in your browser's URL bar.

javascript:alert(document.cookie);

This command will popup a box which lists your current cookies. A malicious user could use javascript to change values in the cookie. For example lets say a web application you are testing sets an authorization cookie to true when a user has successfully logged in and passed the authorization test. To change the values within the cookie, a malicious user would execute javascript like the following from the url bar within the browser.

javascript:void(document.cookie="authorization=true");

This would cause the current cookie parameter authorization=false to be changed to authorization=true. Which the malicious user might not have passed the original authorization test. The malicious user has just bypassed the authorization test and gained access to the sensitive content. As you could imagine, this could cause severe problems in privilege escalation, if the malicious user could use JavaScript injection to bypass the correct authorization process.

If you are testing for JavaScript injection and wish to see if the cookie has been altered you would execute a command similar to the following, except you would want to replace the cookie name and value with the cookie you desire to test. Start with the javascript command to alter the cookie and then tack on the javascript alert function to view what the cookie was changed to. For example

javascript:void(document.cookie="authorization=true");javascript:alert(document.cookie);

You should now be able to see the new cookie parameter in the popup box.

JavaScript HTML Form modification

You can also use javascript to modify any value with an html form, including hidden forms, and disabled forms. The following is an example of how you would set an input tag named email within form number 0 (or the first form on the page)

javascript:void(document.forms[0].email.value="test@test.com");

You will need to view the source code of the html page to determine what needs to be changed and how to change it. Verify the form number and set the correct number. The first form is always 0. Next look for the html tag you wish to change. Finally add the new value you want the html tag to be. This will allow you to modify the information within the html form.

Injecting javascript into existing pages

Not only can you use javascript to manipulate parameters, cookies, but you can also inject javascript into dynamic pages to cause the page to render differently, do something else, or some other malicious thing. Think of a XSS attack.

Come back soon and we will post some examples of this.