Sessiefixatie

Wat is Sessiefixatie?

Fixatie en kaping verschillen afhankelijk van wanneer de aanvaller de sessie-ID krijgt. Een kaper steelt het nadat u zich heeft geverifieerd. Fixation plant eerder een bekende waarde en laat uw eigen login deze upgraden. Je pint een live anonieme ID in een link, kijkt hoe het slachtoffer zich aanmeldt en laadt haar dashboard met diezelfde string. De handler leest const sid = req.cookies.sid || crypto.randomUUID() . De oplossing voegt onvoorwaardelijk een nieuwe id toe bij elke authenticatie- en privilege-overgang, en daarom sluiten entropy en HttpOnly deze niet af.

Wat je leert in Sessiefixatie

• Onderscheid sessiefixatie van sessiekaping door het moment waarop de ID in het bezit van de aanvaller is (vóór inloggen versus daarna)
• Erken dat elke primitief voor het schrijven van cookies (subdomein XSS, MITM, respons-splitting) voldoende is om fixatie mogelijk te maken
• Pas onvoorwaardelijke sessie-id-rotatie toe bij elke succesvolle authenticatie (en bij elke privilege-overgang)
• Koppel de rotatie aan het expliciet verwijderen van de sessie-ID vóór het inloggen, zodat de oude binding niet aan de serverzijde kan worden voortgezet
• Controleer elke transitie van de authenticatiestatus voor dezelfde rotatiehook (inloggen, post-MFA, rolverhoging, wachtwoordwijziging)

Sessiefixatie — Trainingsstappen

1. Bobs plan

   Bob kan het wachtwoord van Alice niet stelen, en dat hoeft ook niet. Zijn plan is om haar een sessie-ID te geven die hij al kent, en haar vervolgens daarbovenop te laten inloggen, zodat de sessie waarbij ze uiteindelijk wordt geverifieerd er een is die hij beheert. Eerst heeft hij een sessie-ID nodig om te kunnen planten. Hij opent zelf het Sundermark Logistics-portaal, en dit oude portaal geeft zijn browser een anonieme sessie-ID en geeft deze rechtstreeks in de adresbalk weer als een ?sid -waarde, precies zoals elke bezoeker zou doen.

2. Een geldige sessie-ID om te planten

   Bob opent de cookie-inspecteur van de browser. De portal heeft hem al een sessie-ID gegeven, voordat hij heeft ingelogd of iets heeft gedaan. Het is anoniem, maar het is een echte waarde die de server heeft uitgegeven en die zal worden geëerd. Dit is de exacte ID die hij op Alice zal plaatsen.

3. Maak er een link van

   Bob hoeft niets te bouwen. De sessie-ID die de server hem gaf, is al aan het adres vastgemaakt als ?sid=SID-9F3A2B1C7D , en de portal heeft een oude eigenaardigheid: het kopieert die sid rechtstreeks uit de URL naar de cookie van de bezoeker. Dus deze exacte link is de valstrik. Van iedereen waar Bob het naar stuurt, wordt zijn sessie-ID in zijn of haar cookie geplaatst zodra hij of zij het opent.

4. Stuur de val naar Alice

   Bob richt zich op Alice, een medewerker wiens portaalaccount hij wil. Hij opent zijn e-mail en schrijft haar een bericht, verkleed als een routinematige IT-toegangsmelding, met dezelfde sessie-id-link in de hoofdtekst. Het enige dat hij nodig heeft, is dat zij het opent en inlogt.

5. Een routinematige toegangsmelding

   Alice krijgt 24 uur per dag een e-mail die lijkt op IT-huishouding: bevestig uw portaltoegang vóór het einde van de dag. De link verwijst naar het echte portaal, dus er springt niets uit.

6. Met één klik wordt het cookie overhandigd

   Alice klikt op de link. Het opent de echte inlogpagina van de portal, precies zoals verwacht. Wat ze niet kan zien: de portal heeft zojuist de sid van de link naar haar koektrommel gekopieerd. Haar browser bevat nu de sessie-ID van Bob.

7. Alice meldt zich aan

   Alice logt in met haar Sundermark-inloggegevens, precies zoals gevraagd in de kennisgeving. Het portaal verwelkomt haar en zet haar neer op haar dashboard. Niets ziet er verkeerd uit. Haar account, haar gegevens, haar sessie.

8. De id die had moeten veranderen

   Hier is de fout zichtbaar gemaakt. Een veilige login zorgt voor een gloednieuwe sessie-ID op het moment dat u zich authenticeert, zodat de ID die u bij u draagt, wordt weggegooid. Alice's identiteit is niet veranderd. De cookie op haar geverifieerde dashboard is byte-voor-byte de waarde die binnenkwam op de per e-mail verzonden link, de waarde die Bob heeft geplant.

9. Bob ververst haar account

   Bob heeft nog steeds de inlogpagina geopend in zijn browser, degene die hij heeft geladen met zijn geplante sessie-ID. Een minuut nadat Alice zich heeft aangemeld, vernieuwt hij het gewoon. Zijn geplante ID is nu gebonden aan haar geverifieerde sessie, dus de portal behandelt zijn verzoek als het hare en stuurt hem rechtstreeks naar haar dashboard. Geen wachtwoord, geen diefstal, geen malware.

10. Noem wat er is gebeurd

    Voordat Alice van slachtoffer naar ingenieur overschakelt, moet je nauwkeurig zijn over de aanval.