så här säkerställer du REST API-säkerhet

API: er (Web application programming interfaces) ger baksidan för moderna webb-och mobilapplikationer. Webb-API-samtal står för över 80% av all webbtrafik och cyberbrottslingar riktar sig alltmer mot API: er, så att säkerställa webb-API-säkerhet är avgörande. REST API: er är den vanligaste typen av webb-API för webbtjänster. Låt oss se vad du kan göra för att säkerställa REST API-säkerhet.

Vad är ett REST API?

REST (förkortning för REpresentational State Transfer) är en mjukvaruarkitektur stil för webbutveckling, vanligtvis används med HTTP-kommunikation. RESTful API: er (eller helt enkelt REST API: er) är applikationsprogrammeringsgränssnitt som följer REST-principer, vilket gör att webbklienter och servrar kan interagera med ett stort antal webbresurser. REST API: er använder standard HTTP-verb (metoder) och statuskoder för att ge en viss nivå av standardisering. De nås via HTTP-webbadresser och används ofta för webbtjänster.

notera: REST API: er är statslösa som HTTP-protokollet i sig, vilket innebär att de inte lagrar någon information om aktuella anslutningar eller sessioner. RESTful webbtjänster ger sätt att komma åt och manipulera resurser, medan sessionshantering ska hanteras av applikationen.

två nivåer av REST API-säkerhet

innan vi går in i de tekniska detaljerna finns det en viktig sak att notera. Ett webb-API exponerar ett gränssnitt för en webbapplikation, så du måste tänka på säkerhet på två nivåer: åtkomst till API och sedan åtkomst till applikationen.

på API-nivån behöver du korrekt autentisering, auktorisering, åtkomstbehörighet och så vidare för att säkerställa att endast tillåtna klienter kan använda gränssnittet och endast utföra tillåtna operationer. På applikationsnivå måste du se till att dina applikationsändpunkter (webbadresserna som används för att komma åt gränssnittet) inte är sårbara för attacker som går igenom gränssnittet eller kringgår det.

Låt oss se hur du kan säkerställa REST API-säkerhet på dessa två nivåer. För en detaljerad diskussion om bästa praxis för API-säkerhet, se OWASP REST Security Cheat Sheet.

säkerställande av säker API-åtkomst

de flesta webb-API: er exponeras för Internet, så de behöver lämpliga säkerhetsmekanismer för att förhindra missbruk, skydda känslig data och se till att endast autentiserade och auktoriserade användare kan komma åt dem.

anslutningssäkerhet

säkerhet börjar med själva HTTP-anslutningen. Säkra REST API: er bör endast tillhandahålla HTTPS-slutpunkter för att säkerställa att all API-kommunikation krypteras med SSL/TLS. Detta gör det möjligt för kunder att autentisera tjänsten och skyddar API-referenser och överförda data.

API-åtkomstkontroll

många webb-API: er är endast tillgängliga för autentiserade användare, till exempel för att de är privata eller kräver registrering eller betalning. Eftersom REST API: er är statslösa hanteras åtkomstkontroll av lokala slutpunkter. De vanligaste REST API-autentiseringsmetoderna är:

• HTTP Basic Authentication: autentiseringsuppgifter skickas direkt i HTTP-rubriker i Base64-kodning utan kryptering. Detta är den enklaste autentiseringsmetoden och det enklaste att implementera. Det är också det minst säkra, eftersom konfidentiella data överförs som vanlig text, så det bör endast användas i kombination med HTTPS.
• JSON Web Tokens( JWT): referenser och andra åtkomstparametrar skickas som JSON datastrukturer. Dessa åtkomsttoken kan signeras kryptografiskt och är det föredragna sättet att kontrollera åtkomst till REST API: er. Se OWASP JWT Cheat Sheet för en snabb översikt över JSON Web Tokens och RFC 7519 för fullständig specifikation.
• OAuth: Standard OAuth 2.0-mekanismer kan användas för autentisering och auktorisering. OpenID Connect möjliggör säker autentisering via OAuth 2.0. Till exempel använder Googles API: er OAuth 2.0 för autentisering och auktorisering.

användarbehörighet med API-nycklar

API-nycklar ger ett sätt att kontrollera åtkomst till offentliga REST-tjänster. Operatörer av offentliga webbtjänster kan använda API-nycklar för att genomdriva hastighetsbegränsande för API-samtal och mildra denial-of-service-attacker. För intäktsgenererade tjänster kan organisationer använda API-nycklar för att ge åtkomst baserat på den köpta åtkomstplanen.

API-Klientbegränsningar

