REST API / web hizmetini güvence altına almak için En İyi Uygulamalar [kapalı]

Bir REST API veya hizmeti tasarlarken güvenlikle başa çıkmak için belirlenmiş en iyi uygulamalar var mı (Kimlik Doğrulama, Yetkilendirme, Kimlik Yönetimi)?

Bir SOAP API'si oluştururken kılavuz olarak WS-Security'ye sahipsiniz ve konuyla ilgili çok sayıda literatür var. REST uç noktalarını koruma hakkında daha az bilgi buldum.

REST'in kasıtlı olarak WS- * 'ye benzer özelliklere sahip olmadığını anlasam da, en iyi uygulamaların veya önerilen modellerin ortaya çıktığını umuyorum.

Herhangi bir tartışma veya ilgili belgelere bağlantılar çok takdir edilecektir. Eğer önemliyse, .NET Framework'ün v3.5'i kullanılarak oluşturulan REST API'lerimiz / Hizmetlerimiz için POX / JSON serileştirilmiş mesajlarla WCF kullanırdık.

Tweakt'ın dediği gibi, Amazon S3 çalışmak için iyi bir model. İstek imzalarında, yanlışlıkla ve kötü amaçlı isteklerin yeniden oynatılmasına karşı korunmaya yardımcı olan bazı özellikler (zaman damgası eklemek gibi) bulunur.

HTTP Basic ile ilgili güzel bir şey, neredeyse tüm HTTP kitaplıklarının bunu desteklemesidir. Elbette, bu durumda SSL'ye ihtiyacınız olacak, çünkü net üzerinden düz metin şifreleri göndermek neredeyse evrensel olarak kötü bir şeydir. SSL kullanırken Basic Digest'i tercih eder, çünkü arayan kimlik bilgilerinin gerekli olduğunu zaten biliyor olsa bile Digest, nonce değerini değiştirmek için ekstra bir gidiş dönüş gerektirir. Basic ile arayanlar kimlik bilgilerini ilk kez gönderir.

Müşterinin kimliği belirlendikten sonra, yetkilendirme gerçekten sadece bir uygulama sorunudur. Ancak, yetkilendirmeyi mevcut bir yetkilendirme modeliyle başka bir bileşene devredebilirsiniz. Yine burada Basic ile ilgili güzel şey, sunucunuzun, gerektiğinde altyapınızdaki başka bir bileşene aktarabileceğiniz, istemci şifresinin düz metin kopyasıyla sona ermesidir.

HTTP dışında REST için standart yoktur. Orada kurulmuş REST hizmetleri var. Onlara bir göz atmanızı ve nasıl çalıştıklarını hissetmenizi öneririm.

Örneğin, Amazon'un S3 REST servisinden kendi fikirlerimizi geliştirirken birçok fikir ödünç aldık. Ancak, istek imzalarına dayalı olarak daha gelişmiş güvenlik modelini kullanmamayı seçtik. Daha basit yaklaşım, SSL üzerinden HTTP Temel kimlik doğrulamasıdır. Durumunuzda neyin en iyi olduğuna karar vermelisiniz.

Ayrıca, O'reilly RESTful Web Hizmetleri kitabını tavsiye ederim . Temel kavramları açıklar ve bazı en iyi uygulamaları sağlar. Genellikle sağladıkları modeli alıp kendi uygulamanızla eşleştirebilirsiniz.

Ayrıca , özellikle http apis'i hedefleyen belirteç tabanlı yetkilendirme için yeni bir açık protokol olan OAuth'a da göz atmak isteyebilirsiniz .

Flickr tarafından alınan yaklaşıma çok benzer ve süt "dinlenme" apilerini hatırlayın (dinlendirici apilerin mutlaka iyi örnekleri değil, jeton tabanlı yaklaşımın iyi örnekleri).

Github'da harika bir kontrol listesi var :

Kimlik Doğrulama

• Kimlik Doğrulama, jeton oluşturma, şifre saklama alanında tekerleği yeniden icat etmeyin. Standartları kullanın.

• Kullanım Max Retryve Oturum hapis özellikleri.

• Tüm hassas verilerde şifreleme kullanın.

JWT (JSON Web Simgesi)

• Jetonu çok zorlamak için kaba bir anahtar (JWT Secret) kullanın.

• Algoritmayı faydalı yükten çıkarmayın. Algoritmayı arka uçta zorlayın (HS256 veya RS256).

• Jetonun sona ermesini ( TTL, RTTL) mümkün olduğunca kısa yapın.

• Hassas verileri JWTyükte saklamayın , kolayca deşifre edilebilir.

OAuth

• redirect_uriYalnızca beyaz listeye alınmış URL'lere izin vermek için her zaman sunucu tarafını doğrulayın .

