Hello everyone, this article will show how the threat hunting process that earned me the title of Honored as DoD Researcher of the Month by the Department of Defense Cyber Crime Center (DC3) took place, and how the exploitation process was carried out through manipulation of the HTTP Location header.
This is link:
Difinition(Location header — HTTP | MDN):
The HTTP Location response header indicates the URL to redirect a page to. It only provides a meaning when served with a redirection response or a 201 Created status response.3XX
While reviewing the application I was testing, I decided to analyze the login page — a PHP page protected by Cloudflare (WAF) that used the Location header to redirect users to the intended directory when the password was correct. If the password was incorrect, the application checked the cookie and automatically redirected to index.php.
Understanding the page behavior, I started testing for open redirect vulnerabilities using previously mapped parameters. However, I always ended up on the same screen because the page redirected me back to the login form.
I then tested for path traversal, since the application kept redirecting, to determine the redirection depth limit. I tried the following paths:
/application_name/../../— adding two levels (..) caused the application to redirect again toindex.php./application_name/../../../— adding one more level caused Cloudflare to return Bad Request.
I reasoned that if the application accepts only two injected characters and returns to index.php, I could inject two empty parameters "/../../" and put a payload inside those empty parameters. I used the payload:
<button popovertarget=x>Click me</button><img onbeforetoggle=alert(1) popover id=x>XSSAfter injecting this and appending two more path segments, the payload was reflected in the page and unexpected functionality appeared in the application — indicating an injection/exposure of application context.
Payload injected successfully.
After that:😎
