Hoe beveilig ik REST API-aanroepen?

Ik ontwikkel de rustgevende web-app die gebruik maakt van een populair webframework op de backend, bijvoorbeeld (rails, sinatra, flask, express.js). Idealiter wil ik de clientzijde ontwikkelen met Backbone.js. Hoe laat ik alleen mijn javascript-clientzijde communiceren met die API-aanroepen? Ik wil niet dat die API-aanroepen openbaar zijn en worden aangeroepen door curlof gewoon door de link in de browser in te voeren.

Antwoord 1, autoriteit 100%

Als eerste principe, als uw API wordt gebruikt door uw JS-client, moet u ervan uitgaan dat deze openbaar is: een eenvoudige JS-debugger plaatst een aanvaller in een positie waar hij een byte-voor-byte identieke verzoek van een tool naar keuze.

Dat gezegd hebbende, als ik uw vraag goed heb gelezen, is dit niet wat u wilt vermijden: wat u echt niet wilt dat er gebeurt, is dat uw API (regelmatig) wordt verbruikt zonder dat uw JS-client betrokken. Hier zijn enkele ideeën over hoe u, indien niet afdwingen, in ieder geval kunt aanmoedigen om uw cliënt te gebruiken:

• Ik weet zeker dat uw API een soort authenticatieveld heeft (bijv. Hash berekend op de client). Zo niet, bekijk dan Deze SO-vraag. Zorg ervoor dat je een salt (of zelfs een API-sleutel) gebruikt die aan je JS-client wordt gegeven op een sessiebasis (o.a. hardcoded). Op deze manier wordt een niet-geautoriseerde gebruiker van uw API tot veel meer werk gedwongen.

• Onthoud bij het laden van de JS-client enkele HTTP-headers (denk aan user-agent) en het IP-adres en vraag om herauthenticatie als ze veranderen, waarbij u zwarte lijsten gebruikt voor de gebruikelijke verdachten. Dit dwingt een aanvaller om zijn huiswerk opnieuw grondiger te doen.

• Onthoud aan de serverzijde de laatste paar API-aanroepen, en controleer voordat u een andere toestaat of de bedrijfslogica de nieuwe toestaat: dit ontneemt een aanvaller de mogelijkheid om veel van zijn sessies in één sessie te concentreren sessie met uw server: in combinatie met de andere maatregelen maakt dit een misbruiker gemakkelijk detecteerbaar.

Ik heb dat misschien niet met de nodige duidelijkheid gezegd: ik beschouw het onmogelijkom het een misbruiker volledig onmogelijk te maken om je dienst te gebruiken, maar je kunt het zo moeilijk maken, misschien is het niet zo de moeite waard.

Antwoord 2, autoriteit 12%

Je zou een soort authenticatiesysteem moeten implementeren. Een goede manier om hiermee om te gaan, is door enkele verwachte kopvariabelen te definiëren. U kunt bijvoorbeeld een auth/login API-aanroep hebben die een sessietoken retourneert. Daaropvolgende aanroepen van uw API verwachten dat een sessietoken wordt ingesteld in een HTTP-headervariabele met een specifieke naam zoals ‘your-api-token’.

Als alternatief maken veel systemen toegangstokens of sleutels die worden verwacht (zoals YouTube, Facebook of Twitter) met behulp van een soort api-accountsysteem. In die gevallen zou uw cliënt deze op de een of andere manier in de cliënt moeten opslaan.

Dan is het gewoon een kwestie van een controle voor de sessie toevoegen aan je REST-framework en een uitzondering maken. Als het enigszins mogelijk is, zou de statuscode (om rustgevend te zijn) een 401-fout zijn.

Antwoord 3, autoriteit 8%

Er is nu een open standaard genaamd “JSON Web Token”,

zie https://jwt.io/& https://en.wikipedia.org/wiki/JSON_Web_Token

JSON Web Token (JWT) is een op JSON gebaseerde open standaard (RFC 7519) voor
tokens maken die een aantal claims doen gelden. Bijvoorbeeld, een
server kan een token genereren met de claim “aangemeld als beheerder”
en dat aan een cliënt verstrekken. De klant zou dat token dan kunnen gebruiken om
bewijzen dat ze zijn ingelogd als admin. De penningen zijn ondertekend door de
serversleutel, zodat de server kan verifiëren dat het token is
rechtmatig. De tokens zijn ontworpen om compact, URL-veilig en bruikbaar te zijn
vooral in de context van eenmalige aanmelding (SSO) van een webbrowser. JWT beweert kan
worden doorgaans gebruikt om de identiteit van geverifieerde gebruikers door te geven tussen
identiteitsprovider en een serviceprovider, of enig ander type claim
zoals vereist door bedrijfsprocessen. [1][2] De tokens kunnen ook zijn:
geauthenticeerd en versleuteld.[3][4]

Antwoord 4

Excuseer me @MarkAmery en Eugene, maar dat is onjuist.

Uw js+html (client)-app die in de browser wordt uitgevoerd, KAN als volgt worden ingesteld om ongeautoriseerdedirecte aanroepen naar de API uit te sluiten:

1. Eerste stap: stel de API in om verificatie te vereisen. De client moet zich eerst authenticeren via de server (of een andere beveiligingsserver), bijvoorbeeld door de menselijke gebruiker te vragen om het juiste wachtwoord op te geven.

Vóór authenticatie worden de oproepen naar de API niet geaccepteerd.

Tijdens authenticatie wordt een “token” geretourneerd.

Na authenticatie worden alleen API-aanroepen met de authenticatie “token” geaccepteerd.

Natuurlijk hebben in dit stadium alleen geautoriseerde gebruikers met het wachtwoord toegang tot de API, maar als het programmeurs zijn die de app debuggen, hebben ze er direct toegang toe voor testdoeleinden.

2. Tweede stap: Stel nu een extra beveiligings-API in, die moet worden aangeroepen binnen een korte tijd nadat de client js+html-app in eerste instantie is aangevraagd bij de server. Deze “callback” zal de server vertellen dat de client succesvol is gedownload. Beperk uw REST API-aanroepen om alleen te werken als de client onlangs en met succes is aangevraagd.

Om uw API nu te kunnen gebruiken, moeten ze eerst de client downloaden en daadwerkelijk in een browser uitvoeren. Pas na het succesvol ontvangen van de callback, en vervolgens binnen een kort tijdsbestek van de gebruiker, zal de API calls accepteren.

U hoeft zich dus geen zorgen te maken dat dit een onbevoegde gebruiker zonder inloggegevens kan zijn.

(De titel van de vraag, ‘Hoe beveilig ik REST API-aanroepen’, en van het meeste van wat u zegt, is dat uw grootste zorg, en niet de letterlijke vraag HOE uw API wordt aangeroepen, maar eerder DOOR WIE , juist?)

Antwoord 5

Dit is wat ik doe:

1. Beveilig de API met een HTTP-header met aanroepen zoals X-APITOKEN:

2. Gebruik sessievariabelen in PHP. Zorg voor een inlogsysteem en sla het gebruikerstoken op in sessievariabelen.

3. Bel JS-code met Ajax naar PHP en gebruik de sessievariabele met curl om de API aan te roepen. Op die manier, als de sessievariabele niet is ingesteld, zal deze niet aanroepen en bevat de PHP-code het toegangstoken tot de API.