Web Application Attack Surface - Measurement and Implementation
03/09/2023
Moss Drake
At the PNSQC 2023 March Meetup, Bhushan Gupta provided an orientation on attack surfaces, vectors, and methods of penetration for web applications. Then, he looked further into a method for quantifying the risks and assigning security priorities before the code is written.
Michael Larsen wrote an account of the presentation as part of his "live blogging" experience.
My guess is a lot of people, even if they've heard the term, may not have a clear handle on exactly what it is. What is the attack surface? it's literally any aspect of your site that can be interacted with. That's not just the UI. You can attack via the API. You could attack via the database. You could attack via microservices that exist in parallel with the web application. There can be open entries or back doors that can be exploited. The more third-party products that make up your web solution, the more likely unintended back doors and entry points can be
exploited.
We can work with data, system processes, remote procedure calls, and the underlying file system can provide an attack vector. We want to get a handle of the attack surface so that we can identify possible vulnerabilities. Basically, any attack vector that can gain access to a system is part of the attack surface. There are many possible attack vectors or entry points which could be vulnerable. There is also an Attack Surface Index, which is a measure of the overall attack surface. We have targets we can access, processes that can enable access, channels that can be used to target the application, control mechanisms that can be used to deny access (and leveraged to possibly breach the system), and the payload that
can be sent to compromise the system.
Web Environments are especially ripe for this kind of attack because systems are often uncoupled. You can have one server or service presenting the front end, another handling the back end transactions, and any number of other services that reside in between. HTTP requests can be sent, received, and intercepted to figure out how to interact with machines, for good and for ill. Through processes like data injections or Man in the Middle attacks, systems can be vulnerable to breaches. SQL Injection and Denial of Service attacks are common, as are attempted interactions with APIs.
Okay, so that may be exciting or terrifying but what can we do to address it? Bhushan says to start by measuring the attack surface. What are the valuable targets? How can they be approached? Once we've established what they are and how to get to them how valuable are they and how attackable are they? From there we can determine a plan of action to help us decide which areas we can easily defend and which areas need to be bolstered.
The aspects that can help us are areas such as limiting roles any user can participate in, and limit the ability to authenticate, including using two-factor authentication. Additionally,
look to see if there are easy targets by way of sharing information via micro-widgets or micro-services.
This is an intriguing way to look at the possibilities of attacking a system and also attempting to prevent or at least mitigate those risks. It's important to realize this is not a complete or foolproof method but it is a good way to see how robust your systems are and where they can be improved over time and with iteration.
Moss Drake
At the PNSQC 2023 March Meetup, Bhushan Gupta provided an orientation on attack surfaces, vectors, and methods of penetration for web applications. Then, he looked further into a method for quantifying the risks and assigning security priorities before the code is written. Michael Larsen wrote an account of the presentation as part of his "live blogging" experience.
My guess is a lot of people, even if they've heard the term, may not have a clear handle on exactly what it is. What is the attack surface? it's literally any aspect of your site that can be interacted with. That's not just the UI. You can attack via the API. You could attack via the database. You could attack via microservices that exist in parallel with the web application. There can be open entries or back doors that can be exploited. The more third-party products that make up your web solution, the more likely unintended back doors and entry points can be
exploited.
We can work with data, system processes, remote procedure calls, and the underlying file system can provide an attack vector. We want to get a handle of the attack surface so that we can identify possible vulnerabilities. Basically, any attack vector that can gain access to a system is part of the attack surface. There are many possible attack vectors or entry points which could be vulnerable. There is also an Attack Surface Index, which is a measure of the overall attack surface. We have targets we can access, processes that can enable access, channels that can be used to target the application, control mechanisms that can be used to deny access (and leveraged to possibly breach the system), and the payload that
can be sent to compromise the system.
Web Environments are especially ripe for this kind of attack because systems are often uncoupled. You can have one server or service presenting the front end, another handling the back end transactions, and any number of other services that reside in between. HTTP requests can be sent, received, and intercepted to figure out how to interact with machines, for good and for ill. Through processes like data injections or Man in the Middle attacks, systems can be vulnerable to breaches. SQL Injection and Denial of Service attacks are common, as are attempted interactions with APIs.
Okay, so that may be exciting or terrifying but what can we do to address it? Bhushan says to start by measuring the attack surface. What are the valuable targets? How can they be approached? Once we've established what they are and how to get to them how valuable are they and how attackable are they? From there we can determine a plan of action to help us decide which areas we can easily defend and which areas need to be bolstered.
The aspects that can help us are areas such as limiting roles any user can participate in, and limit the ability to authenticate, including using two-factor authentication. Additionally,
look to see if there are easy targets by way of sharing information via micro-widgets or micro-services.
This is an intriguing way to look at the possibilities of attacking a system and also attempting to prevent or at least mitigate those risks. It's important to realize this is not a complete or foolproof method but it is a good way to see how robust your systems are and where they can be improved over time and with iteration.