Unit4sec

Web Application Security: Cookie Properties

Ahmet Can Karaağaçlı

Table of Contents

Contents

unit4sec.com | Cookie Properties

01

INTRODUCTION

In my previous blog, I talked about CORS and SOP concepts and explained how cookies work. I also mentioned the cookie mechanism in earlier posts related to web browsers. In this blog, I'll start by summarizing some details about cookies based on RFC-6265. Then, I'll note down some simple explanations about security headers that we encounter while testing web applications.

The cookie features we aim to discuss in this article are:

• expire
  
• max-age
  
• path
  
• domain
  
• secure
  
• httponly
  
• samesite
  

Cookies help manage user sessions and application states in web apps. They act like small databases stored by servers in browsers. They verify our identity with every request sent. They have certain settings that control how they work on the user's side.

Let's talk about these settings in simple terms. Every cookie has a name, which we're familiar with using the 'name' parameter. For example, sessionid=6161...

unit4sec.com | Cookie Properties

02

Expire

Suppose we log into an application. Depending on the session setup, it will expire after some time. (The server configures this, but the browser's stored cookie info can be deleted to show this to the user.) There's a cookie feature called 'expire' that decides when the browser should delete this cookie info.

We can set the 'Expire' value as follows:

Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>

Example: Set-Cookie: id=xx; Expires=Fri, 5 Oct 2021 11:10:00 GMT;

Similarly, 'max-age' can be used to specify the lifespan of a cookie. In the 'max-age' format, the time duration for which the cookie should persist is stated in seconds.

Set-Cookie: <cookie-name>=<cookie-value>; max-age=<seconds>

Example: Set-Cookie: id=xx; Expires=max-age=61

When both 'Expire' and 'max-age' are set, in modern browsers, 'max-age' will override 'Expire' since the 'Expire' feature has been deprecated in favor of 'max-age'.

"

unit4sec.com | Cookie Properties

03

path

Secondly, the 'path' parameter. Depending on the application's design, you might want to develop different web applications within different directories and set different cookies in these directories. In this case, as a developer, the 'path' parameter will be useful.

Let's imagine you've created two separate applications, such as example.com/app1 and example.com/app2, under the same domain but in different directories. If you set the 'path' value as /app1 for a cookie, it will be transmitted with requests made to all directories under /app1/.../.

Set-Cookie: <cookie-name>=<cookie-value>; path=/<path>

Example: Set-Cookie: id=xx; Expires=max-age=61; path=/app1

Speaking of different applications, let's say we've created our applications not in directories but as subdomains. We want to set different cookies for app1.example.com and app2.example.com. In this case, the cookie attribute we'd use is 'domain.'

unit4sec.com | Cookie Properties

04

domain

Speaking of different applications, let's assume we've created our applications not in directories but as subdomains. We want to set different cookies for app1.example.com and app2.example.com. In this case, the cookie attribute we'd use is 'domain.'

Set-Cookie: <cookie-name>=<cookie-value>; domain=<domain>

Example: Set-Cookie: id=xx; Expires=max-age=61; domain=app1.example.com

Considering the example above, it's important to note that with the mentioned example, the cookie information will be transmitted with requests to all subdomains of app1.example.com.

unit4sec.com | Cookie Properties

05

Secure Flag

In short, if the 'secure' attribute is marked for a cookie in your server settings, the browser will only transmit that particular cookie in HTTPS requests. If the request is made over HTTP, the browser will withhold sending this cookie to the site.

"

Httponly

Additionally, one of the most effective features, in my opinion, is the 'httponly' attribute. One of the situations where XSS attacks have the highest impact is in account takeover scenarios. The nature of this vulnerability involves running JavaScript on the client side. JavaScript access means access to cookies (document.cookie), the ability to send requests via AJAX, and if no additional security measures are taken for session management (such as IP-based controls, etc.), it could result in seizing control of the victim's account using the obtained cookie information.

With the 'httponly' attribute, the browser prevents JavaScript from accessing the cookie information marked as 'httponly'. This way, even if there's an XSS vulnerability in the application, it stops the reading and consequently theft of cookie data.

unit4sec.com | Cookie Properties

07

Samesite

Another common weakness in web application security is CSRF (Cross-Site Request Forgery). In one of the previous articles, we briefly discussed how browsers access cookie information while forwarding requests. Although, according to the Same Origin Policy, JavaScript from Site A cannot access cookies from Site B, when you submit a form on Site A, the request sent to Site B will include the cookie information belonging to Site B fetched from the browser

Let's imagine browsing a site like malicious.com. This site contains a form that, when clicked on any link or button, sends a request to bank.com. Consider that this request triggers a sensitive function on bank.com, such as a money transfer function. When the browser sends a request to bank.com, if that site's cookie information is stored in the browser, it includes that cookie information in the request being sent. Consequently, an authenticated request goes to that site. However, you didn't intend to send this request, hence the term used for this attack: cross-site request forgery (CSRF), a form of inter-site request forgery.

unit4sec.com | Cookie Properties

08

At this point, alongside CSRF tokens, checking the origin/referer header, and other methods to prevent CSRF vulnerabilities, the 'SameSite' attribute comes into play. A cookie marked as 'SameSite' blocks requests/forms transmitted through the browser if they don't originate from the relevant domain. The 'SameSite' attribute for a cookie can be used with three different parameters:

• 'Strict': If set to 'Strict', the cookie value won't be transmitted with requests from outside the domain to which the cookie belongs, preventing authenticated requests.
  
• 'Lax': If marked as 'Lax', the cookie will only be included in 'GET' requests.
  
• 'None': If set as 'None', requests from other sites will transmit the cookie information as if the 'SameSite' attribute doesn't exist.
  

In modern browsers, the 'SameSite' attribute may be automatically added by default. It's advisable to ensure the server has set this attribute by testing with different browsers.

References

• https://datatracker.ietf.org/doc/html/rfc2616
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies?source=post_page-----8506c21eaa76
• https://www.netsparker.com.tr/blog/web-guvenligi/samesite-cookie-ayni-samesite-cookie-degil/
• https://www.netsparker.com.tr/blog/web-guvenligi/http-isleyisi-ve-guvenligi-acisindan-cookie-ve-session-yonetimi/
• https://owasp.org/www-community/controls/SecureCookieAttribute
  

unit4sec.com | Cookie Properties

09