Denial, exposure and online security

Database keys are also often exposed. Attackers will attempt to manipulate the "uid" parameter in the URL below to access other user accounts.

http://www.example.com/banking/genReport?uid=10347343

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.