Web Application Vulnerability Scanner

Introduction & Abstract This short report describes the design and implementation of the Web Application scanner that I wrote to discover the XSS and SQL injection vulnerabilities in the Blab Hackathon website. The code is a Console application written in C#. As inputs, it receives a http raw request file and a parameter token that marks the website input parameter to be tested. The scanner uses SQL injection and XSS payloads in that input parameter, and evaluates to see if the website is vulnerable. The algorithm is designed to work for error-based/taint-style-based vulnerabilities where a user input from a source flows to a sink, and is not sanitized. The implementation follows an extensible pattern and allows easy extension to other similar vulnerabilities.

Algorithm

The implementation of both vulnerabilities follows a similar design where these high-level steps are performed:

1. Generation of a custom payload based on the attack
2. Injection of the payload into the request
3. Delivery of the request to the target
4. Evaluation of the response based on expected indicators of the vulnerability Step (1) for both attacks include the generation of a random string that contains dangerous characters that make the attack work. Step (2) is the replacement of a marked placeholder in a raw request provided by the user with the payload generated in step (1). Step (3) creates a http request based on the user provided user http raw request, and delivers it to the web server. Step (4) received the response and then searches for patterns that indicate the presence of vulnerabilities in the web application.

Object Oriented Design

The above algorithm is abstracted in an interface called IAttack. This interface has one method called run_attack that will be implemented by the concrete instances. The only implementation of this interface is the Attack class that works for both the XSS and the SQL injection attacks:

class Attack : IAttack
{
    public IGenPayload PayloadGenerator;
    public string attack_name = "SQL Injection";
    public string attack_str;
    public Request Request;
    public string Response_attack;
    public Regex[] Errors;
    public Attack(string atk_name, IGenPayload pGenerator, Request request, IErrorLoader errorLoader)
    {
        this.PayloadGenerator = pGenerator;
        this.attack_name = atk_name;

        this.Request = request;
        this.attack_str = PayloadGenerator.GeneratePayload();
        this.Response_attack = "";
        this.Errors = errorLoader.load_errors();
    }

… } The constructor receives four parameters that allows easy application of this class for similar types of attacks. The first parameter is the name that will be used in the messages. The second parameter is the payload generator for the attack that has “GeneratePayload” function. The third parameter is the request object that is created based on a user provided raw request and has one method that allows the replacement of the parameter value. Finally, the fourth parameter provides the patterns that should be sought in the response for evaluation of whether the website is vulnerable. The two interfaces mentioned above are implemented based on the nature of XSS and SQL Injection attacks.

XSS Implementation

For the XSS implementation, the IGenPayload and the IErrorLoader are implemented in XSSPayloadGenerator and XSSErrors respectively. The former provides a random string containing the “ "<"">"” string. This is essentially an html tag opened and closed. Two other strings of length 6 are combined with this string randomly to generate the payload. The latter provides a regular expression that tolerates the escape of each of the dangerous characters: ("\\<\\\\"\\"\\*>".

SQL Injection implementation

Similar to the above, the SQL Injection implementation provides the concrete implementations in the SQLPayload and the XMLErrorLoader. The former generates a string definitely containing '"' and ''' and optionally containing [')', '(', ',', '.'] characters. The latter loads MS SQL server errors from an XML resource file. The user has the option of providing their own list of the errors in the regex format. Payload Delivery The payload will be embedded in a raw http request provided by the user. This is a deliberate design and provides advantages over just supporting GET and POST parameters. Firstly, many web applications require more than just one parameter for the correct handling, and sometimes they need hidden fields or some values in the header. One way to support this is to let the user set each value through an input parameter that is not user friendly and exhausting. Another way is the current solution that asks for a raw request that the web server already responded to. This request could be a captured request by Burp Suite and then curated in the intruder tab. Secondly, a comprehensive solution should support every possible source from the user input. This means an input could come from a header value or anywhere in the raw request. That is why the scanner asks for a raw request that marks the parameter to be tested, and then injects the payload into the raw request and delivers it to the target.

Response Evaluation

The final step is the evaluation of the response to check whether pattern indicating the vulnerability exists. The Attack class implementation has the following generic implementation:

    public bool validate_attack()
    {
        if (this.Response_attack == null)
        {
            Console.WriteLine("Can't Validate, there was not response!");
            return false;
        }
        foreach (Regex rx in this.Errors)
        {
            Match m = rx.Match(this.Response_attack);
            if (m.Success)
            {
                return true;
            }
        }
            return false;
    }      

Deployment and Environment setup

The executable can be invoked using the following command:

 MicroFocus_Scanner.exe [C:\PATH\TO\RAW_HTTP_REQUEST.txt] [REGEX-PARAMETER-TO-BE-TESTEd]

In the above command, the first parameter is the path to the raw request that would look like the following:

    POST http://10.0.2.15/[page-path/[PAGE] HTTP/1.1
    Host: 10.0.2.15
    Content-Length: 17
    Accept: */*
    X-Requested-With: XMLHttpRequest
    User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.74 Safari/537.36
    Content-Type: application/x-www-form-urlencoded
    Origin: http://10.0.2.15
    Referer: http://10.0.2.15/[XYZ]
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Cookie: pid=NmFmM2QwZjcyMGI2YjQxNTY2YzU1NzExOTFmMjg4ZDI4OGI5MDYxYg==; ASP.NET_SessionId=gcbggprqvxfbpda4yir205j1
    Connection: close

    messageText=$sssss$

The highlighted portion shows the parameter that will be tested. I used Burp Suite style syntax that is a word enclosed between $$ e.g. "$\w+$", however an optional syntax can be used and then provided as the second argument REGEX-PARAMETER-TO-BE-TESTEd for the program. There is an optional argument that is the path to an XML file containing regular expressions indicating SQL errors. This is for potentially supporting other DBMS like mysql etc.

Troubleshooting

A possible reason of failure could be databse being stopped that occurred a few times during experimentation too. In that case, the SQLLocalDB database should be started manually: sqllocaldb start .\SharedLocalDB