web analytics

Understanding HTTP Cookies

Options

codeling 1524 - 6369
@2021-01-24 14:29:16

An HTTP cookie is a small piece of data that a server sends to the user's web browser. The browser may store it and send it back with later requests to the same server. 

Cookies are mainly used for three purposes:

  • Session management: Logins, shopping carts, game scores, or anything else the server should remember
  • Personalization: User preferences, themes, and other settings
  • Tracking: Recording and analyzing user behavior

Cookies are associated with a Web site, not with a specific page, so the browser and server will exchange cookie information no matter what page the user requests from your site. As the user visits different sites, each site might send a cookie to the user's browser as well; the browser stores all the cookies separately.

Most browsers support cookies of up to 4096 bytes. Because of this small limit, cookies are best used to store small amounts of data, or better yet, an identifier such as a user ID. The user ID can then be used to identify the user and read user information from a database or other data store.

Browsers also impose limitations on how many cookies your site can store on the user's computer. Most browsers allow only 20 cookies per site; if you try to store more, the oldest cookies are discarded. Some browsers also put an absolute limit, usually 300, on the number of cookies they will accept from all sites combined.

@2021-01-24 16:57:49

Creating HTTP Cookies

After receiving an HTTP request, a server can send one or more Set-Cookie headers with the response. The cookie is usually stored by the browser, and then the cookie is sent with requests made to the same server inside a Cookie HTTP header. An expiration date or duration can be specified, after which the cookie is no longer sent. Additional restrictions to a specific domain and path can be set, limiting where the cookie is sent. 

The Set-Cookie HTTP response header sends cookies from the server to the user agent. A simple cookie is set like this:

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

This shows the server sending headers to tell the client to store a pair of cookies:

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

Then, with every subsequent request to the server, the browser sends back all previously stored cookies to the server using the Cookie header.

GET /sample_page.html HTTP/2.0
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

The lifetime of a cookie can be defined in two ways:

  • Session cookies are deleted when the current session ends. The browser defines when the "current session" ends, and some browsers use session restoring when restarting, which can cause session cookies to last indefinitely long.
  • Permanent cookies are deleted at a date specified by the Expires attribute, or after a period of time specified by the Max-Age attribute.

For example:

Set-Cookie: id=a3fWa; Expires=Thu, 31 Oct 2021 07:28:00 GMT;

Set-Cookie: id=a3fWa; Max-Age=0

When an Expires date is set, the time and date are relative to the client the cookie is being set on, not the server.

Max-Age specifies the number of seconds until the cookie expires. A zero or negative number will expire the cookie immediately.

If both Expires and Max-Age are set, Max-Age has precedence.

The following cookie is a session cookie, it was removed when the user shut down the system.

Set-Cookie: sessionId=38afes7a8

If your site authenticates users, it should regenerate and resend session cookies, even ones that already exist, whenever the user authenticates. This technique helps prevent session fixation attacks, where a third party can reuse a user's session.

Restrict access to cookies

There are a couple of ways to ensure that cookies are sent securely and are not accessed by unintended parties or scripts: the Secure attribute and the HttpOnly attribute.

A cookie with the Secure attribute is sent to the server only with an encrypted request over the HTTPS protocol, never with unsecured HTTP (except on localhost), and therefore can't easily be accessed by a man-in-the-middle attacker. Insecure sites (with http: in the URL) can't set cookies with the Secure attribute. However, do not assume that Secure prevents all access to sensitive information in cookies; for example, it can be read and modified by someone with access to the client's hard disk (or JavaScript if the HttpOnly attribute is not set).

A cookie with the HttpOnly attribute is inaccessible to the JavaScript Document.cookie API; it is sent only to the server. For example, cookies that persist server-side sessions don't need to be available to JavaScript, and should have the HttpOnly attribute. This precaution helps mitigate cross-site scripting (XSS) attacks.

Here is an example:

Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly

Define where cookies are sent

The Domain and Path attributes define the scope of the cookiewhat URLs the cookies should be sent to.

The Domain attribute specifies which hosts are allowed to receive the cookie. If unspecified, it defaults to the same host that set the cookie, excluding subdomains. If Domain is specified, then subdomains are always included. Therefore, specifying Domain is less restrictive than omitting it. However, it can be helpful when subdomains need to share information about a user.

For example, if Domain=example.org is set, then cookies are available on subdomains like developer.example.org.

The Path attribute indicates a URL path that must exist in the requested URL in order to send the Cookie header. The %x2F ("/") character is considered a directory separator, and subdirectories match as well.

For example, if Path=/docs is set, these paths match:

  • /docs
  • /docs/Web/
  • /docs/Web/HTTP

The SameSite attribute lets servers specify whether/when cookies are sent with cross-origin requests (where Site is defined by the registrable domain), which provides some protection against cross-site request forgery attacks (CSRF).

It takes three possible values: StrictLax, and None.

  • Strict specifies the cookie is sent only to the same site as the one that originated it; 
  • Lax is similar with Strict, except that cookies are sent when the user navigates to the cookie's origin site, for example, by following a link from an external site. But the cookie is not sent on cross-site requests, such as calls to load images or frames;
  • None specifies that cookies are sent on both originating and cross-site requests, but only in secure contexts (i.e. if SameSite=None then the Secure attribute must also be set).

If no SameSite attribute is set then the cookie is treated as Lax.

Here is an example:

Set-Cookie: mykey=myvalue; SameSite=Strict

Note: Standard related to SameSite recently changed:

  • SameSite=Lax is the new default if SameSite is not specified. Previously the default was that cookies were sent for all requests.

  • Cookies with SameSite=None must now also specify the Secure attribute (they require a secure context).

@2021-01-24 21:56:53

These are general rules on when to use StrictLax or Noneas values for SameSite:

  • Lax: the choice for cookies that are always needed in order to correctly display the site. As we saw earlier, you should use this value for any cookie needed when the user arrives at a top-level URL following a link from another site.
  • Strict : useful for cookies related do actions taken by the user and not affecting the display of the site.
  • None: the choice when we need cookies available to all our application’s URLs (top-level or not) in third-party contexts. Example: Youtube’s login cookies are set with this attribute in order to be sent whenever you see a video embedded in any website different than youtube itself.

Comments

You must Sign In to comment on this topic.


© 2021 Digcode.com