sjb007

Web applications have huge attack surfaces. Most sites have hundreds of URLs, and each function has plenty of parameters, form fields, cookies, and headers for attackers to play with.

One simple way to make your web application more secure is to minimize your attack surface. Let's look at five simple ways to do this.

Tighten up your URL space

The first step is to lock down your webserver, application server, application configuration, and code tree to be sure that you're not supporting any URLs that you didn't expect.

You should also check your application for functions, backup files, temporary files, and test code that wasn't intentionally deployed. Just because they're not linked in the user interface, doesn't mean an attacker can't find and exploit them. Also, be sure you're not supporting all file extensions - just the specific ones you expect.

Ditch those hidden fields

Hidden fields are form values that aren't displayed to the user. When the user submits a form, the hidden fields are submitted just like any other form field. Attackers can easily change hidden field values to anything they want with browser tools like TamperData or WebDeveloper. Hidden fields are frequently quite vulnerable to attack because they're often overlooked when implementing validation.

You could use normal input validation techniques to check the hidden field, but the best way to check is to do a direct comparison with the value that you just set in the web page. Of course, if you can do this, there's really no point in having the hidden fields at all, so consider just getting rid of them and reducing your attack surface.

Don't expose your privates

Most applications use parameters or form fields that reference data on the server by its name or ID. Attackers love to try to access unauthorized data by tampering with these "direct" references. For example, imagine a URL that references a file on the server:

http://www.example.com/banking/fetch...fn=03102008.xl

Attackers will immediately attempt to manipulate the filename to access other files on the host. If the code takes the "fn" parameter and appends it to a filepath, the attacker might try sending the following to gain access to the host's password file:

"?fn=../../../../etc/password%00"

The %00 at the end of the URL will be decoded by the container into a null byte that terminates the string, leaving only the attackers path in the parameter. There are hundreds of attack variants, so don't try to filter out attacks.

Full article here - http://www.theregister.co.uk/2008/11..._applications/