REST API / žiniatinklio paslaugų saugumo patarimai

Kuriant API arba REST paslaugą, ar yra nustatytų saugumo gairių (autentifikavimas, autorizacija, tapatybės valdymas)?

Kurdami savo SOAP API, turite WS-Security kaip vadovą, ir yra daug literatūros šia tema. Radau mažiau informacijos apie REST parametrų apsaugą.

Nors suprantu, kad REST tyčia neturi specifikacijų, panašių į WS- *, tikiuosi, kad bus rodoma geriausia praktika arba rekomenduojami šablonai.

Bet kokia diskusija ar nuorodos į atitinkamus dokumentus būtų labai vertinamos. Jei svarbu, mes naudosime WCF su serializuotais POX / JSON pranešimais mūsų REST API / paslaugoms, sukurtoms naudojant v3.5 .NET Framework.

731
11 авг. nustatė Nathan 11 rug. 2008-08-11 08:44 '08, 08:44, 2008-08-11 08:44
@ 18 atsakymų

Kaip sakė „Twaakt“, „Amazon S3“ yra geras modelis dirbti. Jų užklausų parašuose yra tam tikrų funkcijų (pvz., Leidžia laikrodis), kurios padeda apsaugoti nuo atsitiktinių ir kenkėjiškų užklausų.

Geriausia dalis „HTTP Basic“ yra tai, kad beveik visos HTTP bibliotekos ją palaiko. Žinoma, šiuo atveju jums reikės SSL, nes siuntimo slaptažodžių siuntimas per tinklą yra beveik visuotinai blogas. Naudojant SSL, pageidautina, kad „Basic“ būtų „Digest“, nes net jei skambinantysis jau žino, kad reikalingi įgaliojimai, „Digest“ reikalauja papildomo atvirkštinio perėjimo, kad būtų pakeista „nonce“ reikšmė. „Basic“ skambintojai tiesiog atsiunčia savo įgaliojimus pirmą kartą.

Nustatę kliento ID, autorizacija iš tikrųjų yra problema įgyvendinant. Tačiau galite perduoti leidimą kitam komponentui su esamu autorizacijos modeliu. Vėlgi, „Basic“ geras dalykas yra tai, kad jūsų serveris baigiasi paprasta kliento slaptažodžio teksto kopija, kurią galite paprasčiausiai perkelti į kitą savo infrastruktūros komponentą.

270
11 авг. Greg Hewgill atsakymas, rugpjūčio 11 d. 2008-08-11 11:45 '08, 11:45 val. 2008-08-11 11:45

REST, išskyrus HTTP, nėra standartų. Čia sukuriamos REST paslaugos. Kviečiu jus pažvelgti į juos ir jaustis, kaip jie dirba.

Pavyzdžiui, mes sukūrėme daugybę idėjų iš „Amazon S3 RADA“ tarnybos, kurdami savo. Tačiau mes nusprendėme nenaudoti pažangesnio saugumo modelio, pagrįsto prašymo parašu. Paprastesnis požiūris yra „HTTP Basic auth“ per SSL. Turite nuspręsti, kas geriausiai tinka jūsų situacijai.

border=0

Be to, labai rekomenduoju „O'reilly“ „ RESTful Web Services“ knygą. Jis paaiškina pagrindines sąvokas ir pateikia keletą pažangių metodų. Paprastai galite priimti pateiktą modelį ir suderinti jį su savo programa.

105
11 авг. Marko Renouf atsakymas 11 rug. 2008-08-11 09:07 '08 at 9:07 2008-08-11 09:07

Taip pat galite pažvelgti į naują atviro žetonų pagrindu pagrįstą „ OAuth“ leidimo protokolą, specialiai sukurtą „http apis“.

Jis labai panašus į flickr požiūrį ir prisimena pieno „poilsio“ apį (nebūtinai gerus ramus apis pavyzdžius, bet gerus simbolinio požiūrio pavyzdžius).

66
18 сент. John Spurlock atsakymas rugsėjo 18 d 2008-09-18 05:55 '08 at 5:55 2008-09-18 05:55

