Kullanıcının Kasten Yanlış Yapıldığını Düşünürsem Aşırı Mühendislik mi Yaparım?

Kullanıcının kasıtlı olarak yanlış yapısına (hafifçe koymak için) koruma eklersem, kullanıcının maruz kalabileceği zarar kodumla ilgili değilse aşırı mühendislik mi?

Açıklamak için, böyle basit bir JSON RESTful hizmetini açığa vuruyorum:

GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item

Hizmetin kendisi bir tarayıcı aracılığıyla değil, yalnızca kullanıcı tarafından kontrol edilen üçüncü taraf uygulamalarından (telefon uygulamaları, masaüstü uygulaması vb.) Kullanılmak üzere tasarlanmıştır. Ayrıca, hizmetin kendisi vatansız olmalıdır (yani oturumsuz).

Kimlik doğrulama SSL üzerinden Temel Kimlik Doğrulama ile yapılır.

Bunun gibi bir "zararlı" davranıştan bahsediyorum:

Kullanıcı GET URL'sini bir tarayıcıya girer (bir neden yok ama ...). Tarayıcı Temel Yetkilendirme ister, işler ve geçerli tarama oturumu için yetkilendirmeyi saklar. Kullanıcı, tarayıcıyı kapatmadan, hizmetimize POST yapan kötü amaçlı bir CSRF / XSRF javascript içeren kötü amaçlı web sitesini ziyaret eder .

Yukarıdaki senaryo pek olası değildir ve iş açısından bakıldığında çok fazla endişelenmemem gerektiğini biliyorum. Ancak durumu iyileştirmek için JSON POST verilerinde kullanıcı adı / parola gerekiyorsa da yardımcı olacağını düşünüyor musunuz?

Yoksa Temel Yetkilendirmeyi tamamen bırakmalı, GET'ten kurtulmalı ve içinde yetki bilgisiyle yalnızca POST / PUT kullanmalı mıyım? GET üzerinden alınan bilgiler de hassas olabilir.

Öte yandan, özel üstbilgilerin kullanılması saf REST uygulamasını dikkate alıyor mu? Temel Yetkilendirmeyi bırakabilir ve özel üstbilgiler kullanabilirim. Bu şekilde, bir tarayıcıdan en azından CSRF saldırısından kaçınılabilir ve hizmeti kullanan uygulamalar kullanıcı adını / parolayı özel heather'de ayarlayacaktır. Bu yaklaşım için kötü, şimdi hizmet bir tarayıcıdan tüketilemez.

Aşırı mühendislik? Bir şey değil. Anti-XSRF önlemleri, herhangi bir güvenli web uygulamasının veya hizmetinin gerekli bir parçasıdır. Birisinin size saldırmayı seçmesi “pek olası değildir”, ancak bu yazılımınızı daha az güvensiz yapmaz.

Sistemler genellikle XSRF kullanılarak saldırıya uğradı ve sonuçlar SQL enjeksiyonundan veya XSS'den daha az açık bir şekilde kötü olsa da, kullanıcı ile etkileşime girebilen tüm özellikleri tehlikeye atacak kadar kötü.

Bu, yalnızca parametrelerin çağrının özellikleri olduğu “saf” bir RESTful arayüzüne sahip olamayacağınız anlamına gelir . Bir saldırganın tahmin edemediği bir şeye istek eklemeniz gerekir. Yani olabilir kullanıcı adı-şifre çifti olabilir, ama bu sadece olası seçenek uzak. Parolanın tuzlanmış bir karmasından oluşturulan jetonla birlikte kullanıcı adınız olabilir. Kimlik doğrulama sırasında hizmetin kendisi tarafından verilen belirteçlere sahip olabilirsiniz (oturumda hatırlanabilir veya kriptografik olarak doğrulanabilir).

GET'ten kurtulmalı mıyım

Hayır, GET istekleri etkin yazma işlemi olmayan okuma istekleri için kullanılır (bunlar "idempotent" dir). Sadece XSRF koruması gerektiren yazma işlemleri.

Asla hiçbir şeye güvenme. Her istek bir saldırıdır. Her kullanıcı bir hacker. Bu zihniyetle gelişirseniz, uygulamanız çok daha güvenli, kararlı ve kötü niyetli bir kullanıcı tarafından ele geçirilme olasılığı daha düşük olacaktır. Tek yapmanız gereken , verilerinizle (en değerli kaynaklarınızdan biri ) ciddi belada olmanız için güvenliğinizde bir yol bulmak için akıllı bir kişidir .

Uygulamanızda bir güvenlik boşluğu belirlediyseniz, boşluğu tıkamak için yapmanız gerektiğini düşündüğünüz her şeyi yapın. Özellikle API'niz mevcut en güvenilmez yazılım parçası olmalıdır. Kimlik bilgileri isterdim ve Post istekleri ile gitmek istiyorum.

Kodun oluşturulması ve sürdürülmesi durumunda, uç vakalara tek tek bakılmalı ve ele alınmalıdır.

PARÇAM ÜZERİNDEKİ BAZI HATALAR İÇİN DÜZELTME:

GET hala uygun bir RESTful hizmetinin bir parçası olarak kullanılmalıdır, her durumda kimlik doğrulamasının hala orada olması gerekir. Tahmin etmeye çalıştığım şey, güvenlik amaçları için GET'in POST ile hemen hemen aynı olmasıydı, ancak yazı, bilgileri büyük bir güvenlik farkı (ve neden GET'ten hoşlanmıyorum) olan bir adres çubuğuna koymadan işini yapıyor. Tahmini Giren: @Lee,

GET requests are used to retrieve resources, and PUT/POST are used to add/update 
resources so it would be completely against expectations for a RESTful API to use
PUT/POST to get data. 

Bu, üçüncü taraf uygulamalar tarafından kullanılacağından, bir RESTful hizmeti için iyi uygulamaları takip etmeli, böylece son uygulayıcı bu kısımda karıştırılmamalıdır.

Kullanıcının aktif olarak kötü amaçlı olması ve (belirsiz) güvenlikle ilgili “belirsizliğe göre güvenlik” engellerini tersine mühendislik dahil olmak üzere tüm olası olasılıkları göz önünde bulundurmalısınız.

Ancak aynı zamanda, bir başarı saldırısının etkisini ve bir girişimin gerçekleşme olasılığını değerlendirmelisiniz. Örneğin:

• Sağlam bir güvenlik duvarı tarafından korunan dahili bir hizmetin, genel internetteki bir hizmetten daha az saldırıya maruz kalma olasılığı vardır.

• Bir müşteri tartışma forumunu indiren birinin etkisi, müşteri kredi kartlarını çalmasının etkisinden daha azdır.

Demek istediğim, "toplam güvenlik" "son derece pahalı" ve pratik olarak ulaşılamaz. İdeal olarak, kapsamlı bir maliyet-fayda analizine dayanarak çizgiyi nerede çizeceğinize karar vermeniz gerekir.