Execution After Redirect (EAR) is an attack where an attacker ignores redirects and retrieves sensitive content intended for authenticated users. A successful EAR exploit can lead to complete compromise of the application.

Consider a web application that has login functionality. Users who have an account can access content/features in this web application only by logging in. Unauthenticated users are redirected to the login page for them to first log in and get an authenticated session. This is one of the many situations where the Execute After Redirect or EAR vulnerability may creep in. An EAR vulnerability arises in an improper implementation of code where the developer assumes that the execution stops after redirect. However, that is not true, and the remaining part of the page also gets executed.

The following code snippet shows such an implementation:

If you have a sharp eye, you might have noticed it. No problem if you did not catch it. Let me show it to you. The PHP code checks if the user is authenticated or not. If not, it will redirect them to the login page located at /login. But there’s no one telling the program to stop executing all the code after the redirect. So, all the code that should run only when a user has a valid session will also get executed. If we use a proxy tool such as BurpSuite or ZAP (yeah, I like both of them), we can modify the response of 302 Found redirect into a 200 OKresponse. We will get into that part later. Let’s first fix the code real quick.

By simply invoking the die() function, we are able to stop the execution of the code. The remaining code will not execute now.

Now comes the fun part, aye? The website present on the HTB box named Previse (which is now retired) is vulnerable to this EAR vulnerability.
I first fuzzed the file names using a tool called dirbuster. Most of these files are responding with a 302 Found status code. One thing to notice here is the value of the Content-Length header in the Response is quite high which is not usually the case with redirect responses.

If we visit any such page (as an unauthenticated user) using tools such as cURL that do not follow the redirect, we can clearly see the contents that should only be visible to an authenticated user.

It can allow attackers to steal private sensitive data as well as perform actions to which they are not authorized.

We can use BurpSuite’s inbuilt match and replace feature to automatically convert the 302 redirects to 200 OK responses. But do keep in mind that it may conflict with some pages and act weird.