Introducing Header Injection and URL Redirection

Consider some simple PHP code:

The preceding PHP file, once clicked, takes us to the https://sanjib.site.

Now, consider a case when a developer writes the same code this way:

In the preceding code, the user input is displayed on the header. One can easily manipulate this query string and redirect the location to some malicious sites, which an attacker can control.

Modifying the untrusted URL input to a malicious site, an attacker may successfully launch an attack stealing user credentials. Therefore, as a penetration tester, you need to test whether your client’s application has URL redirection vulnerabilities or not: whether that application leads user input into the target of a redirection in an unsafe way or not.

If the application has such vulnerabilities, the attacker can construct a URL within the application that causes a redirection to a malicious site and users, even if verified, cannot notice the subsequent redirection to another site.

We can try to understand the whole situation better by using a diagram (Figure 5-1).

When the URL is being explicitly declared in the code, it is safe (code 5.1). We can also consider Java code written in a safe way:

If you change this code to this way, it becomes vulnerable, because it receives the URL from the parameter named url (GET or POST) and redirects to that URL:

This vulnerability could be turned into a phishing attack by redirecting users to a malicious site by injecting the header. How it can be done we will see in the next section. At this point we should also remember the importance of OAth 2.0 access token leak. Why is it important? First, web applications usually want to use the service of another application; instead of using your password, they should use a protocol called OAuth. However, you should be careful about how another application stores or uses your data. Suppose for logging into another application you use your Facebook credentials. Open access authorization sometimes invites danger when token injection takes place.

Cross-Site Scripting Through Header Injection

So far we have learned that open redirections or URL redirections are potential vulnerabilities for any web application. Under the influence of untrusted user input data, any web application may fall into this phishing trap. In such cases, a redirection is performed to a location specified in user-supplied data.

We will demonstrate how we can use Burp Suite’s Proxy, Spider, and Repeater tools to check for open redirections in a moment. We are going to test an intentionally vulnerable web application ZAP-WAVE; it is designed for evaluating security tools.

This application is available in the OWASP broken web application project. We have already installed it in our virtual lab. First, run the "owaspbwa" application. In that application, you will get a link to ZAP-WAVE. Click and open it (Figure 5-2).

We have already configured our Burp Suite. Let us ensure that the Burp Proxy intercept is on. Now we visit the ZAP-WAVE page and the traffic is reflected on our Burp Proxy (Figure 5-3).

We get this output on our Burp screen:

Let me clarify how the request header is working here. On the top, there is HOST. Here, it is 192.168.2.3. It is the desired host that handles the request. Next comes the part of acceptance. The Accept part specifies that all MIME types are accepted by the client; for web services, the JSON or XML outputs are specified. The next step handles the cookie. It is a very important part of any request. The browser passes the cookie data to the server.

In Figure 5-3 we can see the Proxy ➤ Intercept tab shows the intercepted request. Now we will right-click our mouse and send this request to the Spider tool. You don’t have to select any item or line, you can click anywhere on the context and choose the Spider tool (Figure 5-4).

In the pop-up menu bar it will ask to add this term to the scope of your Spider tool and once you do it, it will add the request to the scope.

The Spider tool spiders the web application. The Burp Target tool including the Spider tool contains detailed information about your target applications and lets you drive the process of testing for vulnerabilities. Here we are doing the same thing. Burp Proxy is an intercepting web proxy that operates as a man-in-the-middle between the end browser and the target web application.

It will also populate the Site Map tool (Figure 5-5).

If you go to the Target tab and click “Site map,” you will see all the spidered view of the ZAP-WAVE application now.

However, we will use our site map filter here for one particular purpose. We will search for any redirection codes or forwards used by the Site Map. When you click the Filter bar to bring up the options menu, you will find on your right-hand side “Filter by status code” options, under which you will select only 3xx status codes. These status codes indicate that a redirection is needed to fulfill a request (Figure 5-6).

In the site map table, you will now find only the HTTP requests of the 3xx class (Figure 5-7).

As you see, there are two HTTP requests that belong to the 3xx class. We can now manually step through these requests to find a URL where we have a request parameter.

The output of the first URL looks like this:

Discovering Header Injection and URL Redirection Vulnerabilities

So far we have got two HTTP requests; between them, the first one (code 5.6) does not show any request parameter. Let us check the second (Figure 5-8).

Let us show the output so that you can see for yourself whether it shows any request parameter or not.

Through that redir request parameter, we can test our URL redirection technique using Burp Suite’s Repeater tool. We are going to inject the header and show that this application has URL redirection vulnerabilities.

In other words, we can change the parameter and try to investigate whether URL redirection is possible or not. To investigate any further, we should send it to the Repeater tool. Just right-click on the request in the Site map table and click “Send to Repeater” (Figure 5-9).

Let us first click the “Go” button to test whether the URL redirection works or not. We find that the response is OK (Figure 5-10).

Watch the output on the right hand side:

Now, on our left side, we will try to change the value of the URL parameter to an external URL parameter such as https://sanjib.site. You can choose any different domain.

First we will click “Go” to test if the URL is altered or not. It is altered, as our response output changes to this:

In Figure 5-11 we can see the raw response.

Now, we can open an incognito tab in our browser and paste the redirect URL (http://192.168.2.3/zapwave/active/redirect/redirect-url-basic.jsp?redir=https://sanjib.site) to test whether it opens up or not.

Since the URL redirection occurs successfully, as a proof of concept (PoC) we can write this in our report: “The redirector of this web application is open and it has vulnerabilities.”

Finally, the Site map tab of the Burp Suite also shows that we have successfully done the header injection and the URL redirection occurs (Figure 5-13).

And in the raw request we see this output: