Denial, exposure and online security
Five top tips
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:
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:
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.
Database keys are also often exposed. Attackers will attempt to manipulate the "uid" parameter in the URL below to access other user accounts.
A simple approach to solving direct reference issues is replacing them with indirect references. You can use an "access reference map" to assign integers to the authorized resources, and then use the integers in the web page instead of the direct reference.
When the indirect integer reference is returned, your code can look up the corresponding direct reference in the map. This prevents tampering with the parameter and significantly restricts the application's attack surface.
Only accept good input
There are hundreds of thousands of Unicode code points and dozens of different encodings. This creates a huge attack surface for your application.
As a first stage, your application should enforce a global set of allowed characters. Create a filter that rejects or at least sanitizes characters not allowed in your application.You can make the list of allowed characters as broad as it has to be, but you'll bound your attack surface. If you want to get fancy, you can create individual whitelists for the various parts of the HTTP request.
The global character whitelist often isn't enough, though. Your application will probably have to allow in some dangerous characters like apostrophe for example to support people with names like O'Malley, for example. Therefore, you also need to do specific validation on a field-by-field basis.
Validation is all about minimizing the attack surface of your application. An unvalidated form field can contain virtually any attack against a downstream interpreter or application. By enforcing a specific positive pattern, you dramatically reduce the attacker's freedom. Of course you shouldn't forget about using parameterized interfaces or output encoding/escaping, but checking the input is a critical first step.
Deny by default
Don't slip into thinking that as long as your web application does what it's supposed to, anything else it does is okay. Instead, think of your application as an API that you're exposing to attackers. What shows up in your user's browsers is irrelevant, since attackers can invoke any method with any parameters.
Many organizations are still trying to manage their attack surface with a negative approach - attempting to block attacks patterns. With the huge variety of ways to attack web applications, a positive approach implementing deny by default tends to be easier to manage and more cost-effective.
The best way to start is to go through all the layers and tiers of your application stack. Check all your configurations and security code for a default deny rule. Then just make sure all the holes in your attack surface are intentional.®
Jeff Williams is the founder and CEO of Aspect Security  and the volunteer chair of the Open Web Application Security Project . His latest project is the Enterprise Security API , a free and open set of foundational security building blocks for developers.