Tokenblootstelling in URL

Wat is Tokenblootstelling in URL?

Door een sessietoken in een URL te plaatsen, lekt een waarde die degene die het bezit ervan verifieert. URL's komen terecht in server- en CDN-toegangslogboeken, browsergeschiedenis, link-preview-unfurlers en de Referer -header die naar activa van derden wordt verzonden. U verzamelt live tokens uit een analytische verwijzingsdump en leest de privédocumenten van een slachtoffer zonder dat er een wachtwoord bij betrokken is. Vervolgens verplaatst u het token naar een Set-Cookie -header met HttpOnly , Secure en SameSite=Strict , en maakt u elk token ongeldig dat al is gelekt, omdat het patchen van de code niet intrekt wat aanvallers hebben verzameld.

Wat je leert in Tokenblootstelling in URL

• Erken dat elke waarde die een aanvaller opnieuw kan afspelen om zich te authenticeren als gebruiker (sessietoken, API-sleutel, reset-token, ondertekende URL-parameter) thuishoort in een cookie of header, en nooit in een URL
• Begrijp het verschil in lekoppervlak tussen URL's (gelogd, doorgestuurd, opgenomen door veel partijen) en cookies (alleen browser-serverkanaal)
• Pas het HttpOnly + Secure + SameSite=Strict cookiepatroon toe voor sessietokens en gelijkwaardige authenticators
• Maak elk sessietoken ongeldig dat al in logboeken en verwijzingen is gelekt, omdat het repareren van de code de tokens die aanvallers al hebben verzameld niet met terugwerkende kracht intrekt
• Controleer elke URL-generator (aanmelding via magische link, URL's voor ondertekend delen, downloadtokens, URL's voor het opnieuw instellen van wachtwoorden, OAuth-callbacks) op authenticators die buiten de URL moeten worden verplaatst

Tokenblootstelling in URL — Trainingsstappen

1. Bekijk een aanmelding

   Bob heeft zich verdiept in Corveil, een app voor gedeelde werkruimte waarop bedrijven hun documenten kunnen uitvoeren. Voordat hij een ingang zoekt, wil hij eerst zien wat de app precies doet als iemand zich aanmeldt. Hij registreert een wegwerpaccount zodat hij als zichzelf kan inloggen en elke stap kan bekijken. Hij begint op de inlogpagina.

2. Log in en volg de omleiding

   Bob logt in op zijn wegwerpaccount, zoals elke gebruiker dat zou doen. Zijn wachtwoordbeheerder vult de opgeslagen inloggegevens in. Corveil meldt hem aan en stuurt hem door naar zijn werkruimtedashboard. De browser komt terecht op de pagina waarnaar hij is gestuurd.

3. Het token staat in de adresbalk

   Bob zit nu op zijn dashboard en er valt hem iets op: bij het inloggen is zijn sessietoken rechtstreeks in de URL geplaatst. Die ene string is zijn hele ingelogde sessie. Hij hoeft nergens in te breken. Hij heeft alleen de plaatsen nodig waar deze URL's zich opstapelen.

4. Verzamel de verwijzingslogboeken

   Bob stuurt Corveil nooit een enkel kwaadwillig verzoek. In plaats daarvan koopt hij voor een maand aan verwijzingslogboeken van een analytische reseller, het soort leverancier wiens trackingtag op het dashboard van Corveil staat en stilletjes de volledige verwijzende URL registreert van iedereen die deze laadt. Hij opent een terminal naast de browser en greps die zich voeden voor de inloglinks op het dashboard.

5. Speel een gestolen sessie opnieuw af

   Bob kiest één slachtoffer uit de vuilnisbelt, Maya Okafor, en neemt haar sessiefiche. Hij richt de API-tester op de document-API van Corveil en draagt ​​haar gestolen token in een Cookie-header, precies zoals haar browser dat zou doen. Als de server het accepteert, leest hij Maya's privéwerkruimte zonder ooit haar wachtwoord te kennen.

6. Haar sessie is de zijne

   De server beschouwde het gestolen token als een echte login en antwoordde. Bob leest nu Maya's privédocumenten via een gewone API-aanroep, zonder eigen account en zonder wachtwoord.

7. Kennis check

   Bob kan dit voor duizenden gebruikers tegelijk doen, allemaal vanuit de logbestanden die hij heeft gekocht. Wees nauwkeurig over waarom een ​​token in een URL zoveel slechter is dan gewone gegevens in een URL.

8. Het beveiligingsalarm

   U bent eigenaar van de inlogservice van Corveil. Van de ene op de andere dag markeerde de detectie een reeks sessies die vanaf onbekende locaties werden afgespeeld en stuurde u de bevindingen per e-mail. Lees wat er is opgevangen en open vervolgens de code.

9. Open de aanmeldingshandler

   De handler die het inloggen voltooit en de gebruiker doorstuurt naar zijn dashboard, is wat u moet wijzigen. Open het en kijk hoe het de omleiding opbouwt.

10. Zoek het lek

    De handler start een nieuwe sessie en plakt vervolgens de ID rechtstreeks in de queryreeks van het omleidingsdoel. De browser volgt die URL, en vanaf dat moment is het token overal waar het adres naartoe gaat.