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


12

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.


3
Cevabımın yanı sıra, bu ifadeyi de bırakmak istiyorum, bunun muhtemelen SO veya Güvenlik hakkında daha iyi yanıtlanacağını düşünüyorum
Jeff Langemeier

1
RFC 2616 tarafından tanımlanan PUT ve POST'u değiştirdiğinizi düşünüyorum ( tools.ietf.org/html/rfc2616#section-9.5 ).
Svante

Yanıtlar:


6

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.


GET talebi hassas bilgileri ortaya çıkarabilirse ne olur?
Güneşli

@Sunny: Hassas verileri ne düşünüyorsun?
Chris

2
Chris, eğer paranoyak gidersem, "yanlış" kullanıcı tarafından alınırsa her veri duyarlıdır :). Teorik.
Güneşli

pls, eklediğim sorudaki değişiklikleri gözden geçirin.
Güneşli

1
Yanıtın (GET veya başka bir yöntem olsun) yalnızca kullanıcının görmesi gereken verileri içermesi iyidir. Bir XSRF saldırısı yalnızca saldırganın kullanıcıya belirli bir istekte bulunmasına izin verir, bu istekten gelen yanıtı okumalarına izin vermez. Hedef komut dosyası, üçüncü taraf sayfaların bir <script>etiketten kasıtlı olarak (“JSONP”) veya yanlışlıkla ( korumasız JSON ) okumasına izin verecek şekilde özel bir şekilde oluşturulmadıkça .
bobince

32

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.


4
Paranoya için YAY! Düşmanların var! (Ve Her istek için +1 bir saldırıdır )
Treb

0

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.


3
GET'in güvenlik açısından POST'tan farkı nedir? Her ikisi de aktarım (HTTP veya HTTPS) üzerinden düz olarak gönderilir, tek fark GET sorgu dizelerinin adres çubuğunda görünür olmasıdır.
tdammers

1
@Sunny: POST bu konuda GET kadar açıktır. Bana inanmıyorsanız telnet'i çalıştırın ve bir web sunucusuyla konuşun.
tdammers

1
@Jeff: Telnet (ya da kıvrılma, uyandırma ya da iyi bir eski moda dinleyicisi) getirmemizin nedeni, tüm veri akışını görmenize izin vermesidir. Evet, HTTPS bu bilgileri gizlice dinleyenlerden gizler, ancak SSL bağlantısının her iki ucundaki herkes telnetin tam olarak ne gördüğünü görebilir.
tdammers

1
@Jeremy: POST, adres çubuğundaki parametreleri göstermez, ancak veriler gerçek HTTP akışında göründüğü için, genel olarak haklısınız demektir.
tdammers

7
GET istekleri kaynakları almak için kullanılır ve PUT / POST kaynakları eklemek / güncellemek için kullanılır, böylece RESTful API'nin veri almak için PUT / POST kullanması beklentilerine tamamen aykırıdır.
Lee

0

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.


Teşekkürler. Soru, kullanıcıyı "korumak" değil, sorumsuzca hareket ederse kullanıcıyı korumaktı. Ama cevabınız birkaç iyi noktaya değiniyor.
Güneşli
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.