för att minimera säkerhetsrisker bör REST-tjänsteoperatörer begränsa anslutningen av klienter till de minimifunktioner som krävs för tjänsten. Detta börjar med att begränsa HTTP-metoder som stöds för att se till att felkonfigurerade eller skadliga klienter inte kan utföra några åtgärder utöver API-specifikationen och tillåten åtkomstnivå. Till exempel, om API endast tillåter GET-förfrågningar, bör POST och andra förfrågningstyper avvisas med svarskoden 405-Metoden inte tillåten.

skydda program som exponerar API: er

när klienten har legitim åtkomst måste du skydda den underliggande webbapplikationen från felaktiga och skadliga ingångar. REST API-anrop och svar kan också innehålla konfidentiella uppgifter som måste kontrolleras.

känsliga Data i API-kommunikation

API-anrop innehåller ofta referenser, API-nycklar, sessionstoken och annan känslig information. Om de ingår direkt i webbadresser kan dessa uppgifter lagras i webbserverloggar och läckas om loggarna nås av cyberbrottslingar. För att undvika att läcka konfidentiell information ska RESTful web services alltid skicka den i HTTP-förfrågningsrubriker eller begäran (för post-och PUT-förfrågningar).

validering av innehållstyp

fortsatt temat för API-klientbegränsningar bör REST-tjänster exakt definiera tillåtna innehållstyper och avvisa förfrågningar som inte har rätt deklarationer i sina HTTP-rubriker. Detta innebär att du noggrant anger tillåtna typer i både Content-Type och Accept – rubriken, tillsammans med teckenuppsättningen (om möjligt). Om tjänsten innehåller JavaScript (eller annan skriptkod) bör den se till att innehållstypen i rubriken är densamma som i begäran, till exempel application/javascript. Detta hjälper till att förhindra huvudinjektionsattacker.

Svarssäkerhetsrubriker

ytterligare HTTP-säkerhetsrubriker kan ställas in för att ytterligare begränsa typen och omfattningen av förfrågningar. Dessa inkluderar X-Content-Type-Options: nosniff för att förhindra XSS-attacker baserade på MIME-sniffning och X-Frame-Options: deny för att förhindra clickjacking-försök i äldre webbläsare.

om tjänsten inte stöder domänöverskridande samtal bör den inaktivera CORS (cross-origin resource sharing) i sina svarhuvuden. Om sådana samtal förväntas bör CORS-rubrikerna exakt ange det tillåtna ursprunget.

input Validation

API: er är utformade för automatiserad åtkomst utan användarinteraktion, så det är särskilt viktigt att se till att alla ingångar är giltiga och förväntade. Alla förfrågningar som inte överensstämmer med API-specifikationen måste avvisas. Typiska riktlinjer för bästa praxis för validering av indata gäller:

• behandla alla parametrar, objekt och andra indata som otillförlitliga.
• Använd inbyggd valideringsfunktion när den är tillgänglig.
• kontrollera begäran storlek och innehåll längd och typ.
• Använd stark typning för API-parametrar (om det stöds).
• för att förhindra SQL-injektion, undvik att bygga frågor manuellt-använd parametriserade frågor istället.
• vitlista parametervärden och strängingångar där det är möjligt.
• logga alla inmatningsvalideringsfel för att upptäcka autentiseringsförsök.

varför REST API-säkerhet är viktigt

webb-API: er är ryggraden i modern webb-och mobilutveckling. De tillåter applikationer och tjänster att kommunicera och utbyta data över hårdvaru-och mjukvaruplattformar. Medan andra API-format fortfarande används (till exempel SOAP) är REST-API: er nu den dominerande typen och står för över 80% av alla offentliga webb-API: er. De ger baksidan för de flesta mobila applikationer och IoT-enheter och möjliggör enkel integration mellan system och applikationer.

eftersom de använder samma teknik som webbapplikationer kan REST API: er vara sårbara för samma attacker. Samtidigt är API: er inte utformade för manuell åtkomst, så de kan vara svåra att testa, särskilt om vissa slutpunkter och funktioner är odokumenterade. API – säkerhetstestning kräver exakta automatiserade verktyg för att säkerställa fullständig täckning. Netsparker ger fullt stöd för REST API sårbarhetsskanning med en mängd olika autentiseringsmetoder och automatisk URL-omskrivning.

se dokumentationen för testplatsen för Netsparker REST API för fullständiga tekniska detaljer och läs vår fullständiga artikel om att skanna REST API: er för sårbarheter med Netsparker.

om författaren

Zbigniew Banach

teknisk innehållsförfattare på Netsparker. Med sin erfarenhet som IT-journalist och teknisk översättare gör han sitt bästa för att ge webbsäkerhet till en bredare publik på Netsparkers blogg och webbplats.