Onveilige URL-omleiding

Wat is Onveilige URL-omleiding?

Een open omleiding stuurt de browser naar een bestemming die uit het verzoek is gehaald, zonder te vragen of de bestemming van u is. De applicatie profiteert niets van de bug; de aanvaller krijgt uw hostnaam, op het moment dat de gebruiker deze het meest vertrouwt. Je speelt een login af die een next -parameter respecteert en ziet hoe een 302 het slachtoffer naar een vergelijkbare inlogpagina brengt. Vervolgens repareert u res.redirect(req.query.next) met alleen relatieve paden of een acceptatielijst voor hostnamen, en ziet u waarom startsWith('/') een protocol-relatieve //host rechtstreeks voorbij laat gaan.

Wat je leert in Onveilige URL-omleiding

• Herken een open omleiding als een phishing-versneller: de aanvaller leent de legitieme hostnaam voor vertrouwensverankering
• Begrijp dat protocol-relatieve URL's (<code>//host</code>) naïeve <code>startsWith("/")</code>-controles doorstaan en afzonderlijk moeten worden geblokkeerd
• Pas de relatieve validatie toe (of de hostnaam-toelatingslijst als externe omleidingen een echte vereiste zijn)
• Onderscheid open omleiding van SSRF: de aanvaller bestuurt de browser, niet de server, en de impact is de nauwkeurigheid van phishing en niet de toegang tot het interne netwerk
• Controleer elk <code>res.redirect</code>-, <code>location.href</code>- en <code>302 Location</code>-antwoord waarvan het doel is afgeleid van verzoekinvoer

Onveilige URL-omleiding — Trainingsstappen

1. Het doel vergroten

   Vandaag gaat Bob achter Fernloft-accounts aan. Het is een persoonlijke clouddienst, dus één account bevat iemands hele leven: foto's, belastinggegevens, ID-scans, back-ups. Hij heeft niemands wachtwoord, dus hij is van plan te onderzoeken hoe inloggen van binnenuit werkt. Fernloft laat iedereen zich aanmelden, dus hij begint op de aanmeldingspagina.

2. Maak een wegwerpaccount aan

   Eerst heeft hij een eigen account nodig om mee te testen, een account dat nergens naar hem terug leidt. Hij vult een wegwerpadres en wachtwoord in en maakt deze aan.

3. Lees het inlogadres

   Account gemaakt, Bob komt op de inlogpagina terecht. Voordat hij inlogt, leest hij de adresbalk. De inloglink heeft een redirect_to -waarde, momenteel /home , die bepaalt waar de app de browser naartoe stuurt na een succesvolle aanmelding.

4. Meld u aan en kijk waar het u naartoe stuurt

   Nu logt Bob in met zijn wegwerpaccount en kijkt waar de app de browser naartoe stuurt zodra het wachtwoord is geaccepteerd.

5. Creëer de kwaadaardige link

   Bob herbouwt dezelfde inloglink, maar verandert de redirect_to -waarde zodat deze verwijst naar een pagina waarvan hij eigenaar is in plaats van /home . Hij bewerkt precies die ene waarde in de adresbalk om te zien of de app een doel buiten de site op dezelfde manier zal gehoorzamen als /home .

6. Open omleiding bevestigd

   Bob logt in op de echte Fernloft-pagina met zijn wegwerpaccount. De inloggegevens zijn echt, dus de login slaagt, en vervolgens leest de app zijn vervaardigde redirect_to -waarde om te beslissen waar de browser naartoe moet worden gestuurd.

7. Bewapen de link

   Bob verpakt de gemaakte inloglink in een bericht waar iedereen op zou reageren: een waarschuwing dat de sessie is verlopen. Hij haalt Fernloft-adressen uit een inbreukdump en stuurt dezelfde link naar ze allemaal. We volgen één ontvanger, Alice.

8. Een waarschuwing over uw account

   Alice controleert 24 uur per dag haar persoonlijke inbox. Er is een bericht van Fernloft: haar sessie is verlopen en ze moet verifiëren om haar bestanden te behouden. Ze gebruikt Fernloft voor alles, dus het verliezen van de toegang zou echt hoofdpijn zijn.

9. Klik op de link

   De link wijst naar account.fernloft.com, het echte adres van Fernloft, dus Alice klikt erop zoals iedereen dat zou doen.

10. De echte inlogpagina

    De link opent de echte inlogpagina van Fernloft. De adresbalk toont het echte domein via https, alles ziet er goed uit, en dit is het moment waarop Alice besluit de pagina te vertrouwen.