Topic: Web Application Security Testing - Part 3

Web Application Security Testing - Part 3
I hope that you have already read first two parts of this article and familiar with the concept of how web applications are different from traditional client-server applications and what kind of information can be collected from the client. If you have not, you might find it useful to read Part-1 and Part-2 as well.

In this part we will explore how user supplied data can attack your application. We will explore information related to SQL injection, Cross Site Scripting, Directory Traversing etc.

 
Cross-site Scripting ( XSS ) is a mechanism of presenting user with a fraudulent web site content.  Web sites often echo the input data that is entered as some other places with in the application, for example users postings in forums. Sometime postings in forum can also include HTML as well. This HTML, along with the formatting information can also contain client side scripting, which can be dangerous since it will have access to the content of current page. Client side scripting can even steal user's cookies. This type of cross site scripting can be used in places where user write something which is available to all the users. For example, book reviews, blog comments and so on. Another mechanism of using cross site scripting is called reflected cross-site scripting. In this technique, attacker can embed the script into CGI parameter of a URL. When user clicks on the link, real page is loaded and its content changed by the script that is embedded in the URL.

Cross-site scripting attack is best suited for situations when user supplied input data is echoed back the other users. Mostly, this attack exploits the facility of providing user input in HTML format and insert malicious scripts with in ... tags. Apart from direct SCRIPT tag, tags like HTML, BODY, EMBED, FRAME, FRAMESET, IMG, LAYER, META etc. are also known to have this vulnerability. In fact, any tag which support attributes like STYLE, SRC, HREF etc.  are known to be vulnerable.

The best way to protect against this attack is to filter the contents of user supplied data. It should be noted that while filtering, white-lists approach (Allow only trusted code) should be used instead of black-lists approach (Block code with specific tags and allow rest), since it will not cover new vulnerabilities.

SQL Injection is probably one of the well known vulnerabilities in web applications. In this vulnerability, SQL queries can be injected in the form of user input data which can results in number of insecure behavior. For example, on a login page if your application is not protected against SQL injection, you can use it to get all the user names and passwords stored in the database. This technique is mostly used in situations where SQL query is dynamically generated using the data or parameters supplied by user. This vulnerability can be extremely dangerous since SQL is often used for authentication, authorization, billing etc.

Any user input, which becomes part of a SQL query is subject to a possible SQL injection vulnerability. This attack require sound knowledge of database schema for your application and how queries are constructed. Because of the nature of attack and possibility of major threats associated with the attack this is one attack, you should always check in your application. Consider following example to appreciate how serious SQL injection attacks can be -

Suppose your application takes username and password and construct query like this

Select * from Account where username = 'username' and password = 'password' ;

In this query, username and password are passed as parameter and will be replaced in the query. If you pass normal information it should work fine. But how will your query look if you give your username as testuser'--

Select * from Account where username = 'testuser'--' and password = 'password' ;

 Now if you look closely, '--' is SQL comment operator, and effectively it has converted this query into this

Select * from Account where username = 'testuser'

You can understand effect of this query now. You can think of even more serious usage, for example getting list of all the users along with password may be? Yes it is also possible if your application is not tested against this vulnerability.

Similar to most of the attacks, the best way to protect against this attack is proper filtering of parameters at the server side.

Another popular attack in web application is Directory Traversal, in its simplest form, malicious user determines the location of restricted files and views or execute them. Problems associated with this could be ranging from breach of privacy to controlling or modifying the site content. In its simplest form attacker can just guess the file names, directory name and get those files which are residing on the server, but not public as of now.

Directory traversing can also reveal sensitive information if your application and server is not protected properly. Consider this URL -

http://www.somedummyURL.com/getinfo.asp?item=getinfo.asp

This URL is requesting itself, in cases like this web server will display source code of getinfo.asp and that can give considerable information to attacker including database connection strings, password, business logic etc. This attack can be dealt in two ways. To restrict web application to serve pages from only web root directory / subdirectories and by using Access Control Lists.

Hope this information was useful to you and can be used to do security testing for your web application. In the next article, we will explore language specific attacks and different mechanism of attacking servers.