So attack surfaces, well, they can be described best during development.
So in other words, while developing threats can be modeled and then the vulnerabilities will be prevented
before coding is finished.
Hmm, that's not always possible.
So one of the things that I want to touch on here is just a little different than modeling threats.
So before diving into Web application attacks, I want to make it clear and help you to understand the
nature of attacks.
So I'll define three logical surfaces that are typically hit by attacks.
OK, so hacking an application doesn't always happen through the application interface.
What?
Right.
So as a protester, you really need to focus on all surfaces while testing.
So the user service.
Users, of course, or maybe not, of course, but they certainly are the most important threat.
Or you could also look at them as the weakest point in the security process so the application itself
can be very secure and work great.
But if the users administrators are careless.
Well, think about it.
It's going to break the application consistency into.
Server service.
So remember that applications need server software and a server computer.
So if there are any vulnerabilities in these components, this can also break the consistency of Web
applications.
Think of a vulnerability in the server software such as a vulnerability in Apache or ISIS can also bring
down your application security.
Application service.
This service is the application itself.
So the problems on the surface will generally be caused by bad cohabits and vulnerable libraries, let's
take, for example, school injection.
So it's caused due to lack of proper input validation.
So I'm not going to categorize everything and just, you know, make it difficult to grasp, but when
you're testing, these services are going to guide you to shape an attack.