Esu labai nustebęs, kad SSL su kliento pažymėjimais dar nebuvo paminėta. Žinoma, šis metodas yra tikrai naudingas, jei galite pasikliauti naudotojų bendruomene, pažymėta sertifikatu. Tačiau daugelis vyriausybių / bendrovių juos atiduoda savo vartotojams. Naudotojui nereikia nerimauti kuriant kitą naudotojo vardo ir slaptažodžio derinį, o autentifikavimas nustatomas kiekvienam ryšiui, todėl ryšys su serveriu gali būti visiškai neribotas, nereikia jokių vartotojų sesijų. (Nereikia manyti, kad bet kuris kitas minėtas sprendimas reikalauja sesijų)

40
25 сент. atsakymas pateikiamas stinkymatt 25 sep . 2009-09-25 22:39 '09 22:39 pm 2009-09-25 22:39

Kiekvienas iš šių atsakymų praleido tikrą prieigos kontrolę / leidimą.

Pavyzdžiui, jei jūsų REST API / žiniatinklio paslaugos yra susijusios su medicininių įrašų skelbimu POSTing / GETing, galite nustatyti prieigos kontrolės politiką, kuri gali pasiekti duomenis ir kokiomis aplinkybėmis. Pavyzdžiui:

  • gydytojai gali gauti paciento, turinčio ryšį su pacientu, medicininį įrašą
  • niekas negali mokėti už medicininius duomenis už praktikos ribų (pvz., nuo 9 iki 5).
  • Galutiniai vartotojai gali gauti medicininius įrašus, kuriuos jie turi, arba pacientų, kuriems jie yra globėjai, medicininius įrašus.
  • slaugytojai gali UPDATE paciento, priklausančio tai pačiai grupei kaip slaugytoja, medicininį įrašą.

Kad apibrėžtumėte ir įgyvendintumėte šiuos smulkiagrūdžius leidimus, turėsite naudoti atributų prieigos kontrolės kalbą, vadinamą XACML, išplėstinę prieigos kontrolės žymėjimo kalbą.

Kiti standartai yra šie:

  • OAuth: id. pavyzdžiui, federacija ir įgaliojimų delegavimas. leidžia paslaugai veikti mano vardu kitoje tarnyboje („Facebook“ gali siųsti laiškus mano „Twitter“).
  • SAML: autentifikavimo federacija / interneto SSO. SAML yra labai daug apie tai, kas yra vartotojas.
  • WS-Security / WS- * standartai: jie orientuoti į ryšį tarp SOAP paslaugų. Tai yra taikomųjų programų pranešimo formatas (SOAP), ir jie susiję, pavyzdžiui, su pranešimų siuntimo aspektais. patikimumas, saugumas, konfidencialumas, vientisumas, atomiškumas, įvykiai ... Nėra prieigos kontrolės ir jie visi susiję su SOAP.

XACML yra technologinis agnostikas. Jis gali būti taikomas „Java“ programoms, .NET, Python, Ruby ... žiniatinklio paslaugoms, REST API ir kt.

Šie įdomūs ištekliai:

33
25 сент. David Brossard atsakymas rugsėjo 25 d 2013-09-25 01:22 '13 ne 1:22 2013-09-25 01:22

Aš keletą kartų naudoju OAuth ir naudoju keletą kitų metodų (BASIC / DIGEST). Nuoširdžiai siūlau OAuth. Ši nuoroda yra geriausia pamoka, kurią matiau naudojant OAuth:

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

24
10 янв. Rob Ottaway atsakymas, sausio 10 d 2009-01-10 00:25 '09 ne 0:25 2009-01-10 00:25

Vienas iš geriausių pranešimų, kuriuos aš kada nors sutikau dėl saugumo, susijusio su REST, baigėsi 1 RainDrop . „MySpace“ API taip pat naudoja „OAuth“ saugumui, ir jūs turite visišką prieigą prie savo pasirinktų kanalų „RestChess“ kode, su kuriuo aš daug tyrinėjau. Jis buvo demonstruotas „Mix“, ir čia galite rasti leidinį.

17
18 сент. Atsakyti atsižvelgiant į degnome 18 sep . 2008-09-18 23:53 '08 at 11:53 2008-09-18 23:53

Github“ :

Autentifikavimas

  • Negalima išradinėti rato autentiškumo nustatymo režimu, generuoti žymas, saugoti slaptažodžius. Naudokite standartus.

  • Naudokite prisijungimo „ Max Retry ir kalėjimo funkcijas.

  • Naudokite visų slaptų duomenų šifravimą.

