Een open redirect is elke pagina op uw site die de browser van de bezoeker doorstuurt naar een URL uit gebruikersinvoer, zonder die te controleren. Het lijkt onschuldig. In de praktijk stelt het een aanvaller in staat een phishinglink te versturen waarin uw echte domein zichtbaar is, en in een OAuth-opzet kan het autorisatiecodes en access tokens laten lekken.
Waarom een redirect meer is dan een cosmetische fout
CWE-601 beschrijft de zwakte als een webapplicatie die door de gebruiker gestuurde invoer accepteert die een link naar een externe site aanwijst, en die link vervolgens in een redirect gebruikt. Het slachtoffer volgt een link naar uw vertrouwde site en komt terecht op een pagina die de aanvaller beheert. De OWASP cheat sheet geeft het patroon:
http://example.com/example.php?url=http://malicious.example.comDe servernaam in de aangepaste link is identiek aan die van de oorspronkelijke site, waardoor de phishingpoging betrouwbaarder oogt. Voor de kant van de gebruiker, zie onze linkchecker.
Bij OAuth reikt dezelfde fout verder. RFC 9700 stelt dat clients en autorisatieservers GEEN URL's MOGEN blootstellen die de browser doorsturen naar willekeurige URI's uit een queryparameter, omdat open redirectors het exfiltreren van autorisatiecodes en access tokens kunnen mogelijk maken.
Forwards zijn een verwant geval. Als gebruikersinvoer een interne bestemming kiest, zoals in function.jsp?fwd=admin.jsp, kan een speciaal samengestelde URL de toegangscontrole passeren en een beheerfunctie bereiken. De applicatie moet controleren of de gebruiker geautoriseerd is voor het doel.
De parameters opsporen
Namen verschillen: url, fwd en returnUrl komen voor in de OWASP-voorbeelden, en uw eigen code zal er andere hebben. Zoek naar het patroon, niet naar de naam.
| Stack | Gevaarlijk patroon |
|---|---|
| Java | response.sendRedirect(request.getParameter("url")) |
| PHP | header("Location: " . $redirect_url) met $_GET['url'] |
| C# .NET | Response.Redirect(url) met request.QueryString["url"] |
| Rails | redirect_to params[:url] |
| Java forward | getRequestDispatcher(fwd).forward(...) |
Een eerste ronde met grep levert een lijst op om door te lezen. Pas het pad en de bestandstypen aan op uw repository.
grep -rnE 'sendRedirect\(|Redirect\(|redirect_to params|header::LOCATION' src/
grep -rn -A3 'header(.Location' src/Het tweede commando is voor PHP. Lees de regels na elke treffer: zonder exit na header("Location... blijft de rest van het script draaien. Een browser die is ingesteld om de redirect te negeren, kan dan de rest van de pagina tonen.
.NET-teams kijken het best eerst naar login-acties. Volgens de cheat sheet zijn ASP.NET MVC 1- en 2-sites bijzonder kwetsbaar, en het MVC 2-voorbeeld LogOn redirect zonder enige validatie naar returnUrl. De oplossing is overstappen op MVC 3.
De meeste treffers zijn onschuldig. Bij elke redirect waarvan het argument geen letterlijke string of server-side lookup is, hoort één vraag: waar komt de waarde vandaan? Cookies, verborgen formuliervelden, headers en database-inhoud tellen allemaal mee. Veel open redirects bestaan doordat de ontwikkelaar aannam dat een cookie of verborgen veld niet gewijzigd kon worden.
Stop bij het bevestigen van een bevinding niet bij één gewoon extern adres. Verstuur elk van onderstaande waarden in de parameter en bekijk de Location header:
http://malicious.example.comhttps://yoursite.example@malicious.example(userinfo:yoursite.examplewordt een gebruikersnaam)https://yoursite.example.malicious.example(een hostnaam die met de uwe begint)https://malicious-yoursite.example(een hostnaam die op de uwe eindigt)
De cheat sheet noemt userinfo en misleidende hostnamen als manieren om prefix- en suffixcontroles te omzeilen. Als een van deze waarden wel slaagt terwijl de gewone URL werd geblokkeerd, is de controle waarschijnlijk stringmatching. Dat is een inschatting, geen bewijs, maar vervang de controle in elk geval.
Scanners vinden een deel hiervan. De OWASP Web Security Testing Guide stelt dat dergelijke tools generiek zijn en geen applicatiespecifieke context hebben, dus verifieer elke bevinding handmatig.
Verhelpen, in volgorde van voorkeur
- Redirect niet op basis van gebruikersinvoer. Als de bestemming in de code vastligt, kan een aanvaller die niet wijzigen.
- Koppel ID's server-side aan doelen. De gebruiker levert een korte naam of ID aan en de server zoekt de volledige URL op, waarbij al het andere wordt geweigerd. Zorg dat de ID's niet doorlopen kunnen worden, anders kan een bezoeker alle doelen opsommen.
- Gebruik de framework-helper voor lokale returns. In ASP.NET Core zijn dat
LocalRedirectofIsLocalUrl, die niet-lokale bestemmingen weigeren. - Zet externe bestemmingen op een allowlist. Gebruik een onderhouden URL-parser en vergelijk het geparste scheme, de canonieke host en de effectieve poort met een expliciete lijst. Beperk het pad als alleen specifieke endpoints zijn toegestaan.
- Eventueel: vereis een nonce. CWE beschrijft een onvoorspelbare, door de applicatie gegenereerde nonce bij elk redirectverzoek, waarbij verzoeken zonder nonce worden geweigerd. XSS kan dit omzeilen, dus het vult een oplossing aan en vervangt die niet.
Regels voor de allowlist-controle:
- Weiger userinfo en dubbelzinnige invoer.
- Redirect met de gevalideerde URL, niet met een versie die u daarna nog omzet.
- Gebruik nooit ruwe prefix- of suffixmatching. De cheat sheet noemt GitLab als voorbeeld waar userinfo en misleidende hostnamen zulke controles omzeilden.
Een denylist met slechte waarden is een zwakke primaire verdediging, hoewel CWE die accepteert voor het detecteren van aanvallen. Kies in plaats daarvan voor "accepteer alleen wat bekend en goed is".
Als mensen uw site moeten kunnen verlaten, voegt een tussenpagina die de bestemming noemt en een klik vereist een extra laag toe. Voorkom XSS bij het bouwen van die pagina.
De OAuth-kant
RFC 9700 vereist dat autorisatieservers de redirection-URI's van clients met exacte stringvergelijking toetsen aan de vooraf geregistreerde URI's, behalve voor poortnummers in localhost-redirection-URI's van native apps. Mijn interpretatie, geen RFC-tekst: exacte matching bewijst dat de callback de geregistreerde is, dus als die geregistreerde host ook een open redirector heeft, kan de code verder reizen. De RFC verwijst voor de details naar Sectie 4.11. Lees die door voordat u op mijn samenvatting vertrouwt.
Waar te beginnen
- Draai de bovenstaande grep-patronen over uw code en maak een lijst van elke redirect en forward waarvan het doel uit een request, cookie of opgeslagen waarde komt. Controleer eerst de login- en OAuth-callbackhandlers.
- Controleer PHP-treffers op een ontbrekende
exit, en .NET-projecten op MVC 1- of 2-loginacties. - Test elke treffer met de vier invoerwaarden hierboven, inclusief de userinfo-vorm, en noteer welke de browser buiten uw domein sturen.
- Vervang door gebruikers aangeleverde URL's waar mogelijk door server-side ID-mapping, gebruik framework-helpers die alleen lokaal doorsturen voor returnadressen, en pas een allowlist op geparste URL's toe voor de enkele externe bestemmingen die u nodig hebt.
- Controleer uw OAuth-clientregistraties op exacte redirect-URI's en bevestig dat geen van uw hosts een open redirector bevat.
- Neem een redirecttest op in de code review en in de scope van uw penetratietest, zodat de fout niet terugkeert.
