What is Attack Surface Management?

Attack Surface Management is a process where you identify, quantify, and reduce the attack surface of your applications. In its simplest form, it applies to web applications but can be applied to any software.

NOTE: Attack Surface Management is sometimes referred to as "application hardening", but I feel that this term is often misused and should probably be avoided.

If you are interested, I wrote a list of common terms in penetration testing and what they mean for my fellow penetration testers. Some of them might surprise you!

Why Should You Care?

The proper implementation of ASM not only makes your code more secure but also speeds up the development process by reducing churn, bugs, and failures.

ASM is not yet a solved problem in the programming community, so it pays to have a working knowledge of it or at least know who to contact.

Applying Attack Surface Management to Web Applications

First, we must understand what an attack surface is. An attack surface in its simplest terms is the sum of ways you can be attacked. In the case of a web application, this is defined by the number of entry points into your application.

To quantify an attack surface you must first understand what components are necessary for it to function properly. It would not be wise to include a library or framework that has vulnerabilities and does not provide any direct benefit. After all, why add a potential way to be attacked into your application?

Some of the entry points that need to be accounted for are:

HTML templates/pages (note that these might only exist in userland code and not the framework) <form action="/" method="post"> Username: <input name="un" type="text"/> Password: <input name="pw" type="password"/> <input type="submit"/> </form>

Input/Output: This includes anything that the user or application takes in and sends out. These include SQL queries, POST requests, cookies, etc.

Code execution: The ability to execute code on your server is the most dangerous attack surface to your application. In almost all cases, it should be reduced as much as possible.

Configuration: Many applications use various configuration files or custom directories to store sensitive information such as API keys and database credentials. These must also be accounted for in the application attack surface.

Attack Surface Management Example

In order to properly reduce the attack surface of a web application, you first must understand how it functions. For example, say that you have the following HTML form:

<form action="/login" method="post"> Username: <input name="un" type="text"/> Password: <input name="pw" type="password"/> <input type="submit"/> </form>

If you are not familiar with HTML forms, it should be noted that the action attribute of a form is the location that will process the submitted data. In this case, once we submit our form, /login will process its contents. On our server, /login may look like:

require 'net/http' require 'uri' post '/login' do # Code to process the login data end

From here, we could easily scope down our attack surface by removing unnecessary code and libraries from the application. The following would be a great start:

require 'net/http' require 'uri' post '/login' do Net::HTTP.start('localhost') do |http| # Code to process the login data end end

NOTE: This is not a suggested fix, it is just an example.

Conclusion

If you are not familiar with ASM, you can start by simply removing unnecessary code and libraries from your application. You will be surprised how much this will reduce your application's attack surface.