Setting Up Automated Scanning of Apps Using Custom Authentication, Part 2

Automated security scanning has always been a challenge for applications that implement custom authentication mechanisms. Have you ever come across a scenario in which automated tools have failed to scan an application because of an authentication failure? Most automated scanners replay login requests to authenticate when a session expires during a scan.

We encountered such a scenario on a recent engagement and have written two posts to explain issues related to solving this challenge. In the first part, we discussed problems faced by automated scanning tools when login credentials are randomized and login requests cannot be replayed. In this part, we will go through the steps required to address this issue using the automation capabilities of the intercepting proxy tool Burp. 

Burp extension

In the target application, client-side JavaScript generates a hash-based message authentication code (HMAC) from the user-provided password and random key received from the server before authentication. We will write a sample Burp extension that will perform the same operation and post the login request.

The following extension fetches the random value from HTML hidden field and calculates the HMAC using the password and the random value. The credentials are hardcoded in the extension code. Once the HMAC is calculated, it sends the login request to a URL such as http://localhost:8080/test01/Signin. The code for creating the HMAC of the password and logging into the application is written inside the PerformAction function.

The following code is saved as

Adding the extension

Navigate to Extender->Extensions->Burp Extensions and click Add. Provide the location of file,, created above. Make sure you have provided the path to the jython-standalone .jar file under the Option tab (Extender->Options->Python Environment).

Figure 1: Adding extension code to the Extender tool.

If the extension is added successfully, it will appear as “Login to demo App” as a drop-down menu under the label “After running the macro, invoke a Burp extension action handler” in the session-handling action editor section. Let’s verify:

Navigate to “Project options –> Sessions –> Session Handling Rules –> Add/Edit (Screen 1) —> Session handling rule editor –> Rule Actions —> Add—> Check session is valid (Screen 2) –> session handling action editor (Screen 3) and scroll to the bottom.

Figure 2: The added Burp extension is available under “After running the macro, invoke a Burp extension action handler.”

Defining the session-handling rule

To configure Burp to validate the session and invoke the extension code when the session is terminated, navigate to the session-handling action editor. (See Screen 2 below.)

During the automated scan, it is important to constantly monitor if the session is still valid. Any post authentication request can be used to track the session validity, as long as it returns uniquely different responses for valid and invalid sessions.

Go to the label “Make request to validate session” and select “Run macro.” Add the post authentication request (http://localhost:8080/test01/Start.jsp). After every fifth request, Burp will issue a request to start.jsp to check whether it has a valid session ID. If the application sends a 302 redirect, that indicates the session is invalid. Screen 2 below has the same configuration for this. (Note that this configuration is specific to application being tested.)

Figure 3: Configuring session-handling rules.

Invoking the extension based on session validity

In the sample application, the 302 redirect response for the request http://localhost:8080/test01/Start.jsp indicates the session has expired. At this time Burp needs to invoke our extension to perform the login operation so that automated scanning can resume.

Select “If session is invalid, perform the action below” under the label “Define behavior dependent on session validity” and specify the added extension “Login to demo App” for execution.

Figure 4: Further configuring of session-handling rules.

When the session has expired, the extension will trigger authentication and get a valid session ID. We can configure the rule to update the Burp cookie jar with the new session ID. This updated cookie jar can be applied to any Burp tool by defining the “Use cookies from Burp’s cookie jar” rule in the session-handling rules section. Refer to our post “Efficient Application Testing With Burp’s Cookie Jar” to learn more. This step is important to notify Burp tools such as Intruder and Repeater that a new session is available.

In the following section, we will verify whether our configuration works as expected.

Select any request from the proxy history and send it to Intruder. Right-click on the screen and scan the request by selecting “Actively scan defined insertion points.”

Figure 5: Sending the request to the scanner tool from Intruder.

Analyze the logs using Logger++

Recall that after every fifth request, a call is made to start.jsp. The successful response (200 OK) indicates the session is valid; Burp performs no further actions.

Figure 6: The request log using Logger++. Session validation is performed after every fifth request. (See requests 445, 451,457.)

After a certain time, start.jsp returns a 302 redirect (see below), which indicates that the session is invalid. Because we have a configured action for session invalidity, in the subsequent request Burp sends the login request to http://localhost:8080/test01/Signin.

Figure 7: The request log using Logger++. In this screenshot, we can see that when the session becomes invalid (see request 512), Burp automatically triggers the extension, which sends a login request (see request 515) to create a new session.


The technique we have described in this post can be used with any proxy-aware automated scanners, such as sqlmap, to perform an assessment. The code snippet provided can be used as a reference and can be customized to suit application requirements.


Leave a Comment

one × two =