1. Home
  2. Docs
  3. Examples
  4. HTTP Basic Authentication

HTTP Basic Authentication

Web servers that utilize Basic Authentication as defined by  RFC 7617 expect clients to submit Base64-encoded credentials in the HTTP request header. On this page, we discuss implementing a test configuration that allows testing resources protected by HTTP Basic Authentication.

Prerequisites

This example assumes the reader is familiar with the basics of FuzzLabs, can navigate comfortably through the user interface, and has basic familiarity with the Unit and Flow templates and the related Designers. In the example, we will utilize Session Variables and, for a slightly more advanced implementation, we will have a brief look at the Response Processing Rules.

Message Template

HTTP Basic Authentication requires the client to provide the Base64-encoded credentials with each request. For each Unit template, we have to include the appropriate header in the HTTP request.

We start by creating a simple HTTP request template using the Unit template designer. Then, we make the appropriate session variables and adjust our template accordingly.

Creating a Request Template

Let’s create a simple HTTP request template that uses the GET method to fetch the file index.html. A screenshot of such a template is shown below. You can download the JSON object of the above example from HERE. Then, you can copy-paste the JSON object into the editor by clicking on View > View Code in the editor menu. However, if you are new to FuzzLabs, we recommend creating this template manually.

Defining Credential Variables

To authenticate successfully, we need a username and a password to transmit with each request in the appropriate HTTP header. If we hardcoded the credential in the template, we would have to update the template every time the credentials change. So instead, we are going to use Session Variables and later on the Reference primitive to avoid having to hardcode credentials and create configurable test cases.

First, let’s define these two variables by clicking View > Session Variables in the editor menu.

Using the form appearing at the bottom of the page, we create the two variables. The best practice is to pick a name and set a description that is both meaningful and informative. Getting the name right is especially important as we will need it later.

Authorization Header

We have to include the Authorization header in our HTTP request to transmit the credentials. An example of the header is shown below.

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

The Base64-encoded part of the Authorization header’s value contains the credentials. We will discuss how to create this in a minute. But, first, let’s create the header without the credentials.

As can be seen, the last item before the terminating newline (0x0d, 0x0a bytes) in the Authorization header is a Group primitive named “BasicAuth.Credentials”. This Group is the placeholder for the credentials.

As mentioned previously, the credentials are Base-64 encoded. The format of the credentials before the encoding is ${username}:${password}. Therefore, we have to concatenate the username and the password using a colon (:) then Base64 encode the resulting string. To do that, we will:

  1. Add three new primitives as the children of the “BasicAuth.Credentials” Group, these are:
    1. A Reference primitive that refers to the value of the “Username” session variable
    2. A Delimiter primitive with the value set to the colon (:) to separate the username from the password
        1. Another Reference primitive that refers to the value of the “Password” session variable
  2. Apply Base64 encoding on the “BasicAuth.Credentials” Group using a Transform

The video below guides us through this process.

Basic Flow Implementation

Now that the Unit template is ready. It is time to set up a basic Flow template to tell FuzzLabs what actions to perform during the test. The video below shows how to create a simple test flow. First, we add three Actions to tell FuzzLabs to connect to the target, send a test case and finally, disconnect from the target. Next, we drag and drop our Unit template created previously onto the Send action so that FuzzLabs knows which Unit template to use to generate test cases.

Job Configuration with Credentials

The final step is to create a Job based on the Flow template created earlier. For this, we select our Flow template on the Templates page, then choose File > Create Job from the menu. When adding a new target to test during Job configuration, we can see that the Session Variables configuration section allows configuring the Username and Password we defined for the HTTP Basic Authentication. Even better, we can define a different username and password to be used for each target added to the Job configuration.

The short video below guides us through the process.

Improvements

We have successfully created a test configuration that allows testing resources protected by HTTP Basic Authentication. However, we did not account for a potential error: Authentication failure. We may have provided invalid credentials, preventing the test cases from being processed by the application under test. If FuzzLabs was not aware that the authentication has failed, it would keep generating test cases, which ultimately would be just a waste of time. We can improve our test configuration with the help of Response Processing Rules to prevent this from happening.

Environment Setup

We have created a Docker container with Nginx deployed and HTTP basic authentication enabled to make it easier to try out this example. You can download it from container-nginx-http-auth-basic.

Extract the archive and run the start.sh script to set up and start the container. Make sure to run the container on the same system you have your Engine deployed on as it exposes Nginx port 8180 on localhost only. Alternatively, please edit the start.sh script to expose the port on all interfaces.

The basic authentication credentials match what we have configured as default values for the Session Variables in the Unit template earlier.

Response Processing Rule

Open the previously created Flow template. As the first step, we will implement the two Comparables we need for our Response Processing Rule (RPR), select View > Comparables from the editor menu. The screenshot below shows an example of these Comparables.

As the regular expression used for the “Response Code” comparable is not fully visible, we include it below for your reference.

^HTTP/1\.[0-9]{1}\s([0-9]{3})\s.*

Next, open the RPR editor by selecting View > Processing Rules from the editor menu. Recreate the processing rule shown below.

Finally, to use the processing rule:

  1. Add a new Receive action to the Flow template following the Send action
  2. Open the Receive action and click on the + icon
  3. Assign the newly created RPR to the action and click the ADD button

If all went well, you should have something very similar to what is shown below.

Run Tests

Update the previously created Job Configuration with the target details and make sure the credentials are correct. Then, run a test and observe the test run. Feel free to stop and delete the test at any time, as it will not yield any findings.

Update the Job Configuration and, this time, provide invalid credentials. Then, run a test with the updated Job Configuration and observe the difference.

As can be seen on the screenshot below, this time, the test run got terminated as FuzzLabs detected that the authentication has failed, thanks to the response processing rule configured.

Was this article helpful to you? Yes No