We all know cybersecurity threats grow each day and, in these times of increasing danger, it is of great importance to test your website’s security before burglars do. While even the most dull-witted system administrator is able to run a scan with Nmap or Nessus (though he could ignore the myriad of options these scanners offer), it results slightly more difficult to find someone who knows how to use an intercepting proxy, or even knows what it is. The reason is simple, because a basic vulnerability scan is quite an automated task to perform, thus, you don’t have to use your brain, while the usage of an intercepting proxy, requires a more stringent logic to understand what you’re seeing in your console. In this article, we’ll see what is an intercepting proxy and how to use it to test the security of your application.
HTTP means HyperText Transport Protocol. HTTP is a text-based client-server protocol in which a client (generally a web-browser) makes a request, and a server (generally the machine that hosts the web application) answers the requested resource. By default, the server listens on port 80 (http) or on port 443 (https). Each HTTP request contains three parts:
- a method that identifies the request’s type, plus a URI and the HTTP version used by the client
- a header that contains optional parameters
- an optional MIME (Multiporpose Internet Mail Extensions) document attached to the request
The HTTP response, is also made of three parts, specifically:
- a three-digit status line
- a header
- a MIME document
The HTTP Methods
There are several HTTP methods that can be used like, for example, GET, POST, HEAD, PUT, TRACE and so on, but in this article we will focus on the following:
- GET – it is the most common one. It is used to retrieve a document from a server
- HEAD – a variant of the GET method, it is used to retrieve the header of a document, but not the document itself. It can be used to verify if the document exists.
- POST – it is used to send a document to the server
The HTTP Headers
- Content-Length – indicates the length of the document in bytes
- Content-Type – indicates the type of the MIME document. For example, HTML pages use “text/html” type
- Content-Encoding – tells how the document has been encoded, for example, “x-gzip”
- Server – returns the version of the web server that generated the response
- Date – indicates when the response has been produced by the server
- Last-Modified – the date of the last modification of the document
- User-Agent – provides information about the client. The server can answer with a different response depending on this header
- If-Modified-Since – it is a date. Using this date, the server will return the document only if it is newer than the version stored in the client’s cache
- Referrer – indicates what’s the link followed by the client before arriving in the current page
- Host – the fully qualified domain name of the URI requested
HTTP Status Codes
All status codes starting with “2”, indicate a positive response like “200 Ok”. All status codes starting with “3”, indicate that the document is no longer available like “301 Moved Permanently”. All status codes starting with “4”, like “404 Not Found”, indicate that the server found an error in the client’s request. All status codes starting with “5”, indicate an internal error of the server.
What Is An Intercepting Proxy
To test the security of your web application, you will need to understand how it acts in every possible situation. To make this possible, the only way is to read every request and response exchanged, analyzing every possibility of exploitation. Here comes the utility of an intercepting proxy. This tool, in fact, is the only really indispensable one to test the behaviour of your website. An intercepting proxy can, as its name tells us, capture every response and every request and, furthermore, it gives you the possibility to change them.
If you are wondering why you should want to change a response coming from the server, try to figure out this classical example: you are browsing the shopping cart of a website and you see that a certain item has a cost of $300. Using your intercepting proxy, you can observe that the price is actually defined with a hidden form that the normal user could not see simply browsing the website. Thanks to your powers of observation, you can change the cost to, for example, $0, submitting the request and buying the item for free. I personally encountered an application that made me do this trick, but keep in mind that this is only an example of the myriad of vulnerabilities that you could find in this way. For example, you could discover a sql injection vulnerability or a xss one.
How to install ZAP
ZAP stands for Zed Attack Proxy. ZAP is only one of many intercepting proxies, but it is my favourite, because it has awesome features and it comes to you absolutely free. It is maintained by hundreds of international volunteers and it is multi-platform, so you can install it on Linux as well as on Windows. Let’s see how you can install ZAP on Linux:
- go to github and download the latest version
- install it typing ./ZAP_X_X_X_unix.sh
- run cd /usr/local/bin ; ./zap.sh
Now you will be prompted with the following choice:
Click on “Yes, I want to persist this session” and give to it the name and location that you desire. Now you’ll see tha main console, empty:
Go to “tools”, “options”, “local proxies” and remember what port ZAP is listening on (address is localhost). You can change the port to a different one, if you want.
Now click on “Dynamic SSL Certificates” and click on “generate” and “save”.
You’re now creating a new certificate that your browser will use to trust ZAP as local proxy. Now go to your browser’s settings (we’ll use firefox in this example) and set the port for the proxy to the same used by ZAP:
Now let’s import the certificate in your browser, clicking on “import” and choosing the location where you saved the previously generated one:
Now you’re ready to surf the internet with Firefox intercepting every request and response with ZAP! As far as you browse your website, you should see a lot of captured requests and responses in the console:
In the left grid you will see the directory view of your website, while in the lower edge of the console, you’ll see the list of the messages exchanged between your browser and the server. If you click on one of them, you’ll be able to see it in details and, yes, you’ll be able to change it and re-submit it.
Every message is identified by an ID and highlighted with the risk severity.
If you want to explore, you can try to install other intercepting proxies like:
- Burp Suite
Identify Application Entry Points
Now that we installed our intercepting proxy, and we’re able to capture every request and every response, let’s see how we can use the gathered information, to study the behaviour of our website. The starting point is finding the entry points of our application. As you walk through your application, take note of where the GET and POST methods are used.
You can see that the GET is the most used method but in the POST you can usually find sensitive information like prices of items and other things the developer doesn’t want the user to see and modify. Take note also of where uncommon methods like PUT and DELETE are used, because they can usually reveal an unexpected behaviour of the application. Try to understand where cookies are established and keep track of every hidden form. Identify all the hidden parameters in the POST request (those that you can’t see without an intercepting proxy), and identify all the query strings in the GET requests (those with the “?” mark). Find all the parameters in the query strings like “pass=foo”; you’ll have to identify the parameters even if they are encrypted. Take note of every redirect, of every 4XX and 5XX status code and, more generally, of every error message.
This enumerating job is quite boring but, with a growing experience, you’ll be able to identify the interesting zones of your website in less time. This crucial phase of your test is fundamental to perform every security test, but it’s only the beginning; if you perform an exhaustive enumeration phase, you’ll be able to identify your application’s vulnerabilities.