Top OATH API-kwetsbaarheden
Top OATH API-kwetsbaarheden: inleiding
Als het om exploits gaat, zijn API's de beste plek om te beginnen. API toegang bestaat meestal uit drie delen. Clients krijgen tokens uitgegeven door een autorisatieserver, die naast API's draait. De API ontvangt toegangstokens van de client en past op basis daarvan domeinspecifieke autorisatieregels toe.
Moderne softwaretoepassingen zijn kwetsbaar voor verschillende gevaren. Blijf op de hoogte van de meest recente exploits en beveiligingsfouten; het hebben van benchmarks voor deze kwetsbaarheden is essentieel om de beveiliging van applicaties te verzekeren voordat er een aanval plaatsvindt. Toepassingen van derden vertrouwen steeds meer op het OAuth-protocol. Gebruikers zullen dankzij deze technologie een betere algehele gebruikerservaring hebben, evenals sneller inloggen en autorisatie. Het kan veiliger zijn dan conventionele autorisatie, aangezien gebruikers hun inloggegevens niet hoeven bekend te maken aan de toepassing van derden om toegang te krijgen tot een bepaalde bron. Hoewel het protocol zelf veilig is, kan de manier waarop het is geïmplementeerd u vatbaar maken voor aanvallen.
Bij het ontwerpen en hosten van API's richt dit artikel zich op typische OAuth-kwetsbaarheden, evenals verschillende beveiligingsbeperkingen.
Autorisatie op objectniveau verbroken
Er is een enorm aanvalsoppervlak als autorisatie wordt geschonden, aangezien API's toegang bieden tot objecten. Aangezien API-toegankelijke items moeten worden geverifieerd, is dit noodzakelijk. Implementeer autorisatiecontroles op objectniveau met behulp van een API-gateway. Alleen degenen met de juiste machtigingsreferenties mogen toegang krijgen.
Verbroken gebruikersauthenticatie
Ongeautoriseerde tokens zijn een andere veel voorkomende manier voor aanvallers om toegang te krijgen tot API's. Verificatiesystemen kunnen worden gehackt of een API-sleutel kan per ongeluk worden vrijgegeven. Authenticatietokens kunnen zijn gebruikt door hackers toegang te krijgen. Verifieer mensen alleen als ze te vertrouwen zijn en gebruik sterke wachtwoorden. Met OAuth kunt u verder gaan dan alleen API-sleutels en krijgt u toegang tot uw gegevens. Je moet altijd nadenken over hoe je ergens in en uit gaat. OAuth MTLS Sender Constrained Tokens kunnen worden gebruikt in combinatie met Mutual TLS om te garanderen dat clients zich niet misdragen en geen tokens doorgeven aan de verkeerde partij terwijl ze toegang krijgen tot andere machines.
API-promotie:
Overmatige blootstelling aan gegevens
Er zijn geen beperkingen op het aantal eindpunten dat mag worden gepubliceerd. Meestal zijn niet alle functies beschikbaar voor alle gebruikers. Door meer gegevens bloot te leggen dan absoluut noodzakelijk is, brengt u uzelf en anderen in gevaar. Vermijd het onthullen van gevoeligheden informatie totdat het absoluut noodzakelijk is. Ontwikkelaars kunnen specificeren wie toegang heeft tot wat door gebruik te maken van OAuth-bereiken en -claims. Claims kunnen specificeren tot welke delen van de gegevens een gebruiker toegang heeft. Toegangscontrole kan eenvoudiger en gemakkelijker te beheren worden gemaakt door een standaardstructuur voor alle API's te gebruiken.
Gebrek aan bronnen en snelheidsbeperking
Black hats gebruiken vaak denial-of-service (DoS)-aanvallen als een brute manier om een server te overweldigen en zo de uptime tot nul terug te brengen. Zonder beperkingen op de bronnen die kunnen worden aangeroepen, is een API kwetsbaar voor een slopende aanval. 'Met behulp van een API-gateway of beheertool kunt u tariefbeperkingen instellen voor API's. Filtering en paginering moeten worden opgenomen, en antwoorden moeten worden beperkt.
Verkeerde configuratie van het beveiligingssysteem
Verschillende richtlijnen voor beveiligingsconfiguratie zijn redelijk uitgebreid, vanwege de grote kans op verkeerde configuratie van de beveiliging. Een aantal kleine dingen kunnen de beveiliging van uw platform in gevaar brengen. Het is mogelijk dat zwarte hoeden met bijbedoelingen bijvoorbeeld gevoelige informatie ontdekken die is verzonden als reactie op verkeerd opgemaakte vragen.
Massa-toewijzing
Alleen omdat een eindpunt niet openbaar is gedefinieerd, wil nog niet zeggen dat het niet toegankelijk is voor ontwikkelaars. Een geheime API kan gemakkelijk worden onderschept en omgekeerd door hackers. Kijk eens naar dit eenvoudige voorbeeld, dat een open Bearer Token gebruikt in een "privé" API. Aan de andere kant kan er openbare documentatie bestaan voor iets dat uitsluitend bedoeld is voor persoonlijk gebruik. Blootgestelde informatie kan door zwarte hoeden worden gebruikt om objectkenmerken niet alleen te lezen maar ook te manipuleren. Beschouw jezelf als een hacker terwijl je zoekt naar mogelijke zwakke punten in je verdediging. Geef alleen degenen met de juiste rechten toegang tot wat is geretourneerd. Beperk het API-responspakket om de kwetsbaarheid te minimaliseren. Respondenten mogen geen links toevoegen die niet absoluut vereist zijn.
Gepromoveerde API:
Onjuist vermogensbeheer
Afgezien van het verbeteren van de productiviteit van ontwikkelaars, zijn actuele versies en documentatie essentieel voor uw eigen veiligheid. Bereid u ruim van tevoren voor op de introductie van nieuwe versies en de afschaffing van oude API's. Gebruik nieuwere API's in plaats van oudere API's in gebruik te laten blijven. Een API-specificatie kan worden gebruikt als een primaire bron van waarheid voor documentatie.
Injectie
API's zijn kwetsbaar voor injectie, maar dat geldt ook voor apps van derden. Kwaadaardige code kan worden gebruikt om gegevens te verwijderen of vertrouwelijke informatie te stelen, zoals wachtwoorden en creditcardnummers. De belangrijkste les die je hieruit kunt trekken, is om niet afhankelijk te zijn van de standaardinstellingen. Uw beheer- of gatewayleverancier moet in staat zijn om aan uw unieke applicatiebehoeften te voldoen. Foutberichten mogen geen gevoelige informatie bevatten. Om te voorkomen dat identiteitsgegevens buiten het systeem lekken, moeten Pairwise Pseudoniemen in tokens worden gebruikt. Dit zorgt ervoor dat geen enkele client kan samenwerken om een gebruiker te identificeren.
Onvoldoende logboekregistratie en monitoring
Als er toch een aanval plaatsvindt, hebben teams een goed doordachte reactiestrategie nodig. Ontwikkelaars zullen kwetsbaarheden blijven misbruiken zonder gepakt te worden als er geen betrouwbaar registratie- en monitoringsysteem is, wat de verliezen zal vergroten en de publieke perceptie van het bedrijf zal schaden. Hanteer een strikte strategie voor API-monitoring en productie-eindpunttesten. White hat-testers die in een vroeg stadium kwetsbaarheden ontdekken, moeten worden beloond met een premieregeling. Het logboekspoor kan worden verbeterd door de identiteit van de gebruiker op te nemen in API-transacties. Zorg ervoor dat alle lagen van uw API-architectuur worden gecontroleerd met behulp van Access Token-gegevens.
Conclusie
Platformarchitecten kunnen hun systemen uitrusten om aanvallers een stap voor te blijven door vastgestelde kwetsbaarheidscriteria te volgen. Omdat API's toegang kunnen bieden tot persoonlijk identificeerbare informatie (PII), is het handhaven van de beveiliging van dergelijke services van cruciaal belang voor zowel de bedrijfsstabiliteit als de naleving van wetgeving zoals de AVG. Verzend nooit OAuth-tokens rechtstreeks via een API zonder een API-gateway en de Phantom Token-benadering te gebruiken.
Gepromoveerde API:
