EAR (Execute After Redirect) Vulnerability
Execution After Redirect (EAR) is an attack where an attacker ignores redirects and retrieves sensitive content intended for authenticated users.
Last updated
Execution After Redirect (EAR) is an attack where an attacker ignores redirects and retrieves sensitive content intended for authenticated users.
Last updated
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.
You can see this code to get more understand
This basic PHP code redirects every user who doesn’t have their IP inside a whitelist straight to an error page, but if said user is part of the whitelist the same page will display what’s supposed to be restricted content, without performing any actual session or identity check. This means that if a browser was to ignore the redirect, any user would be able to access that content without authorization.
It’s not too common and it derives from bad programming practices that any good developer should be aware of, mostly the lack of proper session management, but it definitely is a real flaw you may run into in the wild.
From the Previse machine from HackTheBox we will view how to exploit it , First let's visit our website
when u visit the http://10.10.11.104 it's redirects u to http://10.10.11.104/login.php so let's see what happens under the hood
When u catch this request and send it to the repeater u can see The response shows a 302 redirect. But the response also includes HTML content with a body tag u can this more clearer with Curl
So how can we expoit it , we can catch the requeset with the 302 Found code and replace it with 200 OK code
Send a regular request and intercept the response to this request
Then u will get the response with 302 NotFound code
Change the 302 Found with 200 Found , Then check ur browser
Now ur a privileged user
