Cookie Flags on Purpose

Your server ends its sessions now. The cookie that carries the id has not changed since HTTP with Python. A login still answers with this header value, where the id is 22 characters:

session=<id>; HttpOnly; Max-Age=3600; Path=/

Those attributes leave a browser free to do three things with the cookie. It may send it over plain HTTP, where anyone on the network path can read it. It may send it along with a form that a page on another site posts to the reading list. And it may accept a second cookie of the same name from a neighboring host and send that one too, which was the first route of Lesson 1.

Four instructions

A cookie attribute is an instruction to the browser that stores the cookie. This lesson sets four of them on purpose.

“Another site” has a precise meaning. A site is the scheme plus the registrable domain, the part of a host name that someone registered, here reading.example. So https://notes.reading.example and https://reading.example are the same site. That is why SameSite does nothing about the neighboring host of Lesson 1. The prefix in the next section does, and Chapter 8 takes up requests from the same site.

SameSite has two other values. Strict would also keep the cookie back when a reader follows a link to the list from another site, so they would arrive logged out. This service does not choose it. None asks for no protection at all.

The __Host- prefix

The cookie’s name can carry a rule too. A browser refuses to store a cookie whose name starts with __Host- unless the cookie has Secure, has Path=/, has no Domain, and arrived over HTTPS. A cookie that a page on notes.reading.example sets for the whole domain needs a Domain attribute, so it can never be called __Host-session. No neighboring host can plant a cookie of that name for the reading list.

The server does its part by reading only that name. Once SESSION_COOKIE is "__Host-session", a cookie called session means nothing to session_id_from, whoever planted it.

An exception retired

HTTP with Python left Secure off, in Lesson 7.1, because its server spoke plain HTTP on your own computer. That exception ends here. A service that will run behind HTTPS always sets it.

pl_sec.py still talks plain HTTP to your server on 127.0.0.1. Over plain HTTP to any other machine, a browser holds a Secure cookie back. Some browsers make an exception for a server on your own computer, which is for development only. The tool is not a browser: it builds the Cookie header by hand, and from this lesson on it says so right under its first line:

pl_sec sends the __Host-session cookie by hand; a browser would not send it over plain HTTP

Who obeys

The server only writes instructions. A test can check that they are written. Whether they are followed is up to the browser, and no browser checks these flags anywhere on this site. A program that is not a browser can send any Cookie header it likes, over any connection. Chapter 8 writes the part of a browser that decides when a cookie is sent.

The cookie you are aiming for

With max_age defaulting to ABSOLUTE_LIMIT, a browser forgets the cookie when the server’s absolute limit would end the session anyway. Once the flags are set, a login answers with:

__Host-session=<id>; HttpOnly; Max-Age=28800; Path=/; SameSite=Lax; Secure

SimpleCookie writes the attributes in alphabetical order, whatever order you set them in, and a flag such as Secure is a bare word with no value.

import http.cookies

cookie = http.cookies.SimpleCookie()
cookie["__Host-session"] = "abc"
cookie["__Host-session"]["path"] = "/"
cookie["__Host-session"]["secure"] = True
cookie["__Host-session"]["samesite"] = "Lax"
print(cookie["__Host-session"].OutputString())

Logout needs no change. The cookie that ends a session comes from the same function, session_cookie("", max_age=0), so it has the same name and flags. It has to: a browser ignores a __Host- cookie that lacks them, and that includes the one that deletes.

Write the attack first

The attack is a browser doing what the bare cookie allows, so the test reads the instructions. Log in as ana through reading_server.handle(...), assert status 200, and take the text in response["headers"]["set-cookie"]. Assert that it starts with __Host-session=, that Secure, HttpOnly, SameSite=Lax, and Path=/ are in it, and that Domain is not. Run python -m pytest -q: it ends with 1 failed, 10 passed.

Your task

1. In tests/test_attacks.py, write test_attack_session_cookie_carries_its_flags() and watch it fail.

2. Set SESSION_COOKIE = "__Host-session".

3. In session_cookie, set secure to True and samesite to "Lax", the same way httponly and path are set, and change the default max_age to ABSOLUTE_LIMIT. Set no domain.

4. In row F4 of SECURITY.md, name your test and set the status to closed in 4.4.

Run python -m pytest -q again. It ends with 11 passed. Your two earlier tests of this chapter needed no change, because steps.cookie_pair never spells the cookie’s name.

Then press Check my work. The three repairs of this chapter are in place. The next lesson puts them together as one policy and deals with the sessions nobody comes back to.