JWT (JSON interneto raktas)

  • Naudokite atsitiktinį kompleksinį raktą (JWT Secret), kad šiurkštus priverstinis ženklas būtų labai sunkus.

  • Neišimkite algoritmo iš naudingosios apkrovos. Konfigūruokite algoritmą backend (HS256 arba RS256).

  • Padaryti RTTL trukmę ( TTL , RTTL ) kuo trumpesnį.

  • Nelaikykite jautrių duomenų į JWT naudingąją apkrovą, ją galima lengvai dekoduoti.

Oauth

  • Visada patikrinkite redirect_uri serverio pusę, kad leistumėte tik URL su baltais sąrašais.

  • Visada pabandykite keistis kodu, o ne žetonų (neleiskite response_type=token ).

  • Jei norite išvengti CSRF per OAuth patvirtinimo procesą, naudokite valstybinį parametrą su atsitiktiniu maišu.

  • Nustatykite numatytąją taikymo sritį ir patikrinkite kiekvienos programos taikymo sritį.

Prieiga

  • Apribojimų užklausos (droselis), kad būtų išvengta DDoS / brutalinių jėgų atakų.

  • Norėdami išvengti MITM („Man In Middle Attack“), naudokite serverio pusę https

  • Naudokite HSTS antraštę su SSL, kad išvengtumėte SSL juostos atakos.

Prisijungti

  • Naudokite atitinkamą HTTP metodą pagal operaciją: GET (skaityti), POST (kurti), PUT/PATCH (pakeisti / atnaujinti) ir DELETE (ištrinti įrašą) ir atsakyti naudojant 405 Method Not Allowed jei prašomas metodas netinka prašomą išteklių.

  • Patvirtinkite turinio tipą pagal užklausą Accept (turinio derybų) antraštę, kad galėtumėte naudoti tik palaikomą formatą (pvz., application/xml , application/json ir tt) ir atsakyti su 406 Not Acceptable nepriimtinu“ atsakymu, jei jis nėra suderintas.

  • Patvirtinkite skelbiamų duomenų content-type (pvz., application/x-www-form-urlencoded , multipart/form-data , application/json ir tt).

  • Patvirtinkite vartotojo įvestį, kad išvengtumėte bendrų pažeidžiamumų (pvz., XSS, SQL injekcijos, nuotolinio kodo vykdymo ir tt).

  • Nenaudokite slaptų duomenų (kredencialų, slaptažodžių, saugumo žetonų ar API raktų) URL, bet naudokite standartinę Authorization antraštę.

  • Naudokite API „Gateway“ paslaugą, kad įgalintumėte talpyklą, nustatykite Rate Limit politiką (pvz., Kvotas, šuolius, lygiagrečias normas) ir dinaminį API išteklių diegimą.

Apdorojimas

  • Patikrinkite, ar visi galiniai taškai yra apsaugoti autentifikavimui, kad būtų išvengta nepavykusio autentifikavimo proceso.

  • Venkite nuosavų išteklių naudotojo ID. Naudokite / me / užsakymus vietoj / user / 654321 / užsakymų.

  • Neįveskite automatinio prieaugio. Vietoj to naudokite UUID.

  • Jei analizuojate XML failus, įsitikinkite, kad subjekto analizė neleidžiama užkirsti kelią išoriniam XML objektui.

  • Jei analizuojate XML failus, įsitikinkite, kad objekto plėtinys neįjungtas, kad išvengtumėte milijardo didintuvo / XML bombos per ekspansijos objekto išplėtimą.

  • Norėdami atsisiųsti failus, naudokite CDN.

  • Jei susiduriate su dideliu duomenų kiekiu, naudokite „Workers and Queues“, kad galėtumėte apdoroti foną ir greitai grąžinti atsakymą, kad išvengtumėte HTTP blokavimo.

  • Nepamirškite išjungti DEBUG režimo.

