Sessies die eindigen

Open SECURITY.md en lees rij F3, die je in hoofdstuk 1 schreef: een sessie-id die ooit gekopieerd is, blijft werken. De cookie zegt Max-Age=3600, en dat vraagt een client alleen om zijn kopie na een uur te vergeten. Een kopie van de id in een bestand vergeet niets, en state["sessions"] houdt de vermelding zo lang als de server draait. Deze les geeft een sessie een einde waarover de server beslist.

Twee limieten, voor twee aanvallers

Een sessie kan op twee manieren misbruikt worden, en elk vraagt een eigen limiet.

Een inactiviteitslimiet (idle limit) beëindigt een sessie die niemand gebruikt. Die dekt een laptop die open in een bibliotheek blijft staan en een cookie die op een gedeelde computer is achtergebleven: na 30 minuten zonder verzoek is de id niets meer waard.

Een absolute limiet beëindigt een sessie die iemand blijft gebruiken. Een dief die een id kopieerde, kan om de paar minuten een verzoek sturen, zodat de sessie nooit inactief is. Alleen haar leeftijd kan haar beëindigen: 8 uur na de login is de sessie voorbij, hoe druk ze ook was.

idle limit: more than 30 minutes without a request ends the session

login   request   request  31 minutes pass  request
  |--------|---------|-------------------------X  refused and removed

absolute limit: more than 8 hours after login the session ends,
however busy it is

login   one request every ten minutes ...   8 hours
  |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--X  refused and removed

De eerste regel laat een sessie zien met een gat van 31 minuten: het verzoek na het gat wordt geweigerd. De tweede laat een sessie zien zonder enig gat: het eerste verzoek na de grens van 8 uur wordt geweigerd. De twee getallen staan in reading_server.py als IDLE_LIMIT = 1800 en ABSOLUTE_LIMIT = 28800, in seconden. Het is de keuze van deze dienst, geen standaard. Een dienst die meer te beschermen heeft, kiest kortere limieten.

Tijd is een argument

Beide limieten vergelijken een opgeslagen tijd met de tijd van nu. De server haalt de tijd uit state["clock"], een functie die seconden als getal teruggeeft. sample_state() zet die op time.time, de echte klok. Je code roept state["clock"]() aan en roept nooit zelf time.time() aan. Dat is de geïnjecteerde tijd uit Python in Practice: omdat de klok via state binnenkomt, kan een test bepalen hoe laat het is.

helpers.fixed_clock(holder) geeft een klokfunctie terug die de tijd uit holder["now"] leest. De test bewaart de dict en verandert hem:

clock = {"now": 1000}
state["clock"] = helpers.fixed_clock(clock)

Na clock["now"] += 1801 zijn er voor de server dertig minuten en één seconde verstreken. Er wacht niets.

Schrijf eerst de aanval

De aanvaller doet hier niets slims. Hij gebruikt een id lang nadat de eigenaar ermee gestopt is. De tweede stap in tests/steps.py houdt de test kort: steps.login_cookie(state, user, password) logt in via handle() en geeft het cookiepaar terug, of None als de login geweigerd werd.

De test zet de vaste klok, logt in als ana, en vraagt GET /me met de cookie. Hij controleert dat de gebruiker ana is, en dat is de voorwaarde vooraf: de sessie werkt zolang ze vers is. Daarna telt hij reading_server.IDLE_LIMIT + 1 op bij clock["now"], vraagt opnieuw, en controleert dat de gebruiker None is.

Voer python -m pytest -q uit. De run eindigt met 1 failed, 9 passed, en de falende regel is weer AssertionError: assert 'ana' is None: een half uur later antwoordt de sessie nog steeds.

Eén pure vraag

Een sessie heeft twee tijdstempels nodig om voor zichzelf te antwoorden. start_session leest één keer now = state["clock"]() en slaat die op onder zowel created als last_seen.

session_expired(session, now) beantwoordt dan één vraag met twee aftrekkingen en twee vergelijkingen. now - session["last_seen"] is hoe lang de sessie inactief is geweest, en now - session["created"] is hoe oud ze is. De functie geeft True terug als het eerste meer is dan IDLE_LIMIT of het tweede meer dan ABSOLUTE_LIMIT. Ze leest geen klok en verandert niets, dus je kunt haar met willekeurige getallen uitproberen.

IDLE_LIMIT = 1800
ABSOLUTE_LIMIT = 28800
session = {"created": 1000, "last_seen": 29000}
now = 30000
idle = now - session["last_seen"] > IDLE_LIMIT
too_old = now - session["created"] > ABSOLUTE_LIMIT
print(idle, too_old)

Weigeren, verwijderen en één veld bijwerken

In current_session(request, state) treden de limieten in werking, omdat /me, /prefs en session_user er allemaal doorheen gaan. Geen enkele aanroeper kan de limieten overslaan. Nadat hij de sessie gevonden heeft, leest hij de tijd en vraagt hij het aan session_expired:

• Een verlopen sessie wordt uit state["sessions"] verwijderd, en de functie geeft None terug, precies alsof de cookie niets aanduidde. Verwijderen doet ertoe. Een sessie die geweigerd en bewaard wordt, staat nog in elke kopie van de state, en één veranderde regel zou haar terug kunnen brengen.

• Een levende sessie krijgt last_seen = now, en de functie geeft haar terug.

created verschuift nooit. Als een verzoek die waarde verschoof, zou de sessie na elk verzoek nieuw lijken en zou de absolute limiet nooit komen.

Er is nog één gebeurtenis die sessies zou moeten beëindigen: als een wachtwoord verandert, zou elke sessie van die gebruiker moeten eindigen. Deze dienst heeft geen route die een wachtwoord verandert, dus hier valt niets te bouwen.

Je opdracht

1. Schrijf in tests/test_attacks.py test_attack_idle_session_is_refused() en zie hem falen.

2. Sla in start_session de tijd op onder created en last_seen.

3. Schrijf session_expired(session, now).

4. Weiger en verwijder in current_session een verlopen sessie, en werk last_seen bij in een levende.

5. Noem in rij F3 van SECURITY.md je test en zet de status op closed in 4.3.

Voer python -m pytest -q opnieuw uit. Het eindigt met 10 passed: de inactiviteitstest, de fixatietest uit les 2, en de acht uit eerdere hoofdstukken.

Klik daarna op Check my work. Sessies eindigen nu op de server. De cookie die de id draagt, zegt nog steeds alleen HttpOnly, Max-Age en Path, en de volgende les geeft hem de rest van zijn instructies.