Skip to main content

The Danger of Leaking Cookies in HTTP Response Bodies

Illustration of The Danger of Leaking Cookies in HTTP Response Bodies
Marcin Zięba

DESCRIPTION

According to the Microsoft Developer Network, HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script accessing the protected cookie (if the browser supports it).

If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.

~https://owasp.org/www-community/HttpOnly

In other words, the httpOnly flag secures application’s cookies by preventing a web browser from accessing cookies using JavaScript. In such case attacker who finds a Cross Site Scripting vulnerability will not be able to extract it by accessing document.cookie.

Even with httpOnly flag is in place when even one application’s module is poorly designed, attacker can achieve his/her objective and steal the cookie – if session cookie is reflected in HTTP response body an attacker can use a simple regex to retrieve desired string (cookie value) from response body and steal it like the flag never existed.

PROOF OF CONCEPT

The session cookie is named sessid and its secured by httpOnly flag.

The listing below presents a default JavaScript injection for a parameter found to be vulnerable to Cross Site Scripting:

The below screenshot confirms the vulnerability existence:

During the tests it was found out that one of application’s pages contains a session cookie in HTTP response body:

As mentioned before, such behavior can be leveraged to steal a session cookie even if httpOnly flag is in place.

Below there is a JavaScript code which:

  1. loads the page where session cookie is disclosed in the HTTP body,

  2. extracts the cookie value using the regex,

  3. sends extracted line to the attacker-controlled server.

Below there is a full link which can be directly passed to the victim in order to execute the attack:

Opening the link in a victim’s browser triggers 3 steps which leads to retrieving the cookie on the attacker-controlled server:

As demonstrated above, even when using the httpOnly flag, a web application can still be vulnerable to cookie stealing if there is a single point of failure. Based on that make sure that application never reveals session cookies in server’s responses.

Other Insights

Illustration of The Legacy of VB6 and the ClientSide Auth Bypass

The Legacy of VB6 and the ClientSide Auth Bypass

Robert Kruczek

In the modern era of microservices and single page applications, we sometimes forget the „old times” of desktop development. Recently, we had the pleasure of testing a legacy desktop application written in Visual Basic 6 (VB6). What started as a routine assessment ended with us dusting off our reverse engineering skills to write a classic “crack”, proving that client side logic is never to be trusted.

READ article
Illustration of Don’t forget to track your vendors’ security advisories

Don’t forget to track your vendors’ security advisories

Adam Borczyk

Every now and then a new critical vulnerability emerges, that has a worldwide impact and is easy to exploit. We’ve all seen Log4Shell, Spring4Shell… and now React2Shell. Despite media coverage, application teams often miss the importance of security patches. This particular vulnerability was found during a recent pentest in a production environment of our client, and it does not require any authentication. Global public disclosure of React2Shell happened just 5 weeks before this pentest.

READ article
A professional cybersecurity consultant ready to assist with your inquiry.

Any questions?

Happy to get a call or email
and help!