The attack‍ surface‍ is the area of our web application‍ test in which we have to put all of our efforts.

The more we know about the target, the wider the attack surface will be and us result more chance to find an exploitable vulnerabilities‍

Lets start our attack surface,

CLIENT SIDE VALIDATION:

User submitted data through web forms can be validate on the client side, server side or both

Recognizing where the validation exist will allow us to manipulating‍ the input in order to mount our input validation attacks like sql injection‍ , cross site scripting‍ or general logical flaws‍ . We can reveal the presence of client side validation by inspecting the web page source code and looking at JavaScript functions triggered upon form submittal. We can do this different ways. My favorite is using Firebug, the very popular Firefox Add-on that lets you to inspect the web page source code easily without having to read hundred lines of code before finding the interesting information

DATABASE INTERACTION:

Detecting database‍ interaction will allow us to look for sql injection‍ vulnerabilities in the testing phase. By database interaction, we mean that the user input changes the appearance of the page because either different data is fetched from the database or, new data is added. This hints that the SQL queries are generated from our input and if the input is not properly sanitized,may result in SQL injections

FILE UPLOAD/DOWNLOAD:

It is not uncommon to encounter web pages providing dynamic downloads according to a parameter provided by the user. This kind of behavior if not handled correctly, can lead to a number of nasty attacks including remote file inclusion‍ and local file inclusion‍ vulnerabilities.

File upload forms are very common in forums, social networks and various CMS. Desired files types can be anything from images, documents and even executables. Handling these uploads is a critical task for the web developer. Mistakes in the way these documents are validated upon upload can lead to critical vulnerabilities, so we will make sure to note any page that offers this feature.

DISPLAY USER SUPPLIED DATA:

Finding displayed user supplied data will bring us to the top web application vulnerability: cross site scripting‍

There is 3 different kind of Cross Site Scripting Vulnerabilities.

Stored Cross Site Scripting‍ , is the most dangerous one because its effects the server side as is stored on the target server, and is not detectable with the eye.

Reflected Cross Site Scripting‍ , is where the injected scripts gets reflected of the web server. Reflected attack are easy detected from the victim.

DOM Based Cross Site Scripting‍ , is an attack where the payload is executed as a result of modifying the DOM on the victims browser.

REDIRECTIONS:

Redirections are server side or client side directives to automatically forward the visitor of a web page to another web page. From a server side perspective the server can issue two different HTTP response codes‍ to make a redirect (301 or 302)

At this point the difference between them is not that important, just keep in mind that 3xx code stands for redirect.

From the client perspective, the redirection is handled by the web browser. It recognizes the 3xx HTTP Response code and makes a request to the page contained in the Location header.

Another kind of refresh is the so-called meta refresh. The meta HTML tags are used to add metadata‍ information to a web page. This data is usually read by search engines to better index the web page. Meta redirect, instead, is a way to generate a redirect either after x seconds or if x=0.

Finding redirects is an important part of our attacking surface as HTTP response splitting‍ and other Header manipulation attacks can be performed when redirects are not handled properly.

ACCESS CONTROL AND LOGIN PAGES:

Login pages will reveal the presence of restricted access areas of the site. We will employ authentication bypass‍ techniques as well as password brute-force attack‍ to test the security of the authentication routines in place.