Web application programming interfaces (API ‘ s) bieden de back-end voor moderne web-en mobiele applicaties. Web API-oproepen zijn goed voor meer dan 80% van al het webverkeer en cybercriminelen zijn steeds meer gericht op API ‘ s, dus het waarborgen van web API-beveiliging is cruciaal. REST API ‘ s zijn de meest voorkomende vorm van web API voor web services. Laten we eens kijken wat je kunt doen om de veiligheid van de REST API te garanderen.
- Wat Is een REST API?
- twee niveaus van REST API beveiliging
- zorgen voor veilige API-toegang
- verbindingsbeveiliging
- API-Toegangscontrole
- Gebruikersautorisatie met API-sleutels
- beperkingen voor API-clients
- toepassingen beschermen die API ‘ s
- gevoelige gegevens in API-communicatie
- validatie van inhoudstype
- Antwoordbeveiligingsheaders
- invoervalidatie
- waarom REST API-beveiliging belangrijk is
- over de auteur
Wat Is een REST API?
REST (afkorting voor REpresentational State Transfer) is een softwarearchitectuurstijl voor webontwikkeling, meestal gebruikt met HTTP-communicatie. RESTful API ’s (of gewoon REST API’ s) zijn applicatieprogrammeerinterfaces die de REST-principes volgen, waardoor webclients en servers kunnen communiceren met een grote verscheidenheid aan webbronnen. REST API ‘ s gebruiken standaard HTTP-werkwoorden (methoden) en statuscodes om enige mate van standaardisatie te bieden. Ze worden benaderd via HTTP-URL ‘ s en worden veel gebruikt voor webservices.
Noot: REST API ‘ s zijn stateloos zoals het HTTP-protocol zelf, wat betekent dat ze geen informatie over de huidige verbindingen of sessies op te slaan. RESTful webservices bieden manieren om bronnen te openen en te manipuleren, terwijl sessiebeheer door de toepassing moet worden afgehandeld.
twee niveaus van REST API beveiliging
voordat we ingaan op de technische details, is er een belangrijk ding om op te merken. Een web API stelt een interface bloot aan een webapplicatie, dus je moet nadenken over beveiliging op twee niveaus: toegang tot de API en vervolgens toegang tot de applicatie.
op API-niveau hebt u de juiste authenticatie, autorisatie, toegangsrechten enzovoort nodig om ervoor te zorgen dat alleen toegestane clients de interface kunnen gebruiken en alleen toegestane bewerkingen kunnen uitvoeren. Op applicatieniveau moet u ervoor zorgen dat de eindpunten van uw applicatie (de URL ‘ s die worden gebruikt om toegang te krijgen tot de interface) niet kwetsbaar zijn voor aanvallen die via de interface komen of deze omzeilen.
laten we eens kijken hoe je de REST API-beveiliging op deze twee niveaus kunt garanderen. Voor een gedetailleerde bespreking van de beste praktijken voor API-beveiliging, zie de OWASP REST Security Cheat Sheet.
zorgen voor veilige API-toegang
de meeste web-API ‘ s worden blootgesteld aan het Internet, dus hebben ze geschikte beveiligingsmechanismen nodig om misbruik te voorkomen, gevoelige gegevens te beschermen en ervoor te zorgen dat alleen geauthenticeerde en geautoriseerde gebruikers toegang hebben.
verbindingsbeveiliging
beveiliging begint met de HTTP-verbinding zelf. Secure REST API ‘ s mogen alleen https-eindpunten bieden om ervoor te zorgen dat alle API-communicatie wordt versleuteld met SSL/TLS. Dit stelt clients in staat om de service te verifiëren en beschermt de API-referenties en verzonden gegevens.
API-Toegangscontrole
veel web-API ‘ s zijn alleen beschikbaar voor geverifieerde gebruikers, bijvoorbeeld omdat ze privé zijn of registratie of betaling vereisen. Omdat REST API ‘ s staatloos zijn, wordt Toegangscontrole afgehandeld door lokale eindpunten. De meest voorkomende REST API authenticatie methoden zijn:
- HTTP Basic Authentication: referenties worden rechtstreeks verzonden in HTTP-headers in Base64-codering zonder encryptie. Dit is de eenvoudigste verificatiemethode en het makkelijkst te implementeren. Het is ook het minst veilig, omdat vertrouwelijke gegevens worden verzonden als platte tekst, dus het mag alleen worden gebruikt in combinatie met HTTPS.
- JSON Web Tokens (JWT): referenties en andere toegangsparameters worden verzonden als JSON data structures. Deze access tokens kunnen cryptografisch worden ondertekend en zijn de beste manier om de toegang tot REST API ‘ s te controleren. Zie de OWASP JWT Cheat Sheet voor een snel overzicht van JSON Web Tokens, en RFC 7519 voor de volledige specificatie.
- OAuth: standaard OAuth 2.0-mechanismen kunnen worden gebruikt voor authenticatie en autorisatie. OpenID Connect maakt veilige authenticatie via OAuth 2.0 mogelijk. De API ‘ s van Google gebruiken bijvoorbeeld OAuth 2.0 voor verificatie en autorisatie.
Gebruikersautorisatie met API-sleutels
API-sleutels bieden een manier om de toegang tot openbare RESTDIENSTEN te controleren. Exploitanten van openbare webservices kunnen API-sleutels gebruiken om snelheidsbeperkingen voor API-oproepen af te dwingen en denial-of-service-aanvallen te beperken. Voor gelde gemaakte services kunnen organisaties API-sleutels gebruiken om toegang te bieden op basis van het gekochte toegangsplan.
beperkingen voor API-clients
om veiligheidsrisico ‘ s te minimaliseren, moeten exploitanten van RESTDIENSTEN de verbindende clients beperken tot de minimale mogelijkheden die voor de dienst vereist zijn. Dit begint met het beperken van ondersteunde HTTP-methoden om ervoor te zorgen dat verkeerd geconfigureerde of kwaadaardige clients geen acties kunnen uitvoeren die verder gaan dan de API-specificatie en het toegestane toegangsniveau. Bijvoorbeeld, als de API alleen GET requests, POST en andere soorten aanvragen moeten worden afgewezen met de respons code 405 methode niet toegestaan.
toepassingen beschermen die API ‘ s
blootstellen zodra de client legitieme toegang heeft, moet u de onderliggende webtoepassing beschermen tegen misvormde en kwaadaardige invoer. REST API-oproepen en antwoorden kunnen ook vertrouwelijke gegevens bevatten die moeten worden gecontroleerd.
gevoelige gegevens in API-communicatie
API-aanroepen bevatten vaak referenties, API-sleutels, sessietokens en andere gevoelige informatie. Indien direct opgenomen in URL ‘ s, deze gegevens kunnen worden opgeslagen in webserver logs en gelekt als de logs worden geopend door cybercriminelen. Om het lekken van vertrouwelijke informatie te voorkomen, moeten RESTful web services deze altijd verzenden in HTTP request headers of de body van het verzoek (voor POST-en PUTVERZOEKEN).
validatie van inhoudstype
door het thema van API-clientbeperkingen voort te zetten, moeten REST-services de toegestane inhoudstypen nauwkeurig definiëren en verzoeken afwijzen die niet de juiste declaraties in hun HTTP-headers hebben. Dit betekent dat de toegestane typen in zowel de header Content-Type
als de header Accept
zorgvuldig moeten worden gespecificeerd, samen met de tekenset (waar mogelijk). Als de service JavaScript (of een andere scriptcode) bevat, moet het ervoor zorgen dat het inhoudstype in de header hetzelfde is als in de aanvraagtekst, bijvoorbeeld application/javascript
. Dit helpt om aanvallen met header-injectie te voorkomen.
Antwoordbeveiligingsheaders
extra HTTP-beveiligingsheaders kunnen worden ingesteld om het type en de reikwijdte van verzoeken verder te beperken. Deze omvatten X-Content-Type-Options: nosniff
om XSS-aanvallen op basis van MIME sniffing te voorkomen en X-Frame-Options: deny
om clickjacking-pogingen in oudere browsers te voorkomen.
als de service geen domeinoverschrijdende aanroepen ondersteunt, moet de service CORS (brondeling tussen verschillende oorsprong) uitschakelen in de responskoppen. Als dergelijke oproepen worden verwacht, moeten de CORS-headers de toegestane oorsprong nauwkeurig specificeren.
invoervalidatie
API ‘ s zijn ontworpen voor geautomatiseerde toegang zonder interactie met de gebruiker, dus het is vooral belangrijk om ervoor te zorgen dat alle invoer geldig en verwacht zijn. Verzoeken die niet voldoen aan de API-specificatie moeten worden afgewezen. Typische richtsnoeren voor beste praktijken voor inputvalidatie zijn van toepassing:
- behandel alle parameters, objecten en andere invoergegevens als niet vertrouwd.
- gebruik de ingebouwde validatiefunctionaliteit indien beschikbaar.
- controleer de grootte en inhoud van de aanvraag en het type.
- gebruik sterke typen voor API-parameters (indien ondersteund).
- om SQL-injectie te voorkomen, vermijd het handmatig opbouwen van query ‘s-gebruik in plaats daarvan geparametreerde query’ s.
- zet parameterwaarden en tekenreeksinvoer op de witte lijst waar mogelijk.
- Log alle invoervalidatiefouten in om pogingen tot het opvullen van referenties te detecteren.
waarom REST API-beveiliging belangrijk is
Web-API ‘ s zijn de ruggengraat van moderne web-en mobiele ontwikkeling. Hiermee kunnen applicaties en diensten communiceren en gegevens uitwisselen tussen hardware-en softwareplatforms. Terwijl andere API-formaten ook nog steeds in gebruik zijn (bijvoorbeeld SOAP), REST API ’s zijn nu het dominante type, goed voor meer dan 80% van alle openbare web API’ s. Ze bieden de back-end voor de meeste mobiele applicaties en IoT-apparaten en maken eenvoudige integratie tussen systemen en toepassingen mogelijk.
omdat zij dezelfde technologieën gebruiken als webapplicaties, kunnen REST-API ‘ s kwetsbaar zijn voor dezelfde aanvallen. Tegelijkertijd zijn API ‘ s niet ontworpen voor handmatige toegang, dus ze kunnen moeilijk te testen zijn, vooral als sommige eindpunten en functies zijn ongedocumenteerd. API-beveiligingstests vereisen nauwkeurige geautomatiseerde tools om volledige dekking te garanderen. Netsparker biedt volledige ondersteuning voor REST API kwetsbaarheid scannen met een verscheidenheid van authenticatie methoden en automatische URL herschrijven.
zie de Netsparker REST API test site documentatie voor volledige technische details en lees ons volledige artikel over het scannen van REST API ‘ s voor kwetsbaarheden met Netsparker.
over de auteur
Technical Content Writer bij Netsparker. Voortbouwend op zijn ervaring als IT-journalist en technisch vertaler, doet hij zijn best om webbeveiliging naar een breder publiek te brengen op de Netsparker blog en website.