Išeiti

  • Siųsti X-Content-Type-Options: nosniff header.

  • Siųsti X-Frame-Options: deny antraštės.

  • Siųsti Content-Security-Policy: default-src 'none' antraštė.

  • Pašalinti spausdinimo antraštes - „ X-Powered-By , „ Server , „ X-AspNet-Version ir kt.

  • Priverstinio content-type atsakymas, jei grįšite application/json , atsakymo turinio tipas bus application/json .

  • Negrąžinkite svarbių duomenų, pvz., Įgaliojimų, slaptažodžių, saugumo žetonų.

  • Grąžinkite atitinkamą būsenos kodą pagal atliktą darbą. (pvz., 200 OK , 400 Bad Request , 401 Unauthorized , 405 Method Not Allowed 401 Unauthorized ir tt).

15
08 нояб. Atsakymą pateikė Andrejs 08 Nov. 2017-11-08 23:29 '17 at 11:29 2017-11-08 23:29

Dėkojame už puikų patarimą. Todėl sukūrėme individualų HTTP antraštę, kad galėtume perduoti tapatybės ženklą iš kliento į tarnybą, ruošiantis integruoti mūsų RESTful API su būsima „Microsoft“ „Zermatt Identity“ platforma. Čia aprašiau problemą ir čia pateiktą sprendimą, taip pat gavau patarimų ir nusipirkau „ RESTful Web Services“ - tai labai gera knyga, jei kuriate bet kokį RESTful API tipą.

15
17 сент. Atsakymą pateikė Nathanas 17 sep. 2008-09-17 23:30 '08 23.30 val. 2008-09-17 23:30

„OWASP“ („Open Web Application Security Project“) yra keli kodai, apimantys visus žiniatinklio programų kūrimo aspektus. Šis projektas yra labai vertingas ir patikimas informacijos šaltinis. „REST“ paslaugoms galite patikrinti: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

12
24 февр. Atsakymą pateikė WelsonJR vasario 24 d. 2014-02-24 21:41 '14 at 21:41 2014-02-24 21:41

Norėčiau rekomenduoti OAuth 2/3. Daugiau informacijos rasite adresu http://oauth.net/2/

7
14 марта '13 в 3:59 2013-03-14 03:59 atsakymą pateikė „ Abhijit Gaikwad“ kovo 14 d., 13 val. 03:59 2013-03-14 03:59

Tai, kad SOAP pasaulis yra gana gerai apsaugotas saugumo standartais, nereiškia, kad jis yra apsaugotas pagal nutylėjimą. Pirma, standartai yra labai . Sudėtingumas nėra labai geras saugumo ir įgyvendinimo pažeidžiamumo draugas, pvz., Atakos su XML atributų pakuotėmis čia yra endeminės.

Kalbant apie „.NET“ aplinką, aš daug nepadėsiu, tačiau kuriant „Web Services“ su „Java“ (plyta su ~ 10 autorių) tikrai padėjo suprasti WS-* saugumo architektūrą ir ypač jos quirks.

6
21 нояб. atsakymas pateikiamas kravietz 21 nov. 2013-11-21 17:19 '13, 17:19, 2013-11-21 17:19

Daug ieškojau saugant ws saugumą, ir mes taip pat galėjome naudoti tokeną per slapuką iš kliento į serverį, kad patvirtintume prašymus. Patvirtinčiau pavasario apsaugą, kad galėčiau patvirtinti prašymus tarnyboje, nes turėjau tikrinti ir išspręsti kiekvieną prašymą, remiantis nurodytomis saugumo taisyklėmis, kurios jau buvo duomenų bazėje.

4
15 мая '12 в 13:36 2012-05-15 13:36 atsakymą pateikė Parisa Kachoui gegužės 15 d. 12 val. 2012-05-15 13:36

Noriu pridėti (pagal stinkeymatt), paprasčiausias sprendimas būtų įtraukti SSL sertifikatus į jūsų svetainę. Kitaip tariant, įsitikinkite, kad jūsų URL yra https: //. Tai apims jūsų transporto saugumą (pataikydamas prie dolerio). Su „RESTful“ URL, idėja yra išlaikyti jį paprastą (skirtingai nei WS * saugumas / SAML), galite naudoti oAuth2 / openID prisijungti arba netgi „Basic Auth“ (paprastais atvejais). Tačiau jums vis tiek reikia SSL / HTTPS. Patikrinkite ASP.NET Web API 2 saugumą: http://www.asp.net/web-api/overview/security (straipsniai ir vaizdo įrašai)

