REST API / Web Service Təhlükəsizlik Məsləhətləri

Bir API və ya REST xidmətini inkişaf etdirərkən, müəyyən edilmiş təhlükəsizlik qaydaları var (kimlik, icazə, şəxsiyyət idarəçiliyi)?

SOAP API qurarkən, WS-Təhlükəsizlik kitabçası var və bu mövzuda bir çox ədəbiyyat var. REST son nöqtələrini qorumaq üçün daha az məlumat tapdım.

REST'in qəsdən WS- * kimi xüsusiyyətlərə malik olmadığını başa düşsəm də, ən yaxşı təcrübələr və ya təklif olunan şablonlar görünəcəkdir.

Müvafiq müzakirələr və ya müvafiq sənədlər ilə əlaqələr çox yüksək qiymətləndiriləcəkdir. Əgər vacibdirsə, biz W3C .NET Framework istifadə edərək qurulmuş REST API / Xidmətlərimiz üçün serialized POX / JSON mesajları ilə WCF istifadə edəcəyik.

731
11 авг. Nathan 11 aug tərəfindən təyin . 2008-08-11 08:44 '08 saat 08:44 'da 2008-08-11 08:44
@ 18 cavab

Twaakt dediyinə görə, Amazon S3 ilə işləmək üçün yaxşı bir modeldir. Sorgu imzalarının bəzi təsadüfi və zərərli istəklərdən qorunmasına kömək edən bəzi funksiyaları var (məsələn, bir zaman damgasını təmin edir).

HTTP Basic haqqında ən yaxşı hissə demək olar ki, bütün HTTP kitabxanaları onu dəstəkləyir. Əlbəttə ki, bu halda SSL-yə ehtiyacınız var, çünki şəbəkə vasitəsilə smart-mətn parol göndərmək demək olar ki, tamamilə pisdir. Təqdimat SSL istifadə edərkən Digestə üstünlük təşkil edir, çünki zəngin kimlik məlumatlarının lazım olduğunu bilirsə belə, Digest qeyri-qiymətin mübadiləsi üçün əlavə bir keçid tələb edir. Əsas olaraq, zəng edənlər sadəcə etimadnaməsini ilk dəfə göndərirlər.

Müştəri şəxsiyyəti müəyyən edildikdən sonra, avtorizasiya həqiqətən tətbiqi ilə bağlı bir problemdir. Bununla birlikdə, başqa bir komponentə icazənin mövcud icazənin modeli ilə göndərə bilərsiniz. Yenə burada əsas mövzuda yaxşı bir şey, serverinizin müştəri parolunun basit bir mətn nüsxəsi ilə başa çatmasıdır ki, bu da sadəcə infrastrukturunuzda başqa bir komponentə lazım ola bilər.

270
11 авг. Greg Hewgill tərəfindən verilmiş cavab 11 Avqust. 2008-08-11 11:45 '08 at 11:45 2008-08-11 11:45

HTTP hariç REST üçün heç bir standart yoxdur. REST xidmətləri orada yaradılır. Onlara baxmağa və necə işlədiyini hiss etməyə dəvət edirəm.

Məsələn, özümüzü inkişaf etdirərkən, Amazon S3 RADA xidmətindən çox fikir almışdıq. Ancaq istək imza əsasında daha qabaqcıl bir təhlükəsizlik modelindən istifadə etməməyə qərar verdik. Sadə bir yanaşma SSL üzərində HTTP Basic authdir. Vəziyyətinizdə ən yaxşısı olan işlərə qərar verməlisiniz.

border=0

Ayrıca, O'reilly'nin RESTful Web Services kitabını çox tavsiye ederim. O, əsas anlayışları izah edir və bəzi qabaqcıl texnika verir. Siz adətən təqdim etdiyiniz modeli ala və öz tətbiqinizlə uyğunlaşdıra bilərsiniz.

105
11 авг. Mark Renouf tərəfindən verilmiş cavab 11 av. 2008-08-11 09:07 '08 at 09:07 2008-08-11 09:07

Http apis üçün nəzərdə tutulmuş yeni bir açıq kodlu avtorizasiya protokolu olan OAuth- a da baxa bilərsiniz.

