@hacker0x01HackerOne

HackerOne stelt de wereld in staat om een ​​veiliger internet op te bouwen.

Onveilige Direct Object References (of IDOR) is een simpele bug die een klap uitdeelt. Wanneer het wordt misbruikt, kan het aanvallers toegang geven tot gevoelige gegevens of wachtwoorden of hen de mogelijkheid geven om informatie te wijzigen. Op HackerOne worden er maandelijks meer dan 200 gevonden en veilig gerapporteerd aan klanten. 

Wat is een IDOR?

Er zijn verschillende soorten IDOR-aanvallen, waaronder:

• Lichaamsmanipulatie, waarin aanvallers de waarde van een selectievakje, keuzerondjes, API's en formuliervelden wijzigen om gemakkelijk toegang te krijgen tot informatie van andere gebruikers.
• URL-manipulatie, waarin de URL aan het einde van de client wordt gewijzigd door de parameters in het HTTP-verzoek aan te passen. 
• HTTP-verzoeken waarin IDOR-kwetsbaarheden doorgaans worden aangetroffen in GET-, POST-, PUT- en DELETE-werkwoorden.
• Massa-toewijzing, waar een recordpatroon kan worden misbruikt om gegevens te wijzigen waartoe de gebruiker geen toegang zou moeten hebben. Hoewel dit niet altijd het gevolg is van IDOR-kwetsbaarheden, zijn er veel krachtige voorbeelden waarvan dit het resultaat is. 

In de eenvoudigste en meest voorkomende vorm ontstaat een IDOR-kwetsbaarheid wanneer de enige input die nodig is om toegang te krijgen tot inhoud of deze te vervangen, afkomstig is van de gebruiker. dit beveiligingslek ingediend bij Shopify door de in Californië gevestigde hacker Rojan Rijal (ook bekend als @rijalrojan) in 2018 is het perfecte voorbeeld.

Door te observeren hoe bestandsbijlagen werden gelabeld bij het verzenden van een vraag naar de Exchange Marketplace-applicatie van Shopify, kon Rojan documenten vervangen door dezelfde bestandsnaam uit verschillende accounts te gebruiken. 

Figuur 1: IDOR-kwetsbaarheid gerapporteerd door @rijalrojan aan Shopify op het HackerOne-platform.

Voor detailhandel- en e-commercebedrijven vertegenwoordigen IDOR-kwetsbaarheden 15% van waar organisaties premies voor betalen en vertegenwoordigen ze de grootste kwetsbaarheid voor programma's binnen de overheid (18%), medische technologie (36%) en professionele dienstverlening (31%). 

Als ze zo eenvoudig zijn, waarom komen ze dan zo vaak voor? 

Kortom, IDOR's kunnen niet alleen door tools worden gedetecteerd. 

IDOR's vereisen creativiteit en handmatige beveiligingstests om ze te identificeren. Ze vereisen dat u de zakelijke context van de doeltoepassing begrijpt. Hoewel sommige scanners activiteit kunnen detecteren, is er een menselijk oog nodig om te analyseren, evalueren en interpreteren. Het begrijpen van de diepere context is een aangeboren menselijke vaardigheid die machines niet kunnen repliceren. In traditionele pentests kunnen deze kwetsbaarheden onopgemerkt blijven, tenzij een pentester elke mogelijke parameter in elk verzoekeindpunt test. 

Wat zijn de implicaties van een IDOR-kwetsbaarheid? 

Misschien wel de meest beruchte IDOR-kwetsbaarheid van de laatste tijd is die gevonden in het alt-tech sociale mediaplatform Parler. Het bedrijf rangschikte hun berichten op nummer in de URL, een veelbetekenend teken van IDOR. Als u een opeenvolgend cijfer toevoegt aan de URL van een Parler-bericht, kunt u voor onbepaalde tijd toegang krijgen tot het volgende bericht op het platform. Zonder authenticatie of toegangsbeperkingen zou een aanvaller gemakkelijk een programma kunnen bouwen om elke post, foto, video en gegevens van de hele site te downloaden. Hoewel dit slechts openbare berichten waren (niet noodzakelijkerwijs ID's die werden gebruikt om accounts te verifiëren), werden ook geolocatiegegevens van berichten gedownload, die de GPS-coördinaten van de huizen van gebruikers konden onthullen.  

Hoe kun je voorkomen dat IDOR's opduiken?

"IDOR vermijden is alleen mogelijk door een robuust toegangscontrolemechanisme te bouwen, de best passende methodologie voor uw scenario te kiezen, alle toegang te loggen en indien mogelijk een audit uit te voeren met een autorisatiecontrole achteraf", aldus HackerOne-hacker Manoel Abreu Netto, online beter bekend als @manoelt.

"Als je echter de impact van een IDOR wilt verminderen, vermijd dan het gebruik van een eenvoudig patroon om naar objecten in de backend te verwijzen, dus gebruik geen sequentiële integerwaarde, maar zoiets als uuid of zelfs een MAC (hash-ID) met een zout per gebruikerssessie.

Dit elimineert de IDOR niet, maar vermindert de algehele impact en de mogelijkheid om objecten op te sommen. "

Hieronder vindt u enkele best practices om IDOR-kwetsbaarheden te verhelpen. 

1. Ontwikkelaars moeten het weergeven van privé-objectreferenties, zoals sleutels of bestandsnamen, vermijden.
2. Validatie van parameters moet correct worden geïmplementeerd.
3. Verificatie van alle objecten waarnaar wordt verwezen, moet worden gecontroleerd.
4. Tokens moeten zo worden gegenereerd dat ze alleen aan de gebruiker kunnen worden toegewezen en niet openbaar zijn.
5. Zorg ervoor dat query's binnen het bereik van de eigenaar van de resource vallen. 
6. Vermijd zaken als het gebruik van UUID's (Universally unique identifier) ​​in plaats van sequentiële ID's, aangezien UUID's vaak IDOR-kwetsbaarheden onopgemerkt laten.

Voor meer informatie over het verminderen van risico's en om aan de slag te gaan met door hackers aangedreven beveiliging, ga je naar onze CISO-gids om waarde te ontlenen aan door hackers aangedreven beveiliging.

Coinsmart. Beste Bitcoin-beurs in Europa
Bron: https://hackernoon.com/what-are-insecure-direct-object-references-idor-hz1j33e0?source=rss