Zoals beloofd zijn we terug met onze volgende blog over de top gerapporteerde kwetsbaarheden!

In deze blog werpen we een blik op de Insecure Direct Object Reference (IDOR) kwetsbaarheid. We zullen bespreken wat voor soort kwetsbaarheid dat is, hoe de aanvaller de informatie verkrijgt, wat de impact en de ernst is, evenals hoe deze kwetsbaarheid kan worden voorkomen en verminderd.

Wat is een IDOR?

Een IDOR, of Insecure Direct Object Reference, is een kwetsbaarheid die een aanvaller ongeautoriseerde toegang geeft om objecten zoals bestanden, gegevens of documenten op te halen. Bovendien staat deze kwetsbaarheid op de lijst van OWASP top tien 2021 onder gebroken toegangscontrole.

De IDOR-kwetsbaarheid komt vaak voor onder de valse veronderstelling dat objecten nooit rechtstreeks zullen worden opgehaald met hun unieke identificatie, maar slechts via de logica van de applicatie. Gewoonlijk toont een applicatie alleen de objecten die je bevoegd bent te bekijken en biedt vaak de vereiste identificatoren om die op te halen. Echter, bij het ophalen van het genoemde object ontbreekt vaak een controle of de aanvragende gebruiker daadwerkelijk toegang heeft tot het object.

In het onderstaande voorbeeld (Figuur 1) kan het kwetsbare object in de URL worden gevonden. Door het nummer te wijzigen naar andere bestaande ID's kan de aanvaller de informatie van die pagina ophalen die toebehoort aan het slachtoffer.

Figuur 1

Andere plaatsen die kwetsbare objecten kunnen bevatten zijn overal in de applicatie die gebruikersinvoer accepteren om objecten direct te verwijzen. Om dit te testen, moet een waarde worden gewijzigd. Wanneer er geen verificatie is of een gebruiker bevoegd is deze gegevens op te halen, worden de gegevens teruggegeven. 

Om IDORs te vinden, kan de methode worden gebruikt om 2 accounts voor een applicatie te maken en de HTTP-verzoeken vast te leggen met Burp Suite of een andere proxy. Deze verzoeken kunnen worden vergeleken en de string die anders is, kan een IDOR zijn, aangezien dit een unieke waarde voor de gebruiker is. De test om te verifiëren of dit object kwetsbaar is, is om het verzoek van de ene gebruiker te herhalen in de context van de andere gebruiker en te zien of er gegevens worden teruggegeven. 

Impact

Er kunnen verschillende dingen gebeuren, afhankelijk van de parameter die werd gewijzigd, evenals de impact afhankelijk is van het type gegevens. Een IDOR-kwetsbaarheid kan leiden tot:

• Toegang tot gevoelige gegevens (Vertrouwelijkheid).

• Ongeautoriseerde wijziging of verwijdering van gegevens (Integriteit en Denial Of Service).

Ernst

De ernst van een IDOR hangt af van de impact. De kwetsbaarheid zal een hogere ernst hebben wanneer de aanvaller de IDOR kan gebruiken om een belangrijk account over te nemen, vergeleken met de gevallen waarin toegang wordt verkregen tot onbelangrijke informatie. Voorbeelden van ernst met IDOR zijn:

• Kritiek‍

  Het overnemen van een admin-account.
  
  

• Hoog

  Het overnemen van een ander gebruikersaccount.
  
  

• Gemiddeld

  In staat zijn om de informatie van een andere gebruiker te bekijken.

  
  

• Laag

  Toegang vinden tot beperkte gegevens, hoewel dit hoger kan zijn afhankelijk van het soort en de gevoeligheid van deze gegevens. 

  
  

• Informatief

  Toegang vinden tot beperkte, maar onbelangrijke, gegevens.

IDOR voorkomen

Toegangscontrole

Authenticatie is het proces van het verifiëren en identificeren van een gebruiker. Autorisatie is het specificeren van de toegangsrechten/privileges die deze gebruiker heeft. Een IDOR komt vaak voor wanneer de autorisatie niet wordt gevalideerd met de gevraagde bron voordat de bron wordt vrijgegeven of gewijzigd. 

Om te voorkomen dat bronnen aan de verkeerde gebruiker worden getoond of gewijzigd, moet toegangscontrole worden toegepast. Dit gebeurt door te verifiëren dat de gebruiker legitieme toegang heeft tot de betreffende bron.

Het is een goede praktijk om standaard alle toegang tot bronnen te weigeren, tenzij het openbare informatie is. Dit voorkomt dat verkeerde informatie wordt getoond aan gebruikers die geen toegang zouden mogen hebben.

Mitigeren

Gebruik een objectidentifier die niet gemakkelijk te raden is

Geef objecten geen waarde met een getal of gemakkelijk te raden woord, gebruik in plaats daarvan een hash met zout. Door alleen de waarde van een object te hashen, kan deze worden doorverwezen naar andere waarden en door aanvallers worden geraden. Bijvoorbeeld, het gehashte woord ‘Waarde’ zal altijd hetzelfde zijn.‍

Waarde = 8185923e0830e44b21d1c6c8c43fa895374fdbb40f9200572d13b58fcdd2a2df

Waarde = 8185923e0830e44b21d1c6c8c43fa895374fdbb40f9200572d13b58fcdd2a2df

Waarde = 8185923e0830e44b21d1c6c8c43fa895374fdbb40f9200572d13b58fcdd2a2df

Door zout toe te voegen, heeft elke waarde een unieke string, wat het nog moeilijker maakt te raden.

Waarde + GKLBP = 821becddd1ffb3c1dadcbac63c5a728a223a2c7cdbfc225930afc44f1ebb861e

Waarde + PRCUQ = a9fd81c209f334aa8e7826a50ba9a06f90c2dc822df38416a8f2ab7f4c55f5cd

Waarde + WZTJY = a1e1b47e447099f48da6c863f887f53e8299eae2dbc8c9a5dd46f2a9144d8e84

Een nog eenvoudigere manier om dit te bereiken is door willekeurig gegenereerde waarden voor objecten te gebruiken, zoals een Universally Unique Identifier (UUID).

We hopen dat je de informatie nuttig vindt en genoten hebt van de blog! Als dat zo is, blijf dan op de hoogte voor de volgende blog over de top gerapporteerde kwetsbaarheden! Heb je de eerste blog over Cross-site scripting (XSS) kwetsbaarheid gemist of wil je je geheugen opfrissen? Je kunt het nog steeds hier bekijken.‍

Referenties

https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html

Tips van OWASP over hoe IDOR-kwetsbaarheden te voorkomen.

https://portswigger.net/bappstore/30d8ee9f40c041b0bfec67441aad158e

Over authmatrix, een Burp Suite-extensie die helpt bij het testen van autorisatie.