Recently, I was approached by a client who wanted to know more information on how they could map out vulnerabilities within their applications as the applications were built along side the yearly review we provide for them. My initial thoughts gravitated to talking more about a more robust SDLC (Software Development Life Cylce) process as well as providing information to the client on how to identify basic flaws within their web application and externally facing infrastructure. 

 

 

In this blog post I hope to present some basic information behind the v00d00 magic of web application testing (or application testing in general) to an audience which most likely consists of quality assurance professionals, internal audit, or even managers who may want more information on how they themselves could build in a very generic testing process to identify very generic vulnerabilities within their web applications. Most of the work which lies before you really hinges upon a few basic pieces of information coupled with a mix of out of the box thinking and practice. 

 

 

What we will cover follows:

 

Just like putting your game face on, or putting on war paint for a crazy adventure you will want to really put yourself into the mindset of a hunter looking for its prey. Along your hunt you will need the courage and perseverance to hunt your prey. The prey, Implementation bugs (input validation specifically) within your companies web application.

Before beginning on your journey remember every part of the application is at your disposal and you want to think about how you can use it for your intended purposes not entirely the intended purposes set forth by the developers.  You will baseline normal activity in preparation for discovering abnormal activity (exceptions). 

 

Remember the webserver is really just a glorified file server, which acts as a presentation 

to the end user *(you, your browser etc). 

Web applications process input from the client in two common forms.

Those forms are known as HTTP GET and POST operations. 

 

A GET request basically asks the webserver to retrieve certain information from the webserver, while a POST operation pushes information into a web application. Information within a webpage (application) can be dynamically rendered based on information within a GET or a POST request.

A GET request might look like the following:

Traditionally information is requested through your web browser to the server. (You won't see the actual GET portion), but within your web browser you will see http://www.yoursite.com/MyCalendarapplication/AddMeeting.asp?day=1&time=noon

Based on the information passed to this portion of the application certain events can transpire on the application based on information passed to variables. 

Eg: /AddMeeting.asp?day=1&time=noon

AddMeeting.asp = the server side script. 

day=1&time=noon are variables in which the server side application respond to depending on what information is passed. (Variables signified by the & character) 

 

The same is true for POST operations, when variables are passed within a POST request to an application (*Note POST requests usually occur when submitting forms etc)

variables will hold information sent back to the application.

 

Your initial goal should be to walk through your application to identify the static content (eg html, css, jpg's) versus the dynamic application like content. (Eg. Php,asp,aspx,cgi )

Your secondary goal will be to map out all the information which is passed to the application, and in which manner (whether it is through a GET or a POST method.)

 

Application information is generally held within a database, in which the application is talking with. By manipulating the input and or output you can discover vulnerabilities which affect the end user's browser security as well as information which is passed to the backend database. 

 

Once you have mapped out the application, server side script, or form from the static content (html), you will want to start pushing in information into each variable seeing what type of input validation is being performed on the application and how the server responds to this input. 

In your scenario , I will assume that you are doing this on a non-production box, so lets assume that verbose error messages are enabled. In this case any bad information you give to the application should present you with an error as to why you triggered an exception. 

 

Placing bad characters in variables is useful in triggering bugs. 

 

By placing characters and words like:

 

By passing this type of information a user can trigger bugs within the application , thus aiding in discovering generic bugs and or security problems within the application. When verbose error messages are encountered please see if the error messages are Application errors or Database errors. Regardless of what type of errors are being thrown this is where you want to question your developers on the type of input and output validation that is being performed.

 

But how and why? Why would the input above cause exceptions and how would I pass or append these characters into the web application?

 

The how is pretty simple. Since your webapplication is passing arguments which interact with a backend database you can influence how queries are performed on the backend database, thus influencing how information is presented back to the end user or what information gets requested on the database. 

 

Now for the how can I do this....

By passing extra information to the form mentioned above:

/AddMeeting.asp?day=@@version&time=';SELECT user -- 

 

 

The above request is basically saying:

To the day variable pass the global variable within the backend database @@version, by working on the assumption that at the end of the select statement on the database query will give you information held within a global variable. 

 

The second variable &time, says ' (add in more sql), end our current query by placing a ';' character, followed by asking the database to perform another query, followed by ending that query. 

If you don't get exceptions don't worry, but you could find some interesting things. 

 

If you have found some exceptions you may want to know more about the exploitability of those bugs. 

Taking your testing a bit further the questions you want to start asking yourself include:

1) Where am I landing in a SQL query on the backend database given the ODBC/Database error I am getting?

2) What could I get to render within the browser, can I put any other HTML entities (HTML Characters) within the input placed into the application which may be 

  rendered back to the end user or application administrator?

 

 

 

Moving away from the basics to a deeper understanding you may want to read the following links and start reading some of the following books. 

Hopefully you are now armed with some basic information on how to identify basic vulnerabilities within your web application as well as places you can search for more information on web application security while gaining more peace of mind. While only basic information has been shared in this article we hope this can spur on a desire to search a deeper understanding of web application bugs and input validation within applications in general. Within the next article I will outline vulnerability classes and proxies as well as more technical error messages detailing bug identification and vulnerability validation. 

 

Thanks,

Daniel Clemens