Het internet is GEEN veilige plek. Prachtig op zichzelf, zeker, en nuttig op meer dan één manier. Maar de cyberspace zit ook tot de nok toe vol met kwaadwillende actoren: dieven, hackers, talloze verschillende criminelen die het voorzien hebben op de zwakken en kwetsbaren. Laat u echter nog niet van slag raken. Zolang u weet waarmee u te maken heeft, maakt u meer dan een goede kans tegen indringers. En in 2022 is de kans groot dat u te maken krijgt met bedreigingen van gebrekkige toegangscontrole (BAC).
Sterker nog, BAC heeft SQL-injecties onttronen en staat nu aan de top van OWASP’s top 10 webapplicatiebeveiligingsrisico’s. Ja, volgens de grootste non-profitorganisatie voor softwarebeveiliging was 3,81% van de geteste apps vatbaar voor bedreigingen van gebrekkige toegangscontrole (wat trouwens VEEL is).
Maar laten we een paar stappen terug doen. Wat is toegangscontrole? En vervolgens, wat is gebrekkige toegangscontrole? Hoe ‘breekt’ het zo gezegd en bent u er kwetsbaar voor? Allemaal goede vragen, dus laten we er meteen induiken.
Gebrekkige toegangscontrole: uitleg en voorbeelden
Zoals u aan de naam kunt raden, is gebrekkige toegangscontrole een beveiligingsdreiging waarbij indringers toegang krijgen tot niet-geautoriseerde gegevens. Toegangscontrole daarentegen omvat beleid en mechanismen die ervoor zorgen dat specifieke gebruikers toegang hebben tot specifieke onderdelen en alleen tot die onderdelen.
Om het uit te leggen (zonder woordspeling bedoeld), kijkt u naar elk systeem, en dat systeem zal verschillende mensen met verschillende rollen hebben. U wilt dat ze dit vrij (tot op zekere hoogte) kunnen doen, maar u wilt zelden dat iedereen die betrokken is toegang heeft tot het hele systeem. Dat is waar toegangscontrole om de hoek komt kijken.
Natuurlijk, als het kapot is en iedereen toegang heeft tot alles wat hij wil, breekt de hel los. Door beoogde machtigingen te omzeilen, kunnen indringers gevoelige informatie openbaar maken, alle gegevens wijzigen en ronduit verwijderen, of bedrijfsfuncties uitvoeren die u niet wilt dat ze uitvoeren.
En met gebrekkige toegangscontrole als de #1 webapplicatiebeveiligingsdreiging ter wereld vandaag de dag, hebben we talloze succesvolle BAC-voorbeelden gezien. Van kleine bedrijven die er het slachtoffer van werden door te vertrouwen op ongeverifieerde gegevens, tot de grootste online imperia die door hackers leeggeroofd werden door doel-URL’s te forceren.
Voordat we naar specifieke voorbeelden kijken, zullen we echter uitzoeken wat toegangscontrole is in de softwarewereld en wat het breekt.
Wat is gebrekkige toegangscontrole?
Gebrekkige toegangscontrole is een falen van de webapplicatie om vooraf vastgestelde toegangsbeleid uit te voeren en te handhaven. Wat is dit beleid? Vanuit het perspectief van webapplicaties valt toegangscontrole in drie hoofdcategorieën:
- Administratieve toegangscontrole. In dit geval bespreken we de toegangsprotocollen die zijn gedefinieerd en ingesteld om het algemene beveiligingsbeleid af te dwingen. Over het algemeen valt dit type in twee subcategorieën: personeelsprotocollen en bedrijfsprotocollen. Om u enkele specifiekere voorbeelden te geven, zijn dit dagelijkse beleidslijnen, aanstellingsprocedures en antecedentenonderzoeken.
- Technische toegangscontrole. Aan de andere kant, ook wel logische toegangscontrole genoemd, zijn de software- en hardwaregebaseerde beperkingen. Deze creëren meerdere extra beveiligingslagen om het systeem (of de bronnen ervan) te beschermen tegen ongeautoriseerde toegang. Deze implementaties omvatten meestal zaken als wachtwoorden, smartcards, verschillende digitale sleutels, protocollen, firewalls en meer. Zoals u zou verwachten, helpen ze veel bij het verhogen van de API-beveiliging van het systeem.
- Fysieke toegangscontrole. Dit is het deel dat bewakingscamera’s, poorten, hekken, beveiligingspersoneel en sloten omvat die de toegang tot specifieke omgevingen beperken. Zoals de naam al aangeeft, richt fysieke toegangscontrole zich op het niet-technische aspect van de vergelijking. Het behoeft geen betoog dat deze categorie net zo belangrijk is als de vorige twee, maar we zullen vandaag in de eerste plaats de ‘technische’ kant bespreken.
Hoe toegangscontrole wordt uitgevoerd
Wat de technische kant betreft, is toegangscontrole opgesplitst in drie groepen: alleen-lezen bestanden, leesbare en schrijf
Eerst moet het de ID van het onderwerp identificeren. Deze ID vertelt het systeem wie toegang heeft aangevraagd.
De volgende stap is het identificeren van de persoon achter het verzoek, meestal gedaan via een authenticatieproces.
Aangenomen dat de authenticatiestap het niet stopt, is de volgende stap het controleren van het verzoek tegen de toegangscontrollijst. Hier zorgt het systeem ervoor dat de persoon achter het verzoek de autoriteit heeft om toegang te krijgen tot de bronnen die ze aanvragen. Ook bepaalt het systeem het toegangs niveau dat deze persoon moet krijgen.
Last but not least moet het systeem altijd auditmechanismen bevatten die potentiële fouten en zwakheden vinden en onderzoeken. Hiermee zou u manieren moeten kunnen detecteren waarop iemand de toegangsbeperkingen kan omzeilen voordat ze het doen.
Wat gebrekkige toegangscontrole veroorzaakt
Om te begrijpen hoe u het systeem kunt beschermen, moet u eerst begrijpen hoe u het systeem kunt breken, toch? Juist. Met dat in gedachten, laten we alles op tafel leggen en ontdekken wat toegangscontrole breekt.
Allereerst zijn er meerdere manieren waarop servers rechten kunnen verlenen en weigeren voor het aanvragen van bepaalde bronnen. Dit omvat sessiecookies, JWT-tokens en meer. Zoals we hierboven hebben vastgesteld, zorgt het systeem er wanneer gebruikers toegang aanvragen tot specifieke bronnen eerst voor dat ze toegang hebben tot deze bronnen voordat de aanvraag wordt uitgevoerd. Het ‘er zeker van zijn’-gedeelte kan worden uitgevoerd via GET-aanroepen en verschillende HTTP-methoden zoals POST/PUT/DELETE. Daar ligt het probleem. Omdat ontwikkelaars elke eindpunt moeten beveiligen met elke mogelijke HTTP-methode, is het gemakkelijk om er ten minste één (of meer) te missen.
Met andere woorden, toegangscontrole ‘breekt’ wanneer indringers erin slagen toegang te krijgen tot iets waar ze geen toegang toe zouden moeten hebben. Vaker wel dan niet gebeurt dit wanneer ontwikkelaars de autorisatieprotocollen niet beveiligen. Het meest voorkomende voorbeeld zijn eindpunten op sites die 403 forbidden-fouten retourneren die vervolgens kunnen worden omzeild door een X-Forwarded-For: “127.0.0.1”-header toe te voegen.
Een ander typisch voorbeeld zijn de oude mappen uit de ontwikkelingsfase die verwijderd of beveiligd hadden moeten worden, maar dat niet zijn.
Meer onervaren gebruikers slaan wachtwoorden misschien ook in platte tekst op in het systeem. Dus wanneer het systeem (meestal de computer) wordt gecompromitteerd, kunnen hackers ook toegang krijgen tot verschillende systemen met deze wachtwoorden.
Andere keren vertrouwen mensen op zwakke wachtwoorden die, zelfs zonder onbedoelde blootstelling, gemakkelijk kunnen worden gekraakt, wat leidt tot gebrekkige toegangscontrole.
En dit is zonder opzettelijke aanvallen op toegangscontrole, wat een heel ander dier is.
Voorbeelden van gebrekkige toegangscontrole
De mogelijke aanvalsvectoren die hackers kunnen gebruiken om toegangscontrole te breken zijn te veel om op te noemen. Dat gezegd hebbende, werken ze meestal volgens dezelfde principes.
Mislukking bij het beperken van URL-toegang
De meest voorkomende aanval op toegangscontrole vindt plaats wanneer een URL authenticatie omzeilt, waardoor het systeem wordt misleid dat het al geauthenticeerd is. Gebruikmakend van kennis van formaten en patronen, kunnen hackers de URL schrijven voor bevoorrechte pagina’s die niet correct zijn geconfigureerd.
Om u een voorbeeld te geven, stel u een kleine vis voor die inlogt. Zijn hoofdpagina zou er ongeveer zo uitzien:
https://webdevsagainsthackers.net/fish_login.htmlZiet u iets verdachts (deze keer opzettelijk)? De URL toont fish_login.html als hoofdpagina.
Alles wat hackers in dit geval hoeven te doen om volledige haai-toegang te krijgen, is de URL als volgt in te voeren:
https://webdevsagainsthackers.net/shark_login.htmlOp dit punt hebben de aanvallers haai-toegang verkregen door niets meer te doen dan de URL te wijzigen. Makkelijk? Zeker. Maar desalniettemin effectief tegen onervaren ontwikkelaars.
Onveilige directe objectreferenties (IDOR)
Dit is iets ingewikkelder. U ziet, er zijn meerdere manieren waarop kwaadwillende actoren toegang kunnen krijgen tot de harde code in een webapplicatie. Delen van die code kunnen onthullen hoe uw database is georganiseerd met betrekking tot formattering, patronen en meer. Met slechts deze paar stukjes kunnen bekwame hackers meer informatie blootleggen voor verdere onderzoekingen.
Bij de volgende toegang logt u in op uw account op een website en bekijkt u de hoofdpagina. In de adresbalk ziet u een URL als deze:
https://webdevsagainsthackers.net/index.php/view?account=4200Wat hebben we hier? Iets dat lijkt op een lange accountlijst, en u bent nummer 4200 in de database.
Op het eerste gezicht niets verdachts. Maar alles wat een kwaadwillende actor hoeft te doen om toegang te krijgen tot accounts van andere gebruikers, is een ander accountnummer invoeren. Soms (vaker dan zou moeten) zijn de accounts van de beheerder toegewezen aan de eerste 1-10 nummers. Dus, u draait het als volgt:
https://webdevsagainsthackers.net/index.php/view?account=1en de verkeerde gebruikers kunnen toegang krijgen tot beheerdersaccounts.
*“Wacht even, dat ziet er niet (noch klinkt het) anders uit dan de vorige aanval?”* U heeft gelijk. Maar ook ongelijk.
Het verschil hier is dat hackers in dit geval objectreferenties misbruiken. De meeste webapplicaties gebruiken standaard paginanamen op basis van de MVC (model, view, en controller) opzet. Omdat dat het geval is, kunnen hackers toegang krijgen tot de broncode van deze webapplicaties.
Beschouw de sectie *Over ons* die de meeste websites hebben. Het onderstaande adres toont dat alle pagina’s eindigen op .htm (of iets dergelijks):
https://webdevsagainsthackers.net/against/default.aspx?content=about_us.htmDe hackers weten dat het default.aspx.cs-deel de hoofdpagina is en *mogelijk* verder wil *onderzoeken*.
Met behulp van een null-byte (./) aanval kunnen ze de browsercode misleiden om te geloven dat de URL compleet is. De tekenreeks na de null-byte stelt aanvallers in staat te onthullen wat er in elk geschreven bestand staat:
https://webdevsagainsthackers.net/against/default.aspx?content=%20./default.aspx.cs%00.htm
In dit voorbeeld hebben de hackers toegang gekregen tot een volledige pagina broncode van default.aspx.cs. Natuurlijk is dit mogelijk met elke standaard paginanaam.
Directe objectreferenties kunnen ook opduiken in een foutcode. Alles wat hackers hoeven te doen, is vermeldingen manipuleren om erachter te komen welke uitzonderingen/fouten er kunnen optreden en wat ze kunnen zeggen. Het geeft hen meer informatie die ze in de URL moeten zoeken.
Echte voorbeelden van BAC
Gezien het feit dat BAC de belangrijkste bedreiging voor softwarebeveiliging van vandaag is, zijn zelfs de grootste media-imperia in het verleden niet gespaard gebleven. Dit zijn slechts enkele voorbeelden:
Snapchat. Gibson Security heeft toegangscontrolekwetsbaarheden in het Snapchat-systeem ontdekt die aanvankelijk als onbelangrijk werden afgedaan. Niet meer dan een week later onthulden brute force enumeraties 4,6 miljoen gebruikersnamen en telefoonnummers. Het behoeft geen betoog dat de getroffen gebruikers helemaal niet blij waren met de datalek.
Facebook Bedrijfspagina’s. Laxman Muthiyah ontdekte dat kwaadwillende gebruikers een verzoek konden indienen om zichzelf beheerdersrechten toe te kennen voor bepaalde Facebook-pagina’s. Omdat Facebook geen veilige toegangscontrolemaatregelen had getroffen, hoefden hackers alleen maar een verzoek te gebruiken zoals dit:
Request :-
POST //userpermissions HTTP/1.1
Host : graph.facebook.com
Content-Length: 245
role=MANAGER&user=&business=&access_token=
Response :-
true
en ze maakten zichzelf beheerder van de pagina. Zoals u zich kunt voorstellen, konden ze met dit nieuw verworven privilege de toegang voor de daadwerkelijke beheerders/managers van de pagina ontzeggen.
Hoe BAC te voorkomen
Om effectieve toegangscontrole te garanderen, moet u er eerst voor zorgen dat het systeem dit afdwingt via vertrouwde server-side code of serverloze API. Door dit te doen, kunt u voorkomen dat hackers de toegangscontrolecheck of metadata wijzigen.
Daarnaast helpen de volgende stappen u om gebrekkige toegangscontrole te voorkomen:
- Controleer machtigingen en zorg ervoor dat ze kloppen. Uiteraard zit de truc hem in grondigheid, waarbij elk bestand wordt gecontroleerd. Bij twijfel, volg het *principe van minimale rechten*: zorg ervoor dat alleen de mensen die specifieke bestanden moeten kunnen bewerken, *schrijftoegang* tot die bestanden hebben.
- Schakel client-side caching uit op beperkte pagina’s. Anders kunnen ongeautoriseerde gebruikers mogelijk opnieuw toegang krijgen tot deze pagina’s.
- Vermijd zogenaamde *presentatie toegangscontrole* mechanismen. Alleen omdat er geen zichtbare knop is die gebruikers naar beperkte pagina’s leidt, betekent niet dat aanvallers het niet kunnen vinden. Het is in feite *beveiliging door obscuriteit*, een principe dat NIET standhoudt tegen serieuze hackers. Vergrendel gevoelige pagina’s in plaats daarvan achter authenticatie.
- Weiger standaard toegang tot alle functies. Op die manier heeft u het gemakkelijker om machtigingen op orde te houden. Zorg er ook voor dat u toegangscontrollelijsten en op rollen gebaseerde authenticatiepraktijken gebruikt.
- Geef doelpagina’s geen betekenisvolle namen. Als u dat doet, helpt u indringers ze te identificeren. Gebruik in plaats daarvan key-value paren die verwijzen naar de objecten.
Snelle samenvatting
U verdient niet de nummer 1-positie op de lijst met softwarebeveiligingsdreigingen zonder serieuze schade aan te richten en nog meer schade in de toekomst mogelijk te maken. Tenzij we het nog niet overduidelijk hebben gemaakt – u moet de gebrekkige toegangscontrole dreiging respecteren, anders vindt u het alternatief misschien niet leuk. Toch, mits u weet waarmee u te maken heeft, hoe u het kunt voorkomen en hoe u BAC kunt bestrijden, zou het goed moeten komen.
Veilige toegangscontrole: de ultieme cheat sheet voor BAC-preventie
