Web application pentest guide Part-II

In last part of the article we have discussed the process of Requirement Collection, Information gathering and URL discovery now we will discuss the other steps.

Automated scanner configuration

Scanner configuration is one of the most critical parts of the process. If anything goes wrong, then we might be hampering customer's application, and now we will discuss how. If we are going to run scans on customer live production environment, then be alert there is a possibility we will make denial of service on the website by a running scanner, and their database will be filled with junk entries generated from the scanner. Things to remember before running scans:

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

• Are we doing a scan with login credentials? - If yes, the application must have some forms and functionality which allows the user to submit data to the database. Then if the scanner scans the same functionality with 100s of payloads and all data will get submitted to the database. As we have already discussed this thing during requirement collection step that asks the customer to take database backup. So, after the pentest is done the application owner will restore the database.
• Are we scanning all URLs? – If yes, make sure don't scan any critical URLs which will directly impact the application or user, for example, a URL which runs a cron job on the server and it generates mail on each hit this kind of URLs must be excluded from the scanner because it will trigger 100s of mail and the cron job also.

Now we will see how to configure scanner we always prefer to use multiple scanners because all scanner will not be able to find everything in our case we are using Burp Suite and Acunetix. One we have captured all URLs in Burp Suite and done with the URL discovery part we will go to Burp Sitemap and right click on the scope and select Actively scan this host.

Now Burp Suite will scan all URLs from the scope as can be seen below.

There is a problem with this process if we are scanning the logged-in areas so there is a probability that we will not get better result because the logged-in session is expired and the scanner whenever sends request with payload the application redirects it to the login page so we have to do scanning with active session for this generally during the application browsing process select the URL on which you want to run scan and right click and do an active scan the scanner will start scanning with single request and active session.

As can be seen above once we have done with scanning all URLs and this is what we have found. Next, we will configure Acunetix open the scanner and click on New Scan, and it will open a scan wizard.

Add the target URL in website URL section and click on Next. Select customize on next step.

In Scanning Options check scanning mode and select extensive mode.

Next, select Crawling Options and check these two options: Start HTTP sniffer for manual crawling and Fetch default index files.

Then click on Ok and the scanner will first start crawling the application and it will open another window for manual browsing at that time again browse the application with login and trigger every functionality so can the scanner capture all requests. Once you are done with the browsing close the window and scanner will start scanning the application.

In our case below are the found vulnerabilities.

Manual Testing: In manual testing, we will be focusing on two things:

1. Try to find logical vulnerabilities by abusing the application functionalities
2. Evaluate the automated scanner result and verify all vulnerabilities manually and remove the false positive results.

In the logical issues finding we will be focusing on that kind of issues which will generally not found by any automated scanner we are not going to test issues like SQL injection, XSS or any other this kind of issues which generally can be found by running scanner so we are not going to waste out time to finding these kinds of issues. For finding the logical issues first, we must understand the application functionality that what is does when the user triggers that functionality and what will happen if we change the parameter's value. So, we are going to show some testing scenario of some of the functionalities of our target application. Once we logged in into the application, the first functionality we came through was Account summary which was shows details from Account Activity. The account activity shows the transaction details from accounts; now as can be seen below there are five accounts i.e. Savings, Checking, Loan, Credit Card, and Brokerage.

So, when we select the Savings account it triggers the following request:

As can be seen above in POST request there is accountId parameter with value 1 so we selected all type of accounts from the drop down menu and noticed that the id value changes subsequently. We have identified that for five types of account accountId value from1 to 5 is assigned. No, what if we changed the value to 6, 7, 8, etc. will it show some data. This will be our test case in this scenario. So, we can fuzz the accountId parameter value by using Burp's Intruder option and can check the response.

Another scenario we will see in Feedback form which is a non-logged-in area. What this kind of form do it takes users feedback, and it must be stored somewhere it could be in the database or in the mail.

As can be seen above the form ask for name, email, subject, and comment. So, the first thing we will check:

Insufficient Anti-automation - When we are submitting the request is it possible to repeat the same request multiple times. If yes then it will be a vulnerability because if the application stores feedback in database then the database will be filled with junk data and possibly it will go out of memory which will cause denial of service, or if the application stores the feedback as a sending email to the application owner then it will send create email flooding issue because on multiple form submission the application owner will get multiple emails. As can be seen above when we submit the feedback form it triggers the POST request.

Now we sent this request in Intruder and repeated it ten times, and as can be seen below all requests we get submitted:

Malicious Link Injection: Here will check the comment field by adding hyperlinked malicious link. If the form gets submitted, then it will be possible to send phishing links to the application owner by using an HTML hyperlink tag.

As can be seen above we have submitted <a href="https://www.phishing.com">Click Here</a> and clicked on Send Message, and it got submitted successfully.

By using the same method, we must test all applications functionalities it will be a time-consuming process, but the result will be much better when we will combine the scanner and manual vulnerabilities in the final report.

Once we are done with the logical vulnerability finding we will check the scanner found issues and remove the false positives, for example, we opened the Burp result, and it detected SQL injection, so we checked in which URL.

As can be seen above its showing currencyId parameter is vulnerable to SQL injection, so we fired Sqlmap on this request, and as can be seen below it can detect the backend database.

One more instance we will see for cross-site scripting vulnerability as can be seen below burp has injected an XSS payload in the accountID parameter.

We repeat the same request and open the response from the browser, and the XSS payload gets executed in the browser.

By executing them, all vulnerabilities found by both scanner that which issue is false positive.

Reporting: The last part of the complete pentest activity which is detailed documentation of all findings which we will share with the application's owner. In the report, the following things will report.

Vulnerability name – The name of the finding like SQL injection, XSS, etc.

Severity – Vulnerability severity level High / Medium / Low.

Description – Detailed description of the finding how and what we found.

Impact – Impact of the vulnerability if we exploit it.

Affected URLs – All URLs and parameter where we issue has been found.

Recommendation – How to fix the issue.

The details mentioned above can be presented in the below tabular format.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Below is the list of all vulnerabilities which is found by us.