• Kodla değil her zaman kodla değiştirmeyi deneyin (izin vermeyin response_type=token).

• Kimlik doğrulama işlemini önlemek CSRFiçin rastgele bir karma içeren durum parametresini kullanın OAuth.

• Varsayılan kapsamı tanımlayın ve her uygulama için kapsam parametrelerini doğrulayın.

Giriş

• DDoS / kaba kuvvet saldırılarını önlemek için istekleri (Kısma) sınırlayın.

• MITM'den (Orta Saldırıdaki Adam) kaçınmak için sunucu tarafında HTTPS kullanın

• HSTSSSL Strip saldırısından kaçınmak için SSL ile üstbilgiyi kullanın .

Giriş

• GET(Okuma), POST(oluştur), PUT/PATCH(değiştir / güncelle) ve DELETE(bir kaydı silmek için) işleme göre uygun HTTP yöntemini kullanın ve 405 Method Not Allowedistenen yöntem istenen kaynak için uygun değilse yanıt verin .

• İstek üzerine Doğrula içerik türü Acceptbaşlığında (İçerik Yönetimi) yalnızca desteklenen biçimi (örneğin izin application/xml, application/jsonile, vs) ve cevap 406 Not Acceptableeşleşti değilse tepki.

• Doğrulama content-typeKabul olarak (ör verileri yayınlanmıştır application/x-www-form-urlencoded, multipart/form-data, application/json, vs).

• Genel güvenlik açıklarından (ör. XSS, SQL Enjeksiyonu, Uzaktan Kod Yürütme, vb.) Önlemek için Kullanıcı girişini doğrulayın.

• URL'de hassas veriler (kimlik bilgileri, Parolalar, güvenlik belirteçleri veya API anahtarları) kullanmayın, ancak standart Authorizationüstbilgi kullanın .

• Önbelleğe almayı, Rate Limitilkeleri (ör. Kota, Spike Arrest, Eşzamanlı Hız Sınırı) etkinleştirmek ve API kaynaklarını dinamik olarak dağıtmak için bir API Ağ Geçidi hizmeti kullanın .

İşleme

• Kırık kimlik doğrulama işleminden kaçınmak için tüm uç noktaların kimlik doğrulamasının arkasında korunup korunmadığını kontrol edin.

• Kullanıcının kendi kaynak kimliğinden kaçınılmalıdır. / User / 654321 / orders yerine / me / orders kullanın.

• Kimlikleri otomatik olarak artırmayın. Bunun yerine UUID kullanın.

• XML dosyalarını ayrıştırıyorsanız, XXE'yi (XML harici varlık saldırısı) önlemek için varlık ayrıştırma özelliğinin etkinleştirilmediğinden emin olun.

• XML dosyalarını ayrıştırıyorsanız, üstel varlık genişletme saldırısı yoluyla Milyar Gülüş / XML bombasından kaçınmak için varlık genişletmenin etkinleştirilmediğinden emin olun.

• Dosya yüklemeleri için bir CDN kullanın.

• Büyük miktarda veriyle uğraşıyorsanız, arka planda mümkün olduğunca işlemek ve HTTP Engellemesini önlemek için yanıtı hızlı bir şekilde döndürmek için İşçiler ve Kuyrukları kullanın.

• HATA AYIKLAMA modunu KAPALI konuma getirmeyi unutmayın .

Çıktı

• X-Content-Type-Options: nosniffÜstbilgi gönder .

• X-Frame-Options: denyÜstbilgi gönder .

• Content-Security-Policy: default-src 'none'Üstbilgi gönder .

• Başlıklarını parmak izi çıkarın - X-Powered-By, Server, X-AspNet-Versionvb

• content-typeYanıtınız için zorlayın , geri dönerseniz application/jsonyanıt içerik türünüz olur application/json.

• Kimlik bilgileri, Parolalar, güvenlik belirteçleri gibi hassas verileri döndürmeyin.

• Tamamlanan işleme göre uygun durum kodunu döndürün. (örneğin 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, vb).

Ben bir tür sürpriz henüz istemci sertifikaları ile SSL belirtilmedi. Bu yaklaşım, yalnızca sertifikalarla tanımlanan kullanıcı topluluğuna güvenebiliyorsanız gerçekten yararlıdır. Ancak bazı hükümetler / şirketler bunları kullanıcılarına verir. Kullanıcının başka bir kullanıcı adı / şifre kombinasyonu oluşturma konusunda endişelenmesine gerek yoktur ve kimlik her bir bağlantıda kurulur, böylece sunucu ile iletişim tamamen vatansız olabilir, kullanıcı oturumu gerekmez. (Bahsedilen diğer çözümlerin herhangi birinin / hepsinin oturum gerektirdiğini ima etmemek)

