Understanding Web Application Security

by Acidus  (acidus@msblabs.org)

Web applications are complex services running on remote systems that are accessed with only a browser.  They have multiple attack vectors and this article is by no means a comprehensive guide.  Today I will discuss what web applications are, how they work, discuss common attack methods, provide brief examples of specific attacks, and discuss how to properly secure a web application.

What do I mean by web application?

A web application is a collection of static and dynamically generated content to provide some service.  Maybe it's Wikipedia providing an ever-updating knowledge base or Amazon providing a commerce portal.  These application can span multiple domains, such as Wachovia's online banking system.

As you can see in Figure 1, web applications have multiple parts.  There is a program used to access the web application known as a user agent.  There is a JavaScript logic layer which allows very limited code to execute on the client's machine.  This is important because sending requests across the Internet cloud to the server is expensive in terms of time and lag.  There is a web server which has some kind of server logic layer.  This layer uses inputs from the client such as cookies or parameter values to dynamically generate a response.  Usually this response is composed of data stored in a back end database.  This database is maintained and populated by various programs like web crawlers and admin scripts.

Web applications are not a passing fad.

Major companies like Amazon, eBay, Google, Saleforce.com, and UPS all use complex web applications with several deriving all their income from them.  Many more companies are developing web apps strictly for internal use.  The cost benefits of having an application that is centrally managed and can be accessed by any browser regardless of the underline OS are simply too great to ignore.  With their place in the online landscape assured it is essential for hacker and security professional alike to understand fundamental security risks of a web application

As you can see web applications differ from traditional applications in that they exist on numerous tiers and span multiple disciplines.  Programmers, internal web designers, graphic artists, database admins, and IT admins are all involved.  It's easy for things to slip through the cracks because people assume a task is someone else's responsibility.  This confusion gap is ripe for vulnerabilities.

Figure 1

Attacking web applications is a lot like being a detective.

The structure of the application contains your clues.  From them you learn information about its structure, if the application is using pre-made components (like phpBB), what its inputs are, and what types of resources are available.  You also have a list of witnesses you can ask to get information not directly available from the site.  These are your search engines.  How often is the site updated?  Does the IT staff ask questions on new groups or forums?  Are there any known vulnerabilities against any of the application's components?  This is just basic system fingerprinting, only you are fingerprinting an application instead of a system.

Web application attacks fall into two categories: resource enumeration and parameter manipulation.

Resource Enumeration

Resource enumeration is all about accessing resources that the web application doesn't publicly advertise.  By this, I mean resources that exist but have no links to them anywhere in the web application.

The first way to execute resource enumeration is based on things you already know about the application.  If checkout.php exists, make a request for checkout.bak or checkout.php.old.  If you succeed you'll get a copy of the PHP source code complete with database connection strings and passwords.

In addition to what files are present in the application, you also know about the structure.

Suppose there is a resource like: /users/acidus/profiles/bookmarks.php

After trying various permutations of bookmarks.zip and such, sending a request for /users/ could return something interesting.  Perhaps it's a directory listing, or it serves an older default page.

Regardless, you will find links to resources that might not be mentioned elsewhere on the site.  While web servers can be configured to deny access to directories, this setting can be global or specific to a folder group.  Any settings can also be overridden on a per folder basis.

Just because /users/ or /users/acidus/ don't work doesn't mean /users/acidus/profiles/ won't work.  Always send requests for every directory you see.

Once you've sent requests for resources based on things you know, you should simply guess for resources.

/test.aspx, /temp.php, and /foo.html are good ones.

You could try db.inc, password.txt, or website.zip.

The directories /admin/, /stats/, and /pr0n/ are good ideas too.  A comprehensive list of files and directories to guess is beyond the scope of this article.

Parameter Manipulation

Parameter manipulation involves modifying the value of inputs trying to make the application act in ways the designers never intended.

We have all seen a site with a URL like: site.com/story.php?id=1732

The id= input specifies which resource to serve up.  Modifying this value allows access to different stories that might not normally be available.  This includes things like archived/deleted items or future/unpublished items.

This technique is known as "value fuzzing" and is quite useful.

What if we send a request with: id=1

Chances are the application will return an error.  However the error might contain information that is useful.  Things like the filesystem path for that resource.  Maybe we'll get some information about what database the application tried to contact or even information about the structure of that database!  Perhaps we'll get a stack track that will show what functions the program is calling or even the values of the parameters.  This technique is known as "edge case testing" or "bounds testing."  Programmers commonly forget to deal with edge cases so this area is ripe for vulnerabilities.

There are several attacks which are really just specific examples of parameters manipulation.

We will discuss SQL Injection, Command Execution, and Cross-Site Scripting (XSS).

SQL Injection

Almost all complex web application, from Amazon to TinyURL, have a back end database.

The inputs you supply the web application when you request a resource are eventually converted into some kind of SQL statement to extract content from this back end database.  Depending on how well the inputs are filtered you can get arbitrary SQL statements to run on this back end database.

It is best to show an example.

Suppose we discover a URL like: /ShowItem.php?id=2710

Chances are 2710 is the primary key in some kind of product table in the database.

Let's say in the PHP we have an SQL statement that looks like:

