Horizontale privilege-escalatie

Wat is Horizontale privilege-escalatie?

Onzekere directe objectreferentie leeft in de kloof tussen twee controles die aanvoelen als één. Sessie-middleware bewijst wie er belt. Niets vraagt ​​of deze beller dit record mag lezen. U opent uw eigen afschrift in een geld-app, wijzigt één cijfer in de ID en leest het saldo en de transacties van een vreemde met uw eigen geldige sessie. Vervolgens voegt u de eigendomsvergelijking toe die 403 retourneert wanneer de eigenaar van de record niet de gebruiker van de sessie is, en ziet u waarom willekeurige UUID's en snelheidslimieten diepgaand zijn in plaats van de oplossing.

Wat je leert in Horizontale privilege-escalatie

• Maak onderscheid tussen authenticatie (wie belt) en autorisatie (of deze beller deze bron mag bereiken) en identificeer welke controle IDOR omzeilt
• Herken de IDOR-handtekening: één geldige sessie, veel verschillende resource-ID's, succesvolle reacties bij veel eigenaren
• Pas de eigendomsvergelijking toe als primaire verdediging: vergelijk de eigenaar van de bron met de gebruiker van de sessie en weiger met 403 als ze niet overeenkomen
• Leg uit waarom willekeurige UUID-ID's, snelheidsbeperkingen en sterkere wachtwoorden stuk voor stuk falen als primaire verdediging tegen IDOR; de bug mist autorisatie en geen raadbare ID's
• Bepaal het eigendom op basis van de sessie aan de serverzijde in plaats van op basis van de waarde die de aanroeper beheert in de URL, hoofdtekst of kopteksten

Horizontale privilege-escalatie — Trainingsstappen

1. Een normaal klantbeeld

   Sablefin is een geld-app waar iedereen zich voor kan aanmelden. Bob deed dat wel, met een wegwerpidentiteit, en nu is hij gewoon een klant die net als iedereen naar zijn eigen account kijkt. Hij opent zijn maandoverzicht. Niets hier is voor hem verboden terrein. Het is zijn account, zijn gegevens, zijn login.

2. Bekijk het verzoek

   Voordat Bob iets verandert, wil hij het verzoek zien dat zijn eigen app doet om deze pagina te laden. Hij opent de netwerktools van de browser en laadt de pagina opnieuw, zodat de oproep die de app verzendt om zijn verklaring op te halen, wordt vastgelegd.

3. Het eindpunt en de id

   De netwerktools hebben het gesprek vastgelegd. Het is een duidelijke GET naar de verklaringen-API, en het hele adres van de verklaring van Bob is een enkel geheel getal aan het einde van het pad.

4. Het teken dat bewijst wie hij is

   Hetzelfde vastgelegde verzoek bevat het sessietoken van Bob. De server leest het om te bevestigen dat de beller een aangemelde klant is.

5. Verander één cijfer

   Bob raakt de interface van de app nooit meer aan. Hij bewerkt het vastgelegde verzoek rechtstreeks, laat de ID één stap achterwege en verzendt het opnieuw met zijn eigen token er nog aan. Als de server een verklaring teruggeeft die niet van hem is, heeft hij nooit het eigendom gecontroleerd: hij vertrouwde op de ID in de URL om te beslissen wat hij moest retourneren.

6. De rekening van iemand anders

   Andere naam, ander rekeningnummer, ander saldo en Bob's token staat nog steeds op de aanvraag. De server had geen reden om dit te serveren, en hij diende het toch. Eén aangrenzende ID is voldoende om de bug te bevestigen. Alles voorbij dit punt is een script van tien regels dat 's nachts door de id-ruimte loopt terwijl Bob slaapt.

7. Kennis check

   Je zag zojuist hoe een ingelogde klant de verklaring van een andere klant las door een nummer te wijzigen. Leg vast waarom.

8. De waarschuwing komt binnen

   U bent eigenaar van de klantenrekeningendienst van Sablefin. Van de ene op de andere dag zorgde de detectie van afwijkingen ervoor dat één sessie instructie na instructie ophaalde voor accounts die niet de zijne waren. Security Operations heeft u de details per e-mail gestuurd.

9. Open de handler

   Open de verklaringenhandler en kijk hoe deze beslist wat moet worden geretourneerd.

10. Zoek de fout

    De handler haalt de instructie op via de id in de URL en retourneert deze. Tussen die twee regels staat de cheque die er zou moeten staan ​​niet.