Bu yanıtlardaki herkes gerçek erişim kontrolü / yetkisini göz ardı etti.

Örneğin, REST API'leriniz / web hizmetleriniz tıbbi kayıtları POSTA / ALMA ile ilgiliyse, verilere kimin erişebileceği ve hangi koşullar altında erişilebileceği konusunda erişim kontrolü ilkelerini tanımlamak isteyebilirsiniz. Örneğin:

• doktorlar bakım ilişkisi olan bir hastanın tıbbi kaydını alabilirler
• hiç kimse tıbbi verileri çalışma saatleri dışında POST yapamaz (örn. 9 ila 5)
• son kullanıcılar sahip oldukları tıbbi kayıtları veya koruyucu oldukları hastaların tıbbi kayıtlarını ALABİLİR
• hemşireler, hemşireyle aynı birime ait olan bir hastanın tıbbi kaydını GÜNCELLEŞTİRİR.

Bu ayrıntılı yetkileri tanımlamak ve uygulamak için, eXtensible Erişim Kontrolü İşaretleme Dili olan XACML adlı özniteliğe dayalı bir erişim kontrol dili kullanmanız gerekir.

Buradaki diğer standartlar aşağıdakiler içindir:

• OAuth: kimlik. federasyon ve yetki devri, örneğin bir hizmetin benim adıma başka bir hizmet üzerinde hareket etmesine izin vermek (Facebook Twitter'a gönderebilir)
• SAML: kimlik federasyonu / web TOA. SAML, kullanıcının kim olduğu ile ilgilidir.
• WS-Security / WS- * standartları: bunlar SOAP servisleri arasındaki iletişime odaklanır. Uygulama düzeyinde mesajlaşma formatına (SOAP) özeldirler ve mesajlaşma gibi güvenilirlik, güvenlik, gizlilik, bütünlük, atomiklik, olay gibi konularla ilgilenirler ... Hiçbiri erişim kontrolünü kapsamaz ve hepsi SOAP'a özgüdür.

XACML teknolojiden bağımsızdır. Java uygulamalarına, .NET, Python, Ruby ... web hizmetlerine, REST API'lerine ve daha fazlasına uygulanabilir.

Aşağıdakiler ilginç kaynaklar:

• OASIS XACML web sitesi
• NIST ABAK standart

OAuth'u birkaç kez kullandım ve diğer bazı yöntemleri de kullandım (BASIC / DIGEST). Ben yürekten OAuth öneririm. Aşağıdaki bağlantı, OAuth'u kullanırken gördüğüm en iyi öğreticidir:

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

REST ile ilgili olarak Güvenlik ile ilgili olarak karşılaştığım en iyi mesajlardan biri 1 RainDrop'ta bitti . MySpace API'sı güvenlik için OAuth'u da kullanıyor ve çok fazla keşif yaptığım RestChess kodundaki özel kanallarına tam erişiminiz var. Bu Mix'te demo'd ve gönderimi burada bulabilirsiniz .

Mükemmel tavsiye için teşekkürler. RESTful API'mizi Microsoft'un yaklaşmakta olan Zermatt Identity çerçevesine entegre etmeye hazırlanmak için istemciden hizmete bir kimlik belirteci aktarmak için özel bir HTTP başlığı kullandık. Problemi tanımladım burada ve çözümümüzü burada . Ayrıca tweakt'ın tavsiyelerini aldım ve herhangi bir RESTful API oluşturuyorsanız çok iyi bir kitap olan RESTful Web Services'i aldım .

OWASP (Açık Web Uygulaması Güvenlik Projesi), Web Uygulaması geliştirmenin tüm yönlerini kapsayan bazı hile sayfalarına sahiptir. Bu Proje çok değerli ve güvenilir bir bilgi kaynağıdır. REST hizmetleri ile ilgili olarak şunları kontrol edebilirsiniz: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

OAuth 2/3 tavsiye ederim. Daha fazla bilgiyi http://oauth.net/2/ adresinde bulabilirsiniz.

Dinlendirici ws güvenlik hakkında çok şey aradım ve biz de istekleri doğrulamak için istemciden sunucuya çerez yoluyla belirteç kullanarak sona erdi. Hizmette isteklerin yetkilendirilmesi için bahar güvenliğini kullandım, çünkü her bir isteği zaten DB'de bulunan belirtilen güvenlik ilkelerine göre doğrulamak ve yetkilendirmek zorunda kaldım.

SOAP dünyasının güvenlik standartlarıyla oldukça iyi örtülmüş olması, varsayılan olarak güvenli olduğu anlamına gelmez. İlk olarak, standartlar çok karmaşıktır. Karmaşıklık çok iyi bir güvenlik dostu değildir ve XML imza sarma saldırıları gibi uygulama güvenlik açıkları burada endemiktir.

.NET ortamına gelince çok yardımcı olmayacağım, ancak “Java ile web hizmetleri oluşturma” (~ 10 yazarlı bir tuğla) WS- * güvenlik mimarisini ve özellikle de tuhaflıklarını anlamamda bana çok yardımcı oldu .

REST'in kendisi hiçbir güvenlik standardı sunmaz, ancak OAuth ve SAML gibi şeyler hızla bu alandaki standartlar haline geliyor. Ancak, kimlik doğrulama ve yetkilendirme, göz önünde bulundurmanız gerekenin yalnızca küçük bir parçasıdır. Web uygulamalarıyla ilgili bilinen güvenlik açıklarının çoğu REST API'leri için çok geçerlidir. Giriş doğrulamasını, oturum kırmayı, uygunsuz hata mesajlarını, dahili çalışan güvenlik açıklarını vb. Dikkate almanız gerekir. Bu büyük bir konudur.

Eklemek istiyorum (stinkeymatt ile uyumlu olarak), en basit çözüm sitenize SSL sertifikaları eklemek olacaktır. Başka bir deyişle, URL'nizin HTTPS: // olduğundan emin olun. Bu, ulaşım güvenliğinizi kapsayacak (kova için patlama). RESTful url'ler ile fikir, basit tutmaktır (WS * güvenlik / SAML'den farklı olarak), oAuth2 / openID connect veya hatta Basic Auth'u (basit durumlarda) kullanabilirsiniz. Ancak yine de SSL / HTTPS'ye ihtiyacınız olacak. Lütfen ASP.NET Web API 2 güvenliğini buradan kontrol edin: http://www.asp.net/web-api/overview/security (Makaleler ve Videolar)

@Nathan sona erdiğinde, basit bir HTTP Üstbilgisi ve bazıları OAuth2 ve istemci tarafı SSL sertifikaları söyledi. Bunun amacı şudur ... REST API'nizin güvenliği gerçekten ele alması gerekmemelidir, çünkü bu gerçekten API kapsamı dışında olmalıdır.

Bunun yerine, ister bir web proxy'sinin arkasındaki bir HTTP Üstbilgisi (SiteMinder, Zermatt veya hatta Apache HTTPd gibi ortak bir yaklaşım), ister OAuth 2 kadar karmaşık olsun, bir güvenlik katmanının üzerine konulmalıdır.

Önemli olan, isteklerin herhangi bir son kullanıcı etkileşimi olmadan çalışmasıdır. Gerekli olan tek şey REST API'sine bağlantının doğrulanmasını sağlamaktır. Java EE'de bir userPrincipalüzerinde elde edilebilecek bir kavramına sahibiz HttpServletRequest. Dağıtım tanımlayıcısında, bir URL modelinin güvenli olabileceği ve REST API kodunun artık kontrol edilmesine gerek kalmayacağı da yönetilmektedir.

WCF dünyasında, ServiceSecurityContext.Current mevcut güvenlik bağlamını elde etmek için . Uygulamanızı kimlik doğrulaması gerektirecek şekilde yapılandırmanız gerekir.

Yukarıda yaptığım ifadenin bir istisnası vardır ve bu, tekrarları önlemek için bir nonce kullanımıdır (bu, saldırılar veya aynı verileri iki kez gönderen biri olabilir). Bu bölüm yalnızca uygulama katmanında kullanılabilir.

Web Uygulaması Güvenliği için, çeşitli güvenlik saldırıları için hile sayfaları sağlayan OWASP'ye ( https://www.owasp.org/index.php/Main_Page ) bir göz atmalısınız. Uygulamanızı güvence altına almak için olabildiğince çok önlem ekleyebilirsiniz. API güvenliği (yetkilendirme, kimlik doğrulama, kimlik yönetimi) ile ilgili olarak, daha önce belirtildiği gibi (Basic, Digest ve OAuth) çeşitli yollar vardır. OAuth1.0'da döngü delikleri vardır, bu nedenle OAuth1.0a'yı kullanabilirsiniz (spesifikasyonla ilgili endişeler nedeniyle OAuth2.0 yaygın olarak kabul edilmez)

Bir süredir ama soru hala geçerli, ancak cevap biraz değişmiş olabilir.

Bir API Ağ Geçidi esnek ve son derece yapılandırılabilir bir çözüm olacaktır. KONG'i biraz test ettim ve kullandım ve gördüklerimi gerçekten beğendim. KONG, kullanıcıları yönetmek için kullanabileceğiniz kendine ait bir yönetici REST API'si sağlar.

Express-gateway.io daha yeni ve aynı zamanda bir API Ağ Geçidi.