Web Application Development

Jakub Klinkovský

:: Czech Technical University in Prague
:: Faculty of Nuclear Sciences and Physical Engineering
:: Department of Software Engineering

Academic Year 2024-2025

Session, cookies and local storage

Session

Session is an abstract concept in computer science that represents a time-limited communication between an application (server) and a user (client). A session typically involves more than one message sent in each direction.

Examples:

  • user session in the operating system (login and logout)
  • browser session: saving open pages and settings when the browser is closed
  • on the web:
    • consciously created by the user (e.g. login and logout)
    • tracked by the application without the user's knowledge (e.g. an application tracking pages visited by a given user)

Session implementation in the network model

In the context of the OSI model, a session can be implemented at different levels:

  • transport layer (transport layer):
    • e.g. TCP session or TCP socket
  • relational layer (session layer):
  • application layer (application layer):
    • storing data to represent state and passing it during communication
    • allows the programmer to control the scope of the session, independently of the protocols used

How to add state to a web application?

The HTTP/1.0 protocol was designed to be stateless, i.e., all requests are independent of each other and do not carry any data associated with previous communication.

Ways to represent state independently of the HTTP protocol:

  • passing variables in the URL (communication using the GET method), e.g.
    <a href="/where/?key1=val1&key2=val2...">
  • passing hidden variables in forms (communication using the POST method):
    <input type="hidden" name="key1" value="val1">
    note: this is actually used in the Django framework: {% csrf_token %}

The third way uses the HTTP/1.1 protocol directly – cookies.

HTTP cookies (🍪 🍪 🍪)

Cookie represents small data that the browser stores on the client's disk according to server instructions and sends it in subsequent requests when communicating with the same server.

Cookies are used to store state information in an otherwise stateless HTTP protocol.

Usage:

  1. session management in the application (login, shopping cart, ...)
  2. personalization (user settings, appearance settings (theme), ...)
  3. user tracking (for recording and analyzing user behavior on the web)

How cookies work

The data contained in cookies is transferred using HTTP headers in requests and responses.

  1. After processing the initial request, the server sends a response with the
    Set-Cookie header. In general: Set-Cookie: <cookie-name>=<cookie-value>

    Example:

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

[page content]

  1. The client processes the response and stores the cookie data in its permanent storage.

  2. In each subsequent request, the client sends all previously set cookies using the Cookie header.

    Example:

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

The Set-Cookie header allows the server to specify a number of parameters for a given cookie:

E.g. Set-Cookie: <name>=<value>; Domain=<domain-value>; Secure; HttpOnly

  • The cookie name can contain any characters from ASCII, except for control characters (0-32 and 127, i.e., including all white characters) and the characters ()<>@,;:\"/[]?={}
  • The value can contain any characters from ASCII, except for control characters (0-32 and 127) and the characters ",;\. It can also be optionally enclosed in double quotes. Some implementations also perform URL-encoding.

A cookie can be accompanied by optional parameters that affect data processing in the browser.

Limiting the lifetime of cookies

Parameters Expires=<date> and Max-Age=<number>:

  • if neither is set, it is a session cookie (the lifetime depends on the browser settings – it may end after closing the window, or never)
  • the expiration date and time depend on the client's clock!
  • Max-Age takes precedence over Expires

Limiting access to cookies

  • Secure parameter:
    • data in the given cookie can only be transmitted using the HTTPS protocol
      (an application visited using HTTP cannot set a Secure cookie, and the client cannot send a Secure cookie to the server using HTTP)
    • limits man-in-the-middle attacks, but does not ensure 100% data security
  • HttpOnly parameter:
    • the cookie is not accessible from JavaScript (using the Document.cookie object)
    • but the cookie is sent in requests that originated in JavaScript code
    • limits cross-site scripting attacks

Setting the scope of cookies by domain

  • Domain parameter:
    • if not set, the data relates to exactly the same domain (not to subdomains)
    • if set, the data always relates to all subdomains
    • it cannot be set for a specific subdomain, but it can be set for a higher-level domain (e.g., an application on sub.example.org can set cookies for example.org)
    • multiple values cannot be set

