How to go about web application penetration tests
Before getting started with a web application penetration test, you first need to set up a testing environment and define the scope. At the very beginning, I also start thinking about the reporting method and prepare a checklist of everything I am going to test. This is to make sure I don’t forget anything during the testing process and also to remind myself again of what needs to be tested as well as to address any potential flaws before starting the test.
It’s equally important to prepare a test procedure with a checklist and to ensure that the tools are up-to-date and ready to use. When performing a web application penetration test, I use the following tools at a bare minimum:
Scoping is also necessary at the very beginning of the project, so that you are on the same page as the customer in terms of how the web application penetration test will be performed and what it should achieve. Scoping is competed together with the customer during a kick-off meeting. The following questions must be addressed by the kick-off meeting, at the very latest:
All of the main items should be clarified before starting the web application penetration test.
There are plenty of good resources available for web application penetration testing. I mainly use the resources provided by OWASP, including the OWASP Testing Guide and the OWASP application security verification standard.
Before I start testing for specific vulnerabilities, I first take an overall look at each web application and try to interact with as many elements of the web application as possible. This includes evaluating differences between various user roles. While browsing, my proxy is running the whole time in the background. This allows me to gain the most comprehensive overall picture possible from the history of all of my requests and responses to them. The first time I browse through the application, I take mental notes of potentially interesting possibilities for interaction, such as login screens and search fields. Then I browse through the application a second time and more closely examine the requests that are sent as well as their responses. This also allows me to discover interesting targets for manual testing.
After I have my first overall impression, I start testing the items previously identified in order to find vulnerabilities. At the same time, I run automated tools on a range of selected endpoints. The tester should not shy away from using automated tools when performing web application penetration tests, as these can help to find the “low-hanging fruit” at an early stage, allowing the tester to focus on more complex tasks. When using automated tools, however, I always make sure to log all executed requests and responses, so that I can briefly review them after running the tool. Sometimes there are unexpected responses that the automated tool does not recognize. This is where I come in as the tester and examine everything manually.
This category encompasses a very broad range of tests and includes all vulnerabilities that an attacker can exploit by using manipulated data to execute a command. These include manipulated SQL statements, operating system commands and many other vulnerabilities. Vulnerabilities of this sort should be identified using an SQL injection procedure.
In this sample scenario, I will test a web shop. This web shop allows products to be filtered by category. While first browsing through the web shop, I discovered that a normal filter-by-category request looks like this:
As the tester, I noticed here that the category filter could land in the WHERE clause of an SQL statement. This is a spot where I will definitely attempt an SQL injection. First, I try using the classic SQL injection
' OR 1=1--. A request would then look like this:
Next, I compare the response from the injection with the response from an unfiltered request. If, for example, the number of products displayed in the response has changed, I can assume that the SQL injection worked.
From the back-end perspective, the whole sample scenario would look like this:
String category = request.getParameter("category"); String query = "SELECT * FROM products WHERE category =' " + category + " ' AND released = 1";
In the case of an attack, the executed SQL statement would ultimately look like this:
SELECT * FROM products WHERE category='' OR 1=1--
to bypass the limiting
AND released = 1.
To close this case fully, I will also show how the vulnerability could have been prevented. SQL injections can be prevented, for example, with prepared statements. In the above case, that would specifically look like this:
String category = request.getParameter("category"); String query = "SELECT * FROM products WHERE category = ? AND released = 1"; PreparedStatement pstmt = connection.prepareStatement(query); pstmt.setString(1, category); ResultSet results = pstmt.executeQuery();
Injections can generally be prevented by using secure API calls, whitelists and specific language-dependent escape characters. For more detailed information, refer to the Injection prevention cheat sheet.
This article has hopefully provided some basic insights for anyone interested in the procedures for web application penetration testing. Careful preparation for the actual technical testing is important and first requires defining of the scopes and objectives of the web application penetration test. When performing the test, the tester should not only possess technical expertise, but also the intuition to identify areas of interest. Even a person who is not an IT security professional can acquire this intuition by monitoring the network requests sent every time they visit a website. By visiting several websites, they will gain a sense of how a “normal” website behaves.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here