SELECT * FROM Products WHERE prodID = + id

This is called a concatenated query string and is vulnerable to SQL injection.

If I send:

2710 UNION ALL SELECT * FROM Customers

The resulting SQL statement is:

SELECT * FROM Products WHERE prodID = 2710 UNION ALL SELECT * FROM Customers

This statement will return the product information for product 2710 and all the records in the Customers table (assuming it exists).  This is simply one example of SQL injection.

See references [1] and [2] from more information.

SQL injection is a big problem.

The Paris Hilton T-Mobile hack didn't happen because someone sniffed the phone's traffic.  T-Mobile's website had an interface to allow subscribers access to their address books.  This means the website had to touch the database that stores contact information.  An attacker found an input they could exploit and dumped out several address books through the T-Mobile web page using SQL injection.

Command Execution

Many times there are applications that are executed on a web server simply by visiting a page.

For example, nslookup, whois, finger, ping, traceroute, uptime, who, last, and cat can be found in so-called application gateways.

This is where a web page receives input from the user and passes it to a native application, returning the output.  These gateways are quite common and were among the first uses of web pages and CGI.

Here is an actual Perl script I've seen in the wild which serves pages:

$res = param('file'); open(FIN, $res); @FIN = <FIN>; foreach $fin (@FIN) { print "$fin\n" }

A request for: /cgi-bin/file.cgi?file=contact.html will return the contents of the file contact.html.

First of all, I can see one vulnerability that isn't even a command execution.

Making a request for /cgi-bin/file.cgi?file=../../../../../etc/passwd will give you the UNIX password file.

Further, the open command supports the use of pipes.  Pipes allow a command to be executed and its output sent to another program.

A request for /cgi-bin/file.cgi?file=nmap -v | will execute Nmap on the server if it exists!

This happens because the open function will execute the Nmap command for you and the pipe means the open function reads the output from nmap -v as if it were a file.

See references [3] and [4] for more information.

Cross-Site Scripting

Cross-Site Scripting (XSS) is a mechanism to inject JavaScript into the web page that is returned to the user.

Consider the simplest example, as shown in Figure 2.

The web application has a personalized greetings page.  The key to the vulnerability is that the input parameter name is reflected into the page that is returned to the user.

Figure 2

As Figure 3 shows, if I insert a block of JavaScript it too is returned to the user.  So what can do you with JavaScript?

You can steal cookies, hijack sessions, log keystrokes, capture HTML traffic (a.k.a. screen scrapping), and many other things.

See [5] and [6] for more information about nasty things JavaScript can do.

See [7] for a case study using XSS + Ajax to make malicious requests as another user.

Figure 3

XSS can also get injected into the back end database of a website, commonly through forum posts, member profiles, and custom stock tickers.  This is especially nasty since the XSS will affect many more people.  There are many avenues to launch XSS attacks.

Reference [8] provides a detailed look at the different XSS mechanisms and defensives.

As you can see XSS is an extremely complex topic and I've only brushed the surface.  Due to technologies like Ajax and the fact that everyone is using standards compliant browsers the danger of XSS is much higher than it was when XSS was originally discovered in 2000.  For some of the really nasty stuff, see my Black Hat Federal presentation [9].

Defenses

Almost all web application attacks can be stopped by validating or filtering the inputs of the application.

SQL injection isn't possible if your numeric inputs only contain numbers.  XSS attacks are not possible if you don't allow a subset of a markup language in your input.  A well placed regex can save you a lot of headache if it's in the proper place.

Just because you have client-side JavaScript to validate input values doesn't mean you're protected.  I can always directly connect to your application and completely bypass your filters.  Always implement filters on the server side!

Your mantra should be "Never trust anything I get from the client."

Everything you get from the client including cookies, query strings, POST data, and HTTP headers can all be faked.  Always make sure you implement some kind of length restriction on your field too.  Otherwise someone might implement a filesystem on top of your web application [10]!

Conclusions

I hope this article served as a nice primer on all the issues surrounding web application security.

It's a complex field and I encourage you to check the cited works to learn more.  There is no group, there is only code.

References

1. SQL Injection White Paper  Examples of SQL injection.
2. Blind SQL Injection White Paper  Examples of blind SQL injection where you don't have ODBC error messages to help you craft attacks.
3. Web Security, Privacy and Commerce  A rather dated O'Reilly book that has an excellent security section in chapter 16.
4. Perl CGI Security Notes by Chris  Well written page going into many more command execution issues with Perl than I covered.
5. XSS-Proxy  XSS-Proxy shows how JavaScript can be used to monitor keystrokes and can receive third-party commands.
6. "The Phuture of Phishing"  Shows some of the nasty things you can do with XSS and how XSS can facilitate phishing.
• "The Phuture of Phishing" - Source Code and JAR File
• "The Phuture of Phishing" - Presentation Notes
7. MySpace.com Virus  Technical details of the MySpace virus as told by the author.  Shows how XSS attacks can be augmented by Ajax.
8. Real World XSS  An excellent paper discussing all aspects of the XSS risk.
9. Web Application Worms and Viruses  Details self propagating web malware and shows some very nasty implications of XSS.
10. TinyDisk  Implementing an application on top of someone else's web application.