Ground Zero – How to Identify all Entry Points in Web Application?

Leave a comment

If hacker has to identify vulnerabilites in any web application or website, his/her first task is to collect the list of all application entry points. This is why this stage is also referred as Ground Zero Step of any hack attempt. Hacker needs to zero in the attack surface in order to find all potential vulnerability areas.  Before beginning any hack attempt, hacker should have good understanding of application, like how user and web browser communicates with web application or website. So Friends, lets learn about Ground Zero i.e. Identify all entry points in web application or website in detail.

Ground Zero - How to Identify all Entry Points in Web Application?

As we all know a web application is all about requests and responses i.e. what we are requesting and what we are getting as response. Since we are talking about web application or website, we should be more curious about HTTP requests (GET or POST) and have to identify when GET requests are used and when POST requests are used to pass parameters to web application. Also we need to pay special attention towards all thoses variables or parameters (specially web form fields) which are passed to the application. But main question rises, HOW??

There are multiple ways of identifying what parameters are sent via POST or what parameters are sent via GET. Easiest one is to get via intercepting ZED ATTACK PROXY Tool by OWASP. You can also use INSPECT feature ( provided in Mozilla Firefox and Google Chrome) of latest web browsers to get that details with help of some more plugins like tamper data and cookie master. But beleive me ZED attack proxy is the best as it traps almost each and every request sent and response received. This is very time taking process but you will get smarter as time and practice goes on.

We have tried to Zero in your work by identifying all possible type of requests and response that can be a potential entry point into the system. Note: There are PUT and DELETE type of requests too but they are rarely used and not covered in our listing. Lets have a closer look that what type of requests and response can be possible entry points in web application or website.

REQUESTS that needs special attention:

  • Hacker needs to identify all parameters used in a POST request (these can be found in body part of HTML).
  • Needs to identify where GET requests are used and where POST request are used. (again body part of HTML)
  • Within the POST request, pay special attention to any hidden parameters. When a POST is sent all the form fields (including hidden parameters) will be sent in the body of the HTTP message to the application. These typically aren’t seen unless a proxy or view the HTML source code is used. In addition, the next page shown, its data, and the level of access can all be different depending on the value of the hidden parameter(s).
  • Needs to identify all parameters used in a GET request (i.e., URL), in particular the query string (usually after a ? mark).
  • Need to identify all the parameters of the query string. These usually are in a pair format, such as foo=bar. Also note that many parameters can be in one query string such as separated by a &, ~, :, or any other special character or encoding.
  • When it comes to identifying multiple parameters in one string or within a POST request is that some or all of the parameters will be needed to execute the attacks. The hacker needs to identify all of the parameters (even if encoded or encrypted) and identify which ones are processed by the application.
  • Need to check for any additional or custom type headers not typically seen (such as debug=False).


RESPONSE’S That need to be monitored:

  • Identify where new cookies are set (Set-Cookie header), modified, or added to.
  • Identify where there are any redirects (3xx HTTP status code), 400 status codes, in particular 403 Forbidden, and 500 internal server errors during normal responses (i.e., unmodified requests).
  • Check for some interesting headers like “Server: BIG-IP” indicates that the site is load balanced. Thus, if a site is load balanced and one server is incorrectly configured, then the tester might have to make multiple requests to access the vulnerable server, depending on the type of load balancing used.


Now lets learn with examples that how to identify entry points in web applicaiton:

Consider an example of Shopping Cart application or ecommerce website. Suppose user has selected an item, below is example of sample GET request:

Cookie: SESSIONID=IGlzIGZvbyBhbmQgcGFzc3dvcmQga

The above request contains following parameters that need to verified for potentical vulnerabilites: CUSTOMERID, ITEM, PRICE, IP, and the Cookie (which could just be encoded parameters or used for session state).


Below is an example of POST request for login request into above shopping application:


and body of the POST message will be something like below:


In above request we need to note all those parmeters that we previously noted but we also need to pay attention on parameters which are passed in body part of html i.e. user, pass, debug, fromtrustIP and also need to check Session Custom cookie.

Now we need to validate all these parameters one by one for all possible vulnerabilities to zero in all entry points. One entry point is sufficient to break down any web application, so Developers must make secure applications to avoid all possible type of vulnerabilities.

That’s all for today! Now we know our Ground Zero too. Enjoy and have happy learning.

Author Bio

Lokesh Singh

Hey Friends, This is Lokesh Singh. Your friend, who loves to share knowledge with friends as i believe in "Sharing is Caring". If you like our tutorials then you can send your gratitude by saying thanks or clicking any of our Sponsor ads.

Leave a Reply

Your email address will not be published. Required fields are marked *

one + 4 =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>