Beste praktyke vir die beveiliging van 'n REST API / webdiens [gesluit]

StackOverflow https://stackoverflow.com/questions/7551

Vra

Is daar enige gevestigde beste praktyke vir die hantering van sekuriteit (stawing, magtiging, identiteitsbestuur) wanneer 'n REST API of diens ontwerp word?

Wanneer jy 'n SOAP API bou, het jy WS-Security as 'n gids en baie literatuur bestaan ​​oor die onderwerp.Ek het minder inligting oor die beveiliging van REST-eindpunte gevind.

Alhoewel ek verstaan ​​dat REST doelbewus nie spesifikasies analoog aan WS-* het nie, hoop ek dat beste praktyke of aanbevole patrone na vore gekom het.

Enige bespreking of skakels na relevante dokumente sal baie waardeer word.As dit saak maak, sal ons WCF gebruik met POX/JSON serialized boodskappe vir ons REST API's/Dienste wat gebou is met v3.5 van die .NET Framework.

Was dit nuttig?

Oplossing

Soos tweakt gesê het, is Amazon S3 'n goeie model om mee te werk.Hul versoekhandtekeninge het wel 'n paar kenmerke (soos die insluiting van 'n tydstempel) wat help om te beskerm teen beide toevallige en kwaadwillige herspeel van versoeke.

Die lekker ding van HTTP Basic is dat feitlik alle HTTP-biblioteke dit ondersteun.U sal natuurlik SSL in hierdie geval moet vereis, want die stuur van gewone tekswagwoorde oor die net is byna universeel 'n slegte ding.Basies is verkieslik bo Digest wanneer SSL gebruik word, want selfs al weet die beller reeds dat geloofsbriewe vereis word, vereis Digest 'n ekstra terugreis om die nonce-waarde uit te ruil.Met Basic stuur die bellers eenvoudig die geloofsbriewe die eerste keer.

Sodra die identiteit van die kliënt vasgestel is, is magtiging eintlik net 'n implementeringsprobleem.U kan egter die magtiging delegeer na 'n ander komponent met 'n bestaande magtigingsmodel.Weereens, die lekker ding van Basic hier is dat jou bediener eindig met 'n gewone tekskopie van die kliënt se wagwoord wat jy eenvoudig kan deurgee na 'n ander komponent binne jou infrastruktuur soos nodig.

Ander wenke

Daar is geen standaarde vir REST behalwe HTTP nie.Daar is gevestigde REST-dienste daar buite.Ek stel voor jy gaan loer na hulle en kry 'n gevoel van hoe hulle werk.

Ons het byvoorbeeld baie idees by Amazon se S3 REST-diens geleen toe ons ons eie ontwikkel het.Maar ons het gekies om nie die meer gevorderde sekuriteitsmodel te gebruik wat op versoekhandtekeninge gebaseer is nie.Die eenvoudiger benadering is HTTP Basiese verifikasie oor SSL.Jy moet besluit wat die beste in jou situasie werk.

Verder beveel ek die boek sterk aan RUSvolle webdienste van O'reilly.Dit verduidelik die kernbegrippe en verskaf wel 'n paar beste praktyke.Jy kan gewoonlik die model wat hulle verskaf neem en dit na jou eie toepassing karteer.

Jy sal dalk ook wil kyk na OAuth, 'n opkomende oop protokol vir token-gebaseerde magtiging wat spesifiek op http apis gerig is.

Dit is baie soortgelyk aan die benadering wat gevolg is flickr en onthou die melk "rus" apis (nie noodwendig goeie voorbeelde van rustige apis nie, maar goeie voorbeelde van die token-gebaseerde benadering).

Daar is 'n wonderlike kontrolelys op Github:

Stawing

  • Moenie die wiel weer uitvind in stawing, tekengenerering, wagwoordberging nie.Gebruik die standaarde.

  • Gebruik Max Retry en tronkfunksies in Login.

  • Gebruik enkripsie op alle sensitiewe data.

JWT (JSON Web Token)

  • Gebruik 'n ewekansige ingewikkelde sleutel (JWT Secret) om brute forseer die teken baie moeilik te maak.

  • Moenie die algoritme uit die loonvrag onttrek nie.Forseer die algoritme in die agterkant (HS256 of RS256).

  • Maak token verval (TTL, RTTL) so kort as moontlik.

  • Moenie sensitiewe data in die JWT loonvrag, dit kan maklik gedekodeer word.

OAuth

  • Bevestig altyd redirect_uri bedienerkant om slegs gewitlys-URL's toe te laat.

  • Probeer altyd om te ruil vir kode en nie tokens nie (moenie toelaat nie response_type=token).

  • Gebruik toestand parameter met 'n ewekansige hash om te voorkom CSRF op die OAuth verifikasie proses.

  • Definieer die verstek omvang, en valideer omvang parameters vir elke toepassing.

Toegang

  • Beperk versoeke (Throttling) om DDoS / brute-force aanvalle te vermy.

  • Gebruik HTTPS aan die bedienerkant om MITM (Man In The Middle Attack) te vermy

  • Gebruik HSTS kop met SSL om SSL Strip-aanval te vermy.

Invoer

  • Gebruik die regte HTTP-metode volgens die bewerking: GET (lees), POST (skep), PUT/PATCH (vervang/werk op), en DELETE (om 'n rekord te skrap), en reageer met 405 Method Not Allowed as die gevraagde metode nie geskik is vir die gevraagde hulpbron nie.

  • Valideer inhoudtipe op versoek Accept kopskrif (inhoudonderhandeling) om slegs jou ondersteunde formaat toe te laat (bv. application/xml, application/json, ens) en reageer met 406 Not Acceptable reaksie indien nie ooreenstem nie.

  • Valideer content-type van geplaasde data soos jy aanvaar (bv. application/x-www-form-urlencoded, multipart/form-data, application/json, ens).

  • Bekragtig gebruikerinvoer om algemene kwesbaarhede te vermy (bv.XSS, SQL-inspuiting, Afgeleë kode uitvoering, ens.).

  • Moenie enige sensitiewe data (eiebewyse, wagwoorde, sekuriteittokens of API-sleutels) in die URL gebruik nie, maar gebruik standaard Authorization kop.

  • Gebruik 'n API Gateway-diens om caching te aktiveer, Rate Limit beleide (bv.Kwota, Spike Arrest, Concurrent Rate Limit) en ontplooi API's-hulpbronne dinamies.

Verwerking

  • Kyk of al die eindpunte agter stawing beskerm word om gebroke stawingsproses te vermy.

  • Gebruiker eie hulpbron ID moet vermy word.Gebruik /me/orders in plaas van /user/654321/orders.

  • Moenie ID's outomaties verhoog nie.Gebruik eerder UUID.

  • As jy XML-lêers ontleed, maak seker dat entiteit-ontleding nie geaktiveer is om XXE (XML eksterne entiteit-aanval) te vermy nie.

  • As jy XML-lêers ontleed, maak seker dat entiteituitbreiding nie geaktiveer is nie om Billion Laughs/XML-bom via eksponensiële entiteituitbreidingsaanval te vermy.

  • Gebruik 'n CDN vir lêeroplaaie.

  • As jy te doen het met 'n groot hoeveelheid data, gebruik Werkers en Toue om soveel as moontlik in die agtergrond te verwerk en vinnig reaksie terug te gee om HTTP-blokkering te vermy.

  • Moenie vergeet om die te draai nie DEBUG modus AF.

Uitset

  • Stuur X-Content-Type-Options: nosniff kop.

  • Stuur X-Frame-Options: deny kop.

  • Stuur Content-Security-Policy: default-src 'none' kop.

  • Verwyder vingerafdrukopskrifte - X-Powered-By, Server, X-AspNet-Version ens.

  • Dwing content-type vir jou antwoord, as jy terugkeer application/json dan is jou antwoord inhoud-tipe application/json.

  • Moenie sensitiewe data soos geloofsbriewe, wagwoorde, sekuriteitstekens terugstuur nie.

  • Gee die korrekte statuskode terug volgens die bewerking wat voltooi is.(bv. 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, ens).

Ek is nogal verbaas dat SSL met kliëntsertifikate nog nie genoem is nie.Toegegee, hierdie benadering is net werklik nuttig as u daarop kan reken dat die gemeenskap van gebruikers deur sertifikate geïdentifiseer word.Maar 'n aantal regerings/maatskappye reik dit wel aan hul gebruikers uit.Die gebruiker hoef nie bekommerd te wees oor die skep van nog 'n gebruikersnaam/wagwoordkombinasie nie, en die identiteit word op elke verbinding gevestig sodat kommunikasie met die bediener heeltemal staatloos kan wees, geen gebruikersessies nodig nie.(Om nie te impliseer dat enige/al die ander genoemde oplossings sessies vereis nie)

Almal in hierdie antwoorde het ware toegangsbeheer/magtiging oor die hoof gesien.

As jou REST API's / webdienste byvoorbeeld handel oor die PLAAS / VERHAAL van mediese rekords, wil jy dalk toegangsbeheerbeleid definieer oor wie toegang tot die data kan verkry en onder watter omstandighede.Byvoorbeeld:

  • dokters kan die mediese rekord KRY van 'n pasiënt met wie hulle 'n versorgingsverhouding het
  • niemand kan mediese data buite oefenure PLAAS nie (bv.9 tot 5)
  • eindgebruikers kan mediese rekords KRY wat hulle besit of mediese rekords van pasiënte vir wie hulle die voog is
  • verpleegkundiges kan die mediese rekord opdateer van 'n pasiënt wat aan dieselfde eenheid as die verpleegster behoort.

Om daardie fyn-korrekte magtigings te definieer en te implementeer, sal jy 'n kenmerk-gebaseerde toegangsbeheertaal genaamd XACML, die eXtensible Access Control Markup Language, moet gebruik.

Die ander standaarde hier is vir die volgende:

  • OAuth:id.federasie en delegering van magtiging bv.om 'n diens namens my op 'n ander diens te laat optree (Facebook kan op my Twitter plaas)
  • SAML:identiteitsfederasie / web SSO.SAML gaan baie oor wie die gebruiker is.
  • WS-Sekuriteit / WS-* standaarde:hierdie fokus op die kommunikasie tussen SOAP-dienste.Hulle is spesifiek vir die toepassingsvlakboodskapformaat (SOAP) en hulle handel oor aspekte van boodskappe bv.betroubaarheid, sekuriteit, vertroulikheid, integriteit, atomisiteit, gebeurtenisse...Geen dek toegangsbeheer nie en almal is spesifiek vir SOAP.

XACML is tegnologie-agnosties.Dit kan toegepas word op Java-toepassings, .NET, Python, Ruby...webdienste, REST API's, en meer.

Die volgende is interessante hulpbronne:

Ek het OAuth 'n paar keer gebruik, en ook 'n paar ander metodes (BASIC/DIGEST) gebruik.Ek stel OAuth van harte voor.Die volgende skakel is die beste tutoriaal wat ek gesien het oor die gebruik van OAuth:

http://hueniverse.com/oauth/guide/

Een van die beste plasings wat ek nog ooit teëgekom het rakende sekuriteit soos dit met RUS verband hou, is verby 1 Reëndruppel.Die MySpace API's gebruik OAuth ook vir sekuriteit en jy het volle toegang tot hul persoonlike kanale in die RestChess-kode, waarmee ek baie verkenning gedoen het.Dit is by Mix gedemo's en jy kan die plasing vind hier.

Dankie vir die uitstekende raad.Ons het uiteindelik 'n pasgemaakte HTTP-opskrif gebruik om 'n identiteitsteken van die kliënt na die diens oor te dra, ter voorbereiding van die integrasie van ons RESTful API met die komende Zermatt Identity-raamwerk van Microsoft.Ek het die probleem beskryf hier en ons oplossing hier.Ek het ook geneem aanpasse raad en gekoop RUSvolle webdienste - 'n baie goeie boek as jy 'n RUSTIGE API van enige aard bou.

OWASP (Open Web Application Security Project) het 'n paar cheat sheets wat oor alle aspekte van webtoepassingsontwikkeling dek.Hierdie projek is 'n baie waardevolle en betroubare bron van inligting.Wat REST-dienste betref, kan u dit nagaan: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

Ek sal OAuth 2/3 aanbeveel.Jy kan meer inligting kry by http://oauth.net/2/

Ek het baie gesoek oor rustige ws-sekuriteit en ons het ook geëindig met die gebruik van token via koekie van kliënt tot bediener om die versoeke te staaf.Ek het veersekuriteit gebruik vir magtiging van versoeke in diens omdat ek elke versoek moes verifieer en gemagtig het op grond van gespesifiseerde sekuriteitsbeleide wat reeds in DB was.

Die feit dat die SOAP-wêreld redelik goed bedek is met sekuriteitstandaarde, beteken nie dat dit by verstek veilig is nie.In die eerste plek is die standaarde baie kompleks.Kompleksiteit is nie 'n baie goeie vriend van sekuriteit en implementering kwesbaarhede soos XML handtekening wikkel aanvalle is endemies hier.

Wat die .NET-omgewing betref, sal ek nie veel help nie, maar "Bou webdienste met Java" ('n baksteen met ~10 skrywers) het my wel gehelp baie in die begrip van die WS-* sekuriteitsargitektuur en veral die eienaardighede daarvan.

REST self bied geen sekuriteitstandaarde nie, maar dinge soos OAuth en SAML word vinnig die standaarde in hierdie ruimte.Stawing en magtiging is egter slegs 'n klein deel van wat u moet oorweeg.Baie van die bekende kwesbaarhede met betrekking tot webtoepassings is baie van toepassing op REST-apis.U moet insetvalidering, sessie-krake, onvanpaste foutboodskappe, interne werknemerkwesbaarhede en so meer oorweeg.Dit is 'n groot onderwerp.

Ek wil byvoeg (in ooreenstemming met stinkeymatt), die eenvoudigste oplossing sal wees om SSL-sertifikate by u webwerf te voeg.Met ander woorde, maak seker dat jou url HTTPS:// is.Dit sal jou vervoersekuriteit dek (bang for the buck).Met RESTful url's is die idee om dit eenvoudig te hou (anders as WS* sekuriteit/SAML), kan jy gebruik oAuth2/openID verbind of selfs Basic Auth (in eenvoudige gevalle).Maar jy sal steeds SSL/HTTPS nodig hê.Gaan asseblief ASP.NET Web API 2-sekuriteit hier na: http://www.asp.net/web-api/overview/security (Artikels en video's)

Soos @Nathan geëindig het, is dit 'n eenvoudige HTTP-kopskrif, en sommige het gesê OAuth2 en kliëntkant SSL-sertifikate.Die kern daarvan is dit...jou REST API hoef nie sekuriteit te hanteer nie, want dit behoort regtig buite die omvang van die API te wees.

In plaas daarvan moet 'n sekuriteitslaag bo-op dit geplaas word, of dit nou 'n HTTP Header agter 'n webinstaanbediener is ('n algemene benadering soos SiteMinder, Zermatt of selfs Apache HTTPd), of so ingewikkeld soos OAuth 2.

Die belangrikste ding is dat die versoeke moet werk sonder enige interaksie met die eindgebruiker.Al wat nodig is, is om te verseker dat die verbinding met die REST API geverifieer is.In Java EE het ons die idee van a userPrincipal wat verkry kan word op 'n HttpServletRequest.Dit word ook in die ontplooiingsbeskrywing bestuur dat 'n URL-patroon veilig kan wees sodat die REST API-kode nie meer hoef na te gaan nie.

In die WCF-wêreld sou ek gebruik ServiceSecurityContext.Current om die huidige sekuriteitskonteks te kry.U moet u toepassing opstel om verifikasie te vereis.

Daar is een uitsondering op die stelling wat ek hierbo gehad het en dit is die gebruik van 'n nonce om herhalings te voorkom (wat aanvalle kan wees of iemand wat net dieselfde data twee keer indien).Daardie deel kan slegs in die toepassingslaag hanteer word.

Vir webtoepassingsekuriteit, moet u na OWASP (https://www.owasp.org/index.php/Main_Page) wat cheatsheets vir verskeie sekuriteitsaanvalle verskaf.Jy kan soveel moontlik maatreëls inkorporeer om jou Aansoek te beveilig.Met betrekking tot API-sekuriteit (magtiging, verifikasie, identiteitsbestuur), is daar verskeie maniere soos reeds genoem (Basies, Digest en OAuth).Daar is lusgate in OAuth1.0, so jy kan OAuth1.0a gebruik (OAuth2.0 word nie algemeen aangeneem nie weens kommer met die spesifikasie)

Dit is 'n rukkie, maar die vraag is steeds relevant, hoewel die antwoord dalk 'n bietjie verander het.

'n API Gateway sou 'n buigsame en hoogs konfigureerbare oplossing wees.Ek het getoets en gebruik KONG nogal en het baie gehou van wat ek gesien het.KONG bied 'n admin REST API van sy eie wat jy kan gebruik om gebruikers te bestuur.

Express-gateway.io is meer onlangs en is ook 'n API Gateway.

Gelisensieer onder: CC-BY-SA met toeskrywing
Nie verbonde aan StackOverflow
scroll top