Flickr yanaşmasına çox oxşayır və südün "istirahət" apisini xatırlayır (sakit apisin mütləq yaxşı nümunələri deyil, mö'cüzə əsaslı yanaşmanın yaxşı nümunələri).

66
18 сент. John Spurlock tərəfindən verilmiş cavab 18 sentyabr 2008-09-18 05:55 '08 at 5:55 2008-09-18 05:55

Mən müştəri sertifikatları ilə SSL hələ qeyd olunmayıb çox şaşırdım. Əlbəttə, bu yanaşma, sertifikatlarla müəyyən edilmiş bir istifadəçi cəmiyyətinə güvenebileceğiniz təqdirdə faydalıdır. Ancaq bir sıra hökumət / şirkət onları istifadəçilərinə təqdim edir. Istifadəçi, istifadəçi adı və şifrəsinin başqa bir kombinasiyası yaratmaqdan narahat olmur və hər bir əlaqə üzərindəki identifikasiya müəyyən edilir, belə ki serverlə ünsiyyət tamamilə məhdud ola bilər, istifadəçi seansları tələb olunmur. (Sözügedən hər hansı digər həlli sessiyaların tələb olunmamasını nəzərdə tutmur)

40
25 сент. cavab verilir stinkymatt 25 sep . 2009-09-25 22:39 '09 at 10:39 pm 2009-09-25 22:39

Bu cavabların hər biri orijinal giriş nəzarətini / icazəsini qaçırdı.

Məsələn, REST API / veb xidmətləriniz POSTing / GETing-də tibbi qeydlərin dərc olunmasına aiddirsə, məlumatlara və hansı şəraitdə istifadə edə biləcək bir giriş nəzarəti siyasətini təyin edə bilərsiniz. Məsələn:

  • həkimlər bir xəstə ilə əlaqəsi olan bir xəstənin tibbi qeydini ala bilərlər
  • Heç kəs təcrübə xaricində tibbi məlumatlar üçün ödəniş edə bilməz (məsələn, 9-dan 5-ə).
  • Son istifadəçilər tibbi müayinələrə və ya onların qəyyumları olduqları xəstələrin tibbi qeydlərinə sahib ola bilərlər.
  • tibb bacıları hemşire kimi eyni qrupa aid bir xəstənin tibbi qeydini yeniləyə bilər.

Bu ince taneli yetkileri tanımlamak ve uygulamak üçün, XACML adlı uzantı erişim denetimi biçimlendirme dili olan bir atribut temelli erişim denetim dilini kullanmanız lazımdır.

Burada digər standartlar aşağıdakılardır:

  • OAuth: id. federasiya və nümayəndəlik nümayəndəliyi, məsələn. xidmətin başqa bir xidmətdə (Facebook Twitter-a mesaj göndərə biləcəyini) mənim adından hərəkət etməyə imkan verir.
  • SAML: Doğrulama Federasiyası / Veb SSO. SAML, istifadəçinin kim olduğu haqqında çox şey.
  • WS-Security / WS- * standartları: onlar SOAP xidmətləri arasında ünsiyyətə yönəldirlər. Onlar proqrama xüsusi mesaj formatıdırlar (SOAP) və məsələn, mesajlaşma aspektləri ilə əlaqəli olurlar. etibarlılıq, təhlükəsizlik, məxfilik, bütövlüyə, atomikliyə, hadisələrə ... Giriş icazəsi yoxdur və bunların hamısı SOAP ilə əlaqələndirilir.

XACML texnoloji agnostikdir. Java tətbiqləri, .NET, Python, Ruby ... web xidmətləri, REST API və s. Tətbiq oluna bilər.

Maraqlı resurslar aşağıdakılardır:

33
25 сент. David Brossard tərəfindən verilmiş cavab Sep 25 2013-09-25 01:22 '13 at 1:22 2013-09-25 01:22

OAuth-ı bir neçə dəfə istifadə etmişəm və digər üsullardan istifadə etmişəm (BASIC / DIGEST). Səmimi olaraq OAuth-a təklif edirəm. Aşağıdakı link OAuth istifadə edərkən gördüyüm ən yaxşı təlimdir:

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

24
10 янв. Rob Ottaway tərəfindən verilmiş cavab 10 yanvar 2009-01-10 00:25 '09 at 0:25 2009-01-10 00:25

REST ilə əlaqədar təhlükəsizliklə bağlı tanış olduğum ən yaxşı mesajlardan biri 1 RainDrop'da başa çatdı. MySpace API-də təhlükəsizlik üçün OAuth-dan istifadə edirsiniz və RestChess kodunda xüsusi kanallarınıza tam erişiminiz var. Mix'ta demo'daydı və burada bir nəşr tapa bilərsiniz .

17
18 сент. Cavab verildi 18 sep . 2008-09-18 23:53 '08 at 11:53 2008-09-18 23:53

Github'da :

Doğrulama

  • Təkərləri identifikasiya rejimində təkrarlamaq, ayələr çıxarmaq, parol saxlama. Standartları istifadə edin.

  • Max Retry və həbs funksiyalarını istifadə edin.

  • Bütün həssas məlumatlar üçün şifrəni istifadə edin.

JWT (JSON Web Token)

  • Təsadüfi kompleks düyməsini (JWT Secret) istifadə edin, çox ağır bir məcburi məcbur etməkdir.

  • Alqoritmləri yükündən çıxarmayın. Ardıcıllıqdakı alqoritmi (HS256 və ya RS256) konfiqurasiya edin.

  • RTTL müddətini ( TTL , RTTL ) mümkün qədər qısa müddətə edin.

  • JWT yüklənməsində həssas məlumatları saxlamayın, asanlıqla şifrələnə bilər.

Oauth

  • Yalnız ağ siyahıları olan URL'lere icazə verilməsi üçün həmişə redirect_uri server tərəfini yoxlayın.

  • Həmişə kodu dəyişdirməyə çalışın, tokens deyil ( response_type=token icazə verməyin).

  • OAuth doğrulama prosesi zamanı CSRF qarşısını almaq üçün təsadüfi karma ilə CSRF bir parametrdən istifadə edin.

  • Varsayılan əhatə dairəsini təyin edin və hər bir tətbiq üçün əhatə dairəsinin parametrlərini yoxlayın.

Access

  • DDoS / kobud güc hücumlarından qaçınmaq üçün məhdudiyyət istəkləri (təxribatlar).

  • MITM (Orta Hücumda Man) qarşısını almaq üçün server tərəfdən https istifadə edin

  • SSL Strip hücumundan qaçmaq üçün SSL ilə HSTS başlığını istifadə edin.

Daxil ol

  • Əməliyyata uyğun olaraq müvafiq HTTP metodundan istifadə edin: GET (oxumaq), POST (yaratmaq), PUT/PATCH (dəyişdirin / yeniləyin) və DELETE (qeydləri silmək üçün) və 405 Method Not Allowed cavab verin. istənilən resurs.

  • Yalnızca dəstəklənən formata (məsələn, application/xml , application/json , və s.) application/jsonapplication/json durumunda 406 Not Acceptable cavabla cavab vermək üçün istək üzrə məzmun tipini təsdiqləyin (Məzmun Müzakirəsi) başlığını təsdiqləyin.

  • (Məsələn, application/x-www-form-urlencoded , multipart/form-data , application/json , və s.) Qəbul etdiyiniz zaman dərc edilmiş məlumatların content-type təsdiq edin.

  • Ümumi zəifliklərin qarşısını almaq üçün istifadəçi girişini təsdiqləyin (məsələn, XSS, SQL injection, uzaqdan kodun icrası və s.).

  • URL-də həssas məlumatları (etimadnamələr, şifrələr, təhlükəsizlik ayələrini və ya API düymələri) istifadə etməyin, lakin standart Authorization başlığını istifadə edin.

  • Caching, Rate Limit siyasətlərini (məsələn, kotalar, sivilcələr, paralel dərəcə məhdudiyyətləri) və API resurslarının dinamik yerləşdirilməsini təmin etmək üçün API Gateway xidmətindən istifadə edin.

Qenerasiya

  • Başa çatmayan bir autentifikasiya prosesindən qaçınmaq üçün bütün son nöqtələrin doğrulama üçün qorunduğunu təsdiqləyin.

  • Öz resurs istifadəçi idindən çəkinin. / User / 654321 / siparişləri yerine / me / siparişleri istifadə edin.

  • Avtomatik artım daxil etməyin. Əvəzinə UUID istifadə edin.

  • XML faylları ayrıştırırsanız, bir xarici XML obyektinə hücumdan qaçınmaq üçün obyektin ayrıştırılmasının etkin olmadığından əmin olun.

  • XML faylları analiz edirsinizsə, genişlənmə obyekti uzantısı hücumundan milyardıncı büyüteç / XML bomba istifadə etməmək üçün müəssisənin genişləndirilməsinə imkan verməyin.

  • Faylları yükləmək üçün CDN istifadə edin.

  • Bir çox məlumatla məşğul olduqda, Arxa plana mümkün qədər çox emal etmək üçün İşçi və Kuyrukları istifadə edin və HTTP qarşısını almaq üçün bir cavab verin.

  • DEBUG rejimini silməyi unutmayın.

Çıxın

  • X-Content-Type-Options: nosniff göndərin X-Content-Type-Options: nosniff başlığı.

  • X-Frame-Options: deny Göndər X-Frame-Options: deny başlığı X-Frame-Options: deny .

  • Content-Security-Policy: default-src 'none' göndər Content-Security-Policy: default-src 'none' başlığı.

  • X-Powered-By , Server , X-AspNet-Version və s.

  • Cavabınız üçün content-type məcbur, application/json , cavabınızın məzmunu application/json .

  • Kimlik məlumatları, şifrələr, təhlükəsizlik nişanları kimi mühüm məlumatları geri qaytarmayın.

  • Tamamlanmış işə uyğun müvafiq status kodunu qaytarın. (məsələn, 200 OK , 400 Bad Request , 401 Unauthorized , 405 Method Not Allowed və s.).

15
08 нояб. Cavab Andrejs tərəfindən verildi 08 noyabr. 2017-11-08 23:29 '17 də 11:29 2017-11-08 23:29

Böyük məsləhətləriniz üçün təşəkkür edirik. Nəticədə, RESTful API-yı Microsoft-un gələcək Zermatt Identity platformasına inteqrasiya etmək üçün hazırlanarkən, identifikatorun xidmətdən müştəriyə xidmət göstərmək üçün xüsusi bir HTTP başlığı yaratdıq. Buradakı problemi və həll etdiyimiz problemi burada təsvir etdim, həmçinin tweakt məsləhətləri aldım və RESTful Web Services - hər hansı RESTful API yaratdığınız təqdirdə çox yaxşı bir kitab aldım.

15
17 сент. Cavab Nathan tərəfindən 17 sentyabrda verilir. 2008-09-17 23:30 '08, saat 11.30 'da, 2008-09-17 23:30' da

OWASP (Open Web Application Security Project) veb tətbiqi inkişafın bütün aspektlərini əhatə edən bir neçə fırıldaqçı siyahıdan ibarətdir. Bu layihə çox dəyərli və etibarlı məlumat mənbəyidir. REST xidmətlərinə görə bunu kontrol edə bilərsiniz: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

12
24 февр. Cavab 24 fevralda WelsonJR tərəfindən verilmişdir. 2014-02-24 21:41 '14 at 21:41 2014-02-24 21:41

OAuth 2/3 məsləhət görürəm. Daha ətraflı məlumatı http://oauth.net/2/ ünvanından əldə edə bilərsiniz.

7
14 марта '13 в 3:59 2013-03-14 03:59 Cavab Abihad Gaikwad tərəfindən 14 Mart '13 'də 3:59 2013-03-14 03:59' də verilir

SOAP dünyasının təhlükəsizlik standartları ilə əhatə etdiyi həqiqət onu default olaraq qorunur demək deyil. Birincisi, standartlar çoxdur. Mürəkkəblik çox təhlükəsiz bir dost deyil və təhlükəsizliyin yerinə yetirilməməsi, məsələn , XML xüsusiyyətlərinin qablaşdırılması ilə hücumlar burada endemikdir.

.NET mühitinə gəldikdə, mən çox kömək etmirəm, amma Java ilə Veb Xidmətləri yaratmaq (~ 10 yazıçı ilə kərpic) həqiqətən mənə WS- * təhlükəsizlik arxitekturasını və xüsusilə də quirkslərini anlamağa kömək etdi.

6
21 нояб. Cavab verilir kravietz 21 nov. 2013-11-21 17:19 '13 at 17:19 2013-11-21 17:19

Mən ws-in təhlükəsizliyini qoruya bilmək üçün çox şey axtarırdıq və istəkləri doğrulamaq üçün müştəridən serverə bir cookie vasitəsilə bir mö'cüzə ilə istifadə etdik. Mən xidmətdə istəklərə icazə vermək üçün yay təhlükəsizliyindən istifadə etdim, çünki verilənlər bazasında olan müəyyən edilmiş təhlükəsizlik siyasətlərinə əsasən hər bir tələbi yoxlamaq və həll etmək məcburiyyətindəyəm.

4
15 мая '12 в 13:36 2012-05-15 13:36 Cavab Parisa Kachoui tərəfindən 15 may 2012-ci ildə saat 01 : 36-da verilir. 2012-05-15 13:36

Əlavə etmək istəyirəm (stinkeymatt görə), ən asan həll sitenize SSL sertifikat əlavə etmək olardı. Başqa sözlə, URL'nizin https olduğuna əmin olun: //. Bu, nəqliyyat təhlükəsizliyinizi (dollar vurmaq) əhatə edəcəkdir. RESTful url ilə, fikir sadə (WS * təhlükəsizlik / SAML fərqli), oAuth2 / openID əlaqə və ya hətta Basic Auth (sadə hallarda) istifadə edə bilərsiniz. Ancaq hələ SSL / HTTPS lazımdır. ASP.NET Web API 2 təhlükəsizliyini yoxlayın: http://www.asp.net/web-api/overview/security (məqalələr və videolar)

3
01 марта '14 в 4:04 2014-03-01 04:04 Cavab Maniş Jain tərəfindən martın 01 '14 'də 4:04' də verilir 2014-03-01 04:04

REST özü hər hansı bir təhlükəsizlik standartı təqdim etmir, lakin OAuth və SAML kimi şeylər tez-tez bu məkanda standartlara çevrilir. Buna baxmayaraq, təsdiqləmə və icazə vermək lazım olanların yalnız bir hissəsi. Web applications ilə bağlı bilinən zəifliklərin əksəriyyəti REST apis üzərində çox güclü təsir göstərir. Girişin yoxlanılması, hack iclası, səhv səhv mesajlar, daxili işçi zəiflikləri və s. Nəzərə alınmalıdır. Bu böyük bir sual.

3
12 окт. Robert Morschel tərəfindən verilmiş cavab oktyabr 12 2012-10-12 11:22 '12 saat 11:22 'da 2012-10-12 11:22

Bir müddətdir, lakin sual hələ də vacibdir, baxmayaraq ki, cavab bir az dəyişdi.

Gateway API, çevik və özelleştirilebilir bir həll olacaq. Mən KONG'u bir qədər sınaqdan keçirmiş və istifadə etmişəm və gördüyüm şeyləri çox sevdim. KONG istifadəçilər idarə etmək üçün istifadə edə bilərsiniz Admin REST API təmin edir.

Express-gateway.io daha sonra və bir API ağ geçidi.

2
12 авг. Cavab Matt Bannert 12 Avqust 2017-08-12 00:51 '17 at 0:51 2017-08-12 00:51

Veb tətbiqi təhlükəsizliyini təmin etmək üçün, müxtəlif təhlükəsizlik hücumları üçün hileler təmin edən OWASP ( https://www.owasp.org/index.php/Main_Page ) səhifəsinə baxmalısınız. Proqramı qorumaq üçün mümkün qədər çox tədbirlər əlavə edə bilərsiniz. Təhlükəsizlik API'si (avtorizasiya, autentifikasiya, şəxsiyyət idarəçiliyi) ilə bağlı olaraq, artıq qeyd olunduğu kimi bir neçə yol vardır (Əsas, Digest və OAuth). OAuth1.0 loopback deşiklərinə malikdir, belə ki, OAuth1.0a istifadə edə bilərsiniz (OAuth2.0 spesifikasiyası ilə bağlı problemlər səbəbindən geniş istifadə edilmir)

1
06 окт. java_geek tərəfindən verilmiş cavab 06 oktyabr 2014-10-06 09:05 '14 saat 09:05 'da 2014-10-06 09:05

@Nathan bir sadə HTTP başlığı olmağı sona çatdırdı və bəzi OAuth2 və müştəri tərəfli SSL sertifikatları dedi. Onun mahiyyəti ... REST API'sinin təhlükəsizliklə işləmək lazım deyil, çünki həqiqətən API-dən kənara çıxmalıdır.

Bunun əvəzinə bir təhlükəsizlik qatı yerləşdirilməlidir, bir web proxy HTTP başlığı (SiteMinder, Zermatt, hətta Apache HTTPd kimi ümumi bir yanaşma) və ya OAuth 2 kimi kompleks olsun.

Əsas nöqtə, sorguların son istifadəçi ilə qarşılıqlı əlaqə olmadan çalışmasıdır. Lazım olanların hamısı REST API ilə əlaqənin təsdiqləndiyinə əmin olmaqdır. Java EE-də biz userPrincipal də əldə oluna bilən userPrincipal anlayışına userPrincipal . Dağıtma təsviri həmçinin URL nümunəsinin qorunub saxlanılmasını nəzarət edir, belə ki, REST API kodu artıq yoxlanılmalıdır.

WCF dünyasında, mövcud təhlükəsizlik məzmununu almaq üçün ServiceSecurityContext.Current istifadə edirəm. Tətbiqi təsdiqləmə üçün konfiqurasiya etmək lazımdır.

Yuxarıda göstərilən bəyanata bir istisna və təkrarlanmanın qarşısını almaq üçün qeyri-cəmiyyətin istifadəsi (hücum ola bilən və ya sadəcə eyni məlumatı iki dəfə ötürən kimsə). Bu hissə yalnız tətbiq səviyyəsində işlənə bilər.

1
17 июля '14 в 18:08 2014-07-17 18:08 Archimedes Trajano'nun cavabını 17 İyul, '14 'də saat 18:08' də verən 2014-07-17 18:08