🏆Eindproject: Project: sessies die standhouden

Drie lessen deden drie reparaties: een nieuwe id bij de login, twee limieten, en een cookie met zijn vlaggen. Elk heeft een eigen test. Dit project leest ze als één beleid, voegt het ene stuk toe dat nog ontbreekt, en bewijst het hele beleid met vijf tests.

Het beleid

Elke rij op één na is af. Het gat zit in “Wanneer eindigt ze?”.

De sessie waar niemand naar terugkomt

current_session verwijdert een verlopen sessie als haar id gebruikt wordt. Een bezoeker die nooit terugkomt, gebruikt de id nooit, dus de vermelding blijft in state["sessions"] staan zo lang als de server draait. En POST /prefs geeft een sessie aan iedereen die erom vraagt.

sweep_sessions(state) dicht het gat. Hij leest de tijd uit state["clock"](), verwijdert elke sessie waarvoor session_expired(...) waar is, en geeft terug hoeveel hij er verwijderde. start_session roept hem als eerste aan, zodat de opslag wordt opgeruimd telkens als er een sessie begint.

Eén detail bepaalt hoe je hem schrijft. Een vermelding uit een dict verwijderen terwijl een for-lus dezelfde dict leest, geeft RuntimeError: dictionary changed size during iteration zodra de lus zijn volgende stap zet. Ruim dus in twee rondes op: verzamel eerst de verlopen id’s in een lijst, en verwijder ze daarna in een tweede lus over die lijst.

Mijlpalen

1. Een drukke sessie eindigt toch. Schrijf test_attack_busy_session_still_ends(). Het is de dief uit les 3, die elke tien minuten een verzoek stuurt. Log in onder een vaste klok die bij 1000 begint. Herhaal daarna: tel 600 op bij clock["now"], vraag GET /me, en controleer dat de gebruiker ana is. Ga door zolang de volgende stap nog onder de limiet blijft:

    while clock["now"] + 600 < 1000 + reading_server.ABSOLUTE_LIMIT:

Na de lus is de sessie 28200 seconden oud. Tel er 601 bij op, waarmee ze één seconde voorbij de limiet komt, vraag opnieuw, en controleer dat de gebruiker None is.

2. Uitloggen beëindigt de sessie op de server. Schrijf test_attack_logout_ends_the_session_on_the_server(). Log in met steps.login_cookie, vraag GET /me en controleer ana, stuur POST /logout met de cookie, vraag daarna GET /me met dezelfde cookie en controleer None. De aanvaller is iedereen die een kopie van de cookie van vóór het uitloggen bewaarde.

Voer python -m pytest -q uit. Het eindigt met 13 passed: beide nieuwe tests slagen de eerste keer. Les 3 bouwde de absolute limiet al, en HTTP with Python bouwde een uitlog die de sessie verwijdert. Deze twee tests bewijzen geen reparatie. Ze bewaken er een, en de quiz hieronder zegt waartegen.

3. Het opruimen. Schrijf sweep_sessions(state) en roep hem aan als eerste regel van start_session. Geen enkele test van jou verandert van kleur: python -m pytest -q eindigt nog steeds met 13 passed.

4. Bekijk het beleid. Voer het sessiescenario uit:

python pl_sec.py sessions

Het logt in, laat 31 minuten verstrijken op een eigen klok, vraagt opnieuw, logt daarna in en uit en probeert de oude cookie. De id’s zijn hier ingekort:

--- a session that is left alone ---
ana logs in                          POST /login   -> 200
set-cookie: __Host-session=<id>; HttpOnly; Max-Age=28800; Path=/; SameSite=Lax; Secure
ana asks who she is                  GET /me       -> 200  {"user": "ana", "page_size": 20}
(the clock moves 31 minutes)
the same cookie, 31 minutes later    GET /me       -> 200  {"user": null, "page_size": 20}
--- a session that is logged out ---
ana logs in again                    POST /login   -> 200
ana logs out                         POST /logout  -> 204
set-cookie: __Host-session=""; HttpOnly; Max-Age=0; Path=/; SameSite=Lax; Secure
the cookie from before the logout    GET /me       -> 200  {"user": null, "page_size": 20}
--- result ---
after 31 idle minutes the session answered as: nobody
after logout the old cookie answered as: nobody

5. De bevindingen. Controleer in SECURITY.md dat de rijen F3, F4 en F5 elk een test noemen en closed zeggen.

Wat nog open staat

Opruimen begrenst hoe lang een dode sessie in de opslag blijft. Het begrenst niet hoeveel levende bezoekerssessies een vreemde in een half uur kan openen: elke POST /prefs zonder cookie maakt er een, en geen ervan verloopt binnen 30 minuten. Een echte dienst voegt een maximum toe, of wacht met een sessie maken tot hij iets heeft wat het onthouden waard is. Het opruimen leest ook elke keer dat er een sessie begint de hele opslag, dus dezelfde vloed maakt elke POST /prefs trager. Deze cursus noemt beide problemen en bouwt geen van beide oplossingen.

Klik daarna op Check my work. Je sessies houden nu stand. De bearer-tokens niet: dat zijn nog steeds twee vaste strings in de broncode die nooit verlopen, en hoofdstuk 5 vervangt ze.