Phenquestions
In dit artikel krijgt u de vereiste informatie van de toepassing om te weten wat de aanvallende site moet doen om geldige verzoeken naar de kwetsbare server te sturen. Vervolgens maakt u een pagina die de legitieme verzoeken simuleert en de gebruiker verleidt om die pagina te bezoeken terwijl deze is geverifieerd. Je maakt ook een paar herhalingen van de basis proof of concept om het meer op een echte aanval te laten lijken, waarbij het slachtoffer het niet merkt. Merk op dat het codebestand voor dit artikel te vinden is op de github van de auteur.
Klaar maken
Voor dit artikel heeft u een geldig gebruikersaccount in BodgeIt nodig. Dit artikel gebruikt [e-mail beveiligd] als slachtoffer:
Hoe je dat doet…
Eerst moet je het verzoek analyseren waartoe je het slachtoffer wilt dwingen. Hiervoor heb je Burp Suite of een andere proxy nodig die in de browser is geconfigureerd:
- Log in bij BodgeIt als een gebruiker en klik op de gebruikersnaam om naar het profiel te gaan.
- Een wachtwoord wijzigen. Bekijk hoe het verzoek eruitziet in de proxy:
Het is dus een
POSTverzoek omhttp://192.168.56.11/bodgeit/wachtwoord.jsp,en heeft alleen het wachtwoord en de bevestiging in de body. - Probeer een heel eenvoudige HTML-pagina te maken die dit verzoek repliceert. Maak een bestand (noem het)
csrf-wachtwoord wijzigen.html) met de volgende inhoud:
- Laad dit bestand nu in dezelfde browser als uw ingelogde sessie:
- Klik op verzenden en u wordt doorgestuurd naar de profielpagina van de gebruiker. Het zal u vertellen dat het wachtwoord met succes is bijgewerkt.
- Hoewel dit het punt bewijst, kan een externe site (of een lokale HTML-pagina zoals in dit geval) een verzoek om wachtwoord wijzigen in de app uitvoeren. Het is nog steeds onwaarschijnlijk dat een gebruiker op de Verzenden U kunt het automatiseren en de invoervelden verbergen zodat de schadelijke inhoud verborgen is. Maak nu een nieuwe pagina op basis van de vorige; noem het
csrf-wijzig-wachtwoord-scripted.html:Een volledig ongevaarlijke pagina
Je kunt deze pagina vertrouwen.
Er zal niets ergs met jou of je BodgeIt-account gebeuren.
Deze keer heeft het formulier een ID-parameter en is er een script op de pagina dat de inhoud verzendt wanneer de pagina volledig is geladen.
- Als u deze pagina in dezelfde browser laadt waar u een BodgeIt-sessie hebt gestart, wordt het verzoek automatisch verzonden en wordt de profielpagina van de gebruiker daarna weergegeven. In de volgende schermafbeelding is de browser Debuggerstel een breekpunt in net voordat het verzoek werd gedaan:
- Deze laatste poging ziet er beter uit vanuit het perspectief van een aanvaller. Je hebt alleen het slachtoffer nodig om de pagina te laden en het verzoek wordt automatisch verzonden, maar dan ziet het slachtoffer de Uw wachtwoord is gewijzigdbericht, en dat zal zeker een waarschuwing opleveren.
- U kunt de aanvallende pagina verder verbeteren door het antwoord in een onzichtbaar frame binnen dezelfde pagina te laten laden. Er zijn veel manieren om dit te doen; een snelle en vuile is om een maat 0 in te stellen voor het frame. Je bestand zou er als volgt uitzien:
Een volkomen ongevaarlijke pagina
Je kunt deze pagina vertrouwen.
Er zal niets ergs met jou of je BodgeIt-account gebeuren.
Merk op hoe de doeleigenschap van het formulier het iframe is dat er net onder is gedefinieerd en dat een dergelijk frame 0% hoogte en breedte heeft.
- Laad de nieuwe pagina in de browser waar de sessie is gestart. Deze schermafbeelding laat zien hoe de pagina eruitziet wanneer deze wordt geïnspecteerd met de browser Ontwikkelaarstools:
Merk op dat het iframe-object slechts een zwarte lijn op de pagina is en dat u in Inspector kunt zien dat het de profielpagina van de BodgeIt-gebruiker bevat. - Als u de netwerkcommunicatie analyseert die wordt uitgevoerd door uw CSRF-pagina, kunt u zien dat deze daadwerkelijk verzoeken doet om het BodgeIt-wachtwoord te wijzigen:
Hoe het werkt…
Wanneer u een verzoek verzendt vanuit een browser en al een cookie van het doeldomein heeft opgeslagen, zal de browser de cookie aan het verzoek toevoegen voordat deze wordt verzonden. Dit is wat cookies zo handig maakt als sessie-ID's, maar dit kenmerk van hoe HTTP werkt, maakt het ook kwetsbaar voor een aanval zoals degene die je in dit artikel hebt gezien.
Wanneer u een pagina in dezelfde browser laadt, waar u een actieve sessie in een applicatie hebt, zal de browser automatisch de sessiecookie aan dat verzoek toevoegen. Dit gebeurt zelfs als het een ander tabblad of venster is en deze pagina een verzoek doet aan het domein waar de sessie is gestart.
Als de server niet verifieert dat de verzoeken die hij ontvangt daadwerkelijk afkomstig zijn van binnen de toepassing, kan een kwaadwillende site oproepen plaatsen namens legitieme, actieve gebruikers die deze schadelijke site bezoeken terwijl ze zijn geverifieerd bij het doeldomein.
In een penetratietest van een web-app, de eerste code die u gebruikte, die met de twee tekstvelden en de Verzenden knop, kan voldoende zijn om de aanwezigheid van een beveiligingsfout aan te tonen. Het penetratietesten van de applicatie kan echter deel uitmaken van een andere opdracht, zoals een social engineering- of rode teamoefening. In dit geval zal enige extra inspanning nodig zijn om te voorkomen dat de slachtoffergebruiker vermoedt dat er iets aan de hand is.
In dit artikel heb je JavaScript gebruikt om het verzenden van het verzoek te automatiseren door de onload-gebeurtenis op de pagina in te stellen en de verzendmethode van het formulier uit te voeren in de gebeurtenishandlerfunctie. Je hebt ook een verborgen iframe gebruikt om de reactie op de wachtwoordwijziging te laden, zodat het slachtoffer nooit het bericht ziet dat zijn/haar wachtwoord is gewijzigd.
Als je dit artikel interessant vond, kun je het verkennen Kali Linux Web Penetration Testing Cookbook - Tweede editie om de meest voorkomende webkwetsbaarheden te ontdekken en te voorkomen dat ze een bedreiging vormen voor de beveiliging van uw site. Kali Linux Web Penetration Testing Cookbook - Tweede editie geeft je de vaardigheden die je nodig hebt om elke fase van een penetratietest te doorlopen - van het verzamelen van informatie over het systeem en de applicatie tot het identificeren van kwetsbaarheden door middel van handmatige tests.