3
01 марта '14 в 4:04 2014-03-01 04:04 atsakymą pateikė „ Manish Jain“ kovo 1 d. 14 d. 4:04 2014-03-01 04:04

REST pati nesuteikia jokių saugumo standartų, tačiau tokie dalykai kaip OAuth ir SAML greitai tampa standartais. Tačiau autentifikavimas ir autorizacija yra tik nedidelė dalis to, ką reikia apsvarstyti. Daugelis žinomų pažeidžiamumų, susijusių su žiniatinklio taikomosiomis programomis, labai stipriai veikia „REST apis“. Turite apsvarstyti įvesties, įsilaužimo sesijos, neteisingų klaidų pranešimų, vidinių darbuotojų pažeidžiamumų ir kt. Tikrinimą Tai didelis klausimas.

3
12 окт. Robert Morschel atsakymas spalio 12 d 2012-10-12 11:22 '12, 11:22 am 2012-10-12 11:22

Tai buvo šiek tiek laiko, bet klausimas vis dar aktualus, nors atsakymas galėjo šiek tiek pasikeisti.

„Gateway“ API bus lankstus ir pritaikomas sprendimas. Aš išbandžiau ir naudoju KONG , ir man labai patiko tai, ką mačiau. „KONG“ pateikia „Admin REST“ API, kurią galite naudoti naudotojams valdyti.

„Express-gateway.io“ yra vėliau ir taip pat yra API sąsaja.

2
12 авг. Atsakyti Matt Bannert 12 rug . 2017-08-12 00:51 '17 ne 0:51 2017-08-12 00:51

Norint užtikrinti interneto programų saugumą, turėtumėte pažvelgti į „OWASP“ ( https://www.owasp.org/index.php/Main_Page ), kuriame pateikiama įvairių saugumo atakų. Jūs galite įtraukti kuo daugiau priemonių, kad apsaugotumėte programą. Kalbant apie saugos API (autorizacija, autentifikavimas, tapatybės valdymas), yra keletas būdų, kaip jau minėta („Basic“, „Digest“ ir „OAuth“). „OAuth1.0“ yra kilpinių skylių, todėl galite naudoti „OAuth1.0a“ („OAuth2.0“ nėra plačiai naudojamas dėl problemų, susijusių su specifikacija)

1
06 окт. atsakymas, kurį pateikė java_geek 06 spalis 2014-10-06 09:05 '14, 9:05 am 2014-10-06 09:05

Kaip @Nathan galėjo būti paprastas HTTP antraštė, o kai kurie OAuth2 ir kliento pusės SSL sertifikatai. Jo esmė yra ta, kad ... jūsų REST API nereikės tvarkyti saugumo, nes ji tikrai turėtų būti ne tik API.

Vietoj to, ant jo turėtų būti dedamas saugos sluoksnis, ar tai būtų proxy HTTP antraštė (bendras požiūris, pvz., „SiteMinder“, „Zermatt“, ar net „Apache HTTPd“), ar taip pat sudėtingas kaip OAuth 2.

Svarbiausia yra tai, kad užklausos turėtų veikti be sąveikos su galutiniu vartotoju. Viskas, ko reikia, yra užtikrinti, kad ryšys su REST API būtų patvirtintas. „Java EE“ mes turime vartotojoPrincipal sąvoką, kurią galima gauti „ HttpServletRequest . Įdiegimo deskriptorius taip pat kontroliuoja, kad URL modelis būtų apsaugotas, todėl REST API kodas nebeturi būti patikrintas.

WCF pasaulyje naudoju ServiceSecurityContext.Current kad gautumėte dabartinį saugumo kontekstą. Turite konfigūruoti autentifikavimo programą.

Yra viena išimtis iš aukščiau pateikto teiginio ir nonce naudojimo siekiant užkirsti kelią pasikartojimams (kurie gali būti išpuoliai arba kažkas tiesiog perduoda tuos pačius duomenis du kartus). Šią dalį galima apdoroti tik programos lygmeniu.

1
17 июля '14 в 18:08 2014-07-17 18:08 atsakymą pateikė Archimedas Trajano, liepos 17 d., 14 val., 18:08, 2014-07-17 18:08