Setting the scope of cookies by path

  • Path parameter:

    • specifies the path that must be present in the URL for the cookie to be sent
    • e.g. a cookie with the Path=/docs parameter:
      • relates to paths /docs, /docs/, /docs/Web/, /docs/Web/HTTP
      • does not relate to paths /, /docsets, /fr/docs

  • SameSite parameter:

    • values Strict, Lax, None
    • e.g. cookies with SameSite=Strict are sent only with requests that originate from a page on the same domain to which the cookie relates

Cookies and security

Due to how cookies work, the server has no way to verify whether the data comes from a secure source or not.

For example, some vulnerable application on a subdomain can set a cookie with the Domain parameter, making the data available on all other subdomains. Additionally, other subdomains can influence the given application using cookies.

To improve security, the standard allows setting cookies with prefixes:

  • __Host-* cookies are accepted by the browser only if they contain the Secure parameter, are received in a response via HTTPS, do not contain the Domain parameter, and the Path parameter is set to /.
  • __Secure-* cookies are accepted by the browser only if they contain the Secure parameter and are received in a response via HTTPS.

Cookies and privacy

Cookies relate to a given domain (subdomains) and scheme (HTTP or HTTPS). For a given page, however, multiple different cookies can be transferred:

  • first-party cookies: come from the same domain and scheme as the document URL
  • third-party cookies: come from other sources (e.g., multimedia data displayed on the given page), can be used for tracking (e.g., Google Analytics)

Browsers allow blocking all third-party cookies (see Firefox, Chrome). More detailed filtering of allowed cookies is possible, e.g., using extensions (or directly in the browser).

Another feature of most (all?) browsers is the incognito window, which is isolated from the normal window, and its data is automatically deleted after closing.

Firefox also allows isolating different pages using containers.

Cookies and regulations in EU (and California)

The use of cookies is subject to several global legislative regulations:

  • General Data Privacy Regulation (GDPR) – EU
  • ePrivacy Directive – EU
  • California Consumer Privacy Act

They apply to all websites that are accessible to users from the given areas. The requirements include:

  • informing users about the use of cookies on the given page
  • allowing users to disable the use of all or some cookies on the given page

In certain regions, there may be additional, local regulations.

Solution: display cookie statement and a so-called cookie banner.

Viewing cookies in the web browser

Firefox: Web Developer Tools (Ctrl+Shift+I), Storage tab.
Chrome: Developer tools (Ctrl+Shift+I), Application tab.

center

Modern technologies for storing data on the client side

Cookies were designed as a general data storage on the client side. However, this approach has several drawbacks, especially in terms of security and efficiency. Cookies are sent with every request, so their use can significantly slow down the entire application (especially for slow connections).

Modern APIs for storing data on the client side are:

Both technologies use JavaScript.

Cookies in the Django framework

Basic use of cookies:

  1. The HttpResponse object has the set_cookie() method
  2. The HttpRequest object has the COOKIES attribute (a dictionary containing all cookies)

Advanced use with authenticity verification:

  1. The HttpResponse object has the set_signed_cookie() method
  2. The HttpRequest object has the get_signed_cookie() method

Additionally, the HttpResponse object has the delete_cookie() method, which allows deleting a cookie from the client's storage.

Cookies and decorators

Decorators in the Python language are often useful for working with cookies.

...see interactive demo...

Further use of cookies in the Django framework

Django uses cookies in other parts of the framework:

See further lectures 😄

- allowing users to use our services without using cookies

## TODO: [session ID](https://en.wikipedia.org/wiki/Session_ID) - A session ID is typically granted to a visitor on their first visit to a site. It is different from a user ID in that sessions are typically short-lived (they expire after a preset time of inactivity which may be minutes or hours) and may become invalid after a certain goal has been met (for example, once the buyer has finalized their order, they cannot use the same session ID to add more items). [session (web analytics)](https://en.wikipedia.org/wiki/Session_(web_analytics))