MVC / REST, diğer kullanıcılara ait kaynaklar için 403 veya 404'ü iade etmeli mi?


33

Kaynak tabanlı bir siteyle (örneğin bir MVC uygulaması veya REST servisi gibi) çalışırken, bir istemci GETerişemedikleri bir kaynağa çalıştığında iki ana seçeneğimiz vardır :

  • 403 , ki bu müşterinin yetkisiz olduğunu söylüyor ; veya
  • 404 , kaynağın var olmadığını (veya bulunamadığını) söylüyor.

Ortak bilgelik ve ortak pratik gerçeğe cevap veriyor gibi görünüyor - yani, bir 403. Ama bunun gerçekten yapılacak doğru şey olup olmadığını merak ediyorum.

Güvenli giriş sistemleri, giriş başarısızlığının nedenini size asla söylemez. Diğer bir deyişle, müşteri söz konusu olduğunda, var olmayan bir kullanıcı adı ile yanlış bir şifre arasında tespit edilebilir bir fark yoktur. Bunun amacı kullanıcı kimliklerini - ya da daha kötüsü, e-posta adreslerini - bulunabilir hale getirmektir.

Bir gizlilik açısından bakıldığında, 404'ü iade etmek çok daha güvenli görünüyor. Birinin bir gerçeklik gösterisinin kazananlarını (Survivor, sanırım) hangi kaynaklarda bulunmadığına bakarak buldukları bildirildi . site vs. olanları yaptı. Bir seri numarası veya hesap numarası gibi hassas bilgileri verebilecek bir 403'ten endişe duyuyorum.

Bir 404'ü iade etmemek için zorunlu sebepler var mı? Bir 404 politikasının başka yerlerde olumsuz yan etkileri olabilir mi? Eğer değilse, o zaman uygulama neden daha yaygın değil?


1
404'ü geri göndermemek için zorlayıcı neden: Hizmet kapalıysa veya kimlik doğrulamasında bir hata / hata varsa, 404 elde edersiniz, ancak sorunu teşhis etmeye çalışan müşteri / kullanıcı / test cihazı / geliştirici / destek sorumlusu hiçbir fikre sahip olmayabilir. hata mesajında ​​yanlış olan ne?
Steven Evers,

@Snorfus: Bu iyi bir nokta - Ben bir cevap koyardım. Josh zaten iyi bir
puan vermiş olsa da

Akılda tutulması gereken bir başka husus da şudur: 404'lerin aşağı havzada nasıl tedavi edilir? Bir CDN veya bir çeşit önbellek var mı? Bunları önbelleğe almak istiyorsanız, o zaman muhtemelen "kullanıcı izniniz yok" 404'lerin önbelleğe alınmasını istemezsiniz.
pc1oad1etter

Yanıtlar:


15

Bununla ilgili genel bir yanlış anlama (ve yanlış kullanım) var 403 Forbidden: Sunucunun istek hakkında ne düşündüğü hakkında bir şey vermemesi gerekiyor. Söylemek için özel olarak tasarlanmıştır,

Ne istediğini anlıyorum, ama ne denersen denesene isteği yerine getirmeyeceğim. O yüzden denemeyi bırak.

Herhangi UA veya istemci gerektiğini o istek anlamına etmek yorumlamak asla çalışmak ve uygun şekilde yanıt verir.

Bunun, kullanıcılar adına istekleri yerine getiren müşterileri için etkileri vardır: bir kullanıcı giriş yapmadıysa veya yanlış yazıyorsa, isteği yerine getiren müşterinin ilk kez "üzgünüm ama hiçbir şey yapamam" yanıtını vermesi gerekir. alır 403ve gelecekteki istekleri yerine getirir . Açıkçası, bir hatanın ardından bir kullanıcının hala kişisel bilgilerine erişim talebinde bulunmasını istiyorsanız, bu bir kullanıcı-düşman davranışıdır.

403zıttır 401 Authorization Requiredki, yok sunucu zamandır doğru kimlik geçerken olarak isteği işlemek edeceğini vermek. Bu genellikle insanların duyduklarında düşündükleridir 403.

Aynı zamanda 404 Page Not Found, diğerlerinin de belirttiği gibi, yalnızca "Bu sayfayı bulamıyorum" demek değil, müşteriye sunucunun gelecekteki taleplerde başarı veya başarısızlık iddiası yapmadığını öne sürmekle de aykırıdır.

İle 401ve 404sunucu onlar sürdürmesi gerektiğini nasıl istemci veya UA'ya bir şey söylemiyor: onlar farklı bir yanıt alma umuduyla denemeye devam edebilir.

Öyleyse 404, herkese göstermek istemediğiniz ancak belirli durumlarda neden göstermeyeceğiniz hakkında hiçbir şey vermekten vazgeçmek istemediğiniz bir sayfa için uygun yoldur.

Tabii ki, bu, talebi yapan müşterinin küçük RFC uyumluluğuna önem verdiğini varsayar. Yeterince kötü niyetli bir müşteri, tesadüfi olmayan durumlar dışında iade edilen durum koduyla ilgilenmeyecektir. Biri, bilinen diğer kullanıcı sayfalarıyla karşılaştırarak gizli bir kullanıcı sayfası (veya potansiyel bir gizli kullanıcı sayfası) olduğunu bilir.

Diyelim ki işleyiciniz öyle users/*. Ben biliyorum users/foo, users/barve users/baaziş, sunucu dönen 401, 403ya 404için users/quuxben orada inanmak için nedenlerimiz var, özellikle eğer denemek için gitmiyorum anlamına gelmez olduğunu bir quuxkullanıcı. Standart bir örnek senaryo Facebook: profilim özel, ancak herkese açık profillerdeki yorumlarım değil. Kötü niyetli bir müşteri 404, profil sayfama dönersem bile var olduğumu biliyor .

Yani durum kodları kötü amaçlı kullanım durumları için değil, kurallara göre oynayan müşteriler içindir. Ve bu müşteriler için, 401bir 404istek veya en uygun olanıdır.


4
401'e 403'e dair iyi puanlar. 404'teki ifadelerinizin kesinliğine katılıyorum. Tabii, Facebook örneğinde, bunun zaten quuxvar olduğunu biliyorsunuz . Ancak, özellikle müşteri verilerinin gerçekten özel olduğu sosyal olmayan sitelerde her zaman dış kanıt olmayacak . Bir meraklı ya da düşmanca kullanıcı sonuçta anlamak mümkün olabilir o mutlaka yalan ama değil hangi sen yalan kaynaklar hakkında . Bence buradaki belirgin nokta gerçekten, başka bir keşif metodu olmadığı sürece 404 kaynağa zahmet etme.
Aarona

@Aaronaught Mesele şu ki, gerçekten, gerçekten birisinin sunucunun neyle ilgili aldatıcı olduğunu ya da zorlanmadığınız bir keşif yöntemi olmadığını bilemeyeceğinizden emin olmalısınız. Akıllı bir insan bunu çözecek ve bu noktada durum kodu anlamsız.

1
Kullanıcı profilleri arasında veri paylaşımı yoksa, yeterince akıllı bir insanın bunu nasıl çözebileceği konusunda hala net değilim . Sonunda, “oh, 404 aslında var olabileceği anlamına gelir, ancak erişemiyorum” anlamına geldiğine karar verilen birisinin farkına varacağını anlıyorum - ancak sunucunun, gerçekten bulunmayan kaynaklar için aynı hatayı döndürdüğünü varsayalım. var olmayan bir kaynak ile ayrıcalıklı bir kaynak arasındaki farkı anlatın?
Aaron,

@Aaronaught, bir kişinin bilmesi gereken tek şey, bir profilin URL'sinin bulunması gerektiğidir. Sadece profil kimliklerini kullanabilir ve bunları sahte bir şekilde artırabilirsiniz (bu nedenle 3333 profil kimliğine sahip bir kişi, 3332 profil kimliğine sahip bir kişi olduğu anlamına gelmez), geçerli kimliklerin örneklem büyüklüğü. Bunu başaramazsanız ve profil sayfaları için URL'leri nasıl ürettiği hakkında hiçbir bilgi sızdırmayan tamamen sertleştirilmiş bir sistem olsa bile, her zaman sosyal mühendislik vardır.

8

RFC2616'ya göre

10.4.4 403 Yasak

Sunucu isteği anladı, ancak yerine getirmeyi reddediyor. Yetkilendirme yardımcı olmaz ve istek tekrar edilmemelidir. İstek yöntemi HEAD değilse ve sunucu isteğin neden yerine getirilmediğini açıklamak isterse, kuruluştaki reddin nedenini açıklamalıdır. Sunucu bu bilgiyi müşteriye sunmak istemezse, 404 durum kodu (Bulunamadı) kullanılabilir.

Ayrıca, Yasaklı kaynaklara erişirken, yetkilendirmenin yardımcı olmayacağını da unutmayın .


RFC'nin farkındayım, ancak gerçeğe çok az benzerlik gösteriyor. Neredeyse hiçbir sunucu, ilk cümlenin ötesindeki bir 403'ün nedenini açıklamıyor ("Sunucu isteği anladı, ancak bunu yerine getirmeyi reddediyor.") Ve çoğu MVC çerçevesinin HttpUnauthorizedResultayrıcalıklı kaynaklar için kullanılması amaçlanan bir şeyi bile var . Ayrıca 404 ki (tabii ki) gerçekleştirmek için yerine kullanılabilir; benim sorum o olsun veya olmasın gerektiğini kullanılacak ve bu karar verirken nelere dikkat edilmelidir.
Aaron,

@Aaronaught: RFC sadece 404 kullanmanıza izin vermekle kalmaz, bir şey kabul etmek istemediğinizde 404'ün atılmasını önerir .
Yalan Ryan

3
Sorun değil, ama ne zaman bir şey kabul etmemeliyim? Daha doğrusu ne zaman yapmalıyım ? Bu gerçekten sorunun özü.
Aaron,

5

Sen-meli? Evet .

Kendin söyledin, mümkün olduğunca ihanet et. Bir sisteme saldırıyor ve sunucunun 403 kodla yanıt verdiğini fark edersem, devam etmek yerine bunlara odaklanırdım. Daha iyi bir kapı, yasaklandığını ilan etmek için var olmadığını ilan eder.

404 istek kullanmanın olumsuz tarafı, harici olarak sayfa yokmuş gibi görünmesi ve bunun olması gereken , ancak eksik olan sayfalarla karşılaştırıldığında bu durumla çelişebilir . Web tarayıcıları için endişelenmiyorsanız (kimliği doğrulanmış sistemler zaten tamamen reddedilmelidir), o zaman kesinlikle bunun için gitmelisiniz. Ben her API yetkisiz erişimi tam olarak aynı şekilde ele alır ve böylece StackOverflow da yapar . Bu sayfayı göremiyor musunuz? Sizi temin ederim, öyle olmadığını iddia etse bile.

Sen olmalıdır kaynak olduğunda isteklerini kabul bilinen varlığını ve erişim engellendi. Başarısız bir giriş 404 mesajla sonuçlanmamalıdır. Sen olmamalıdır kaynağın kendisi varlığı korunmalıdır zaman isteklerini kabul eder. Bölgeye erişim halka açıktır, ancak içindeki güvenlik grupları veya rolleri değildir.


404'ü geri göndermemek için zorlayıcı neden: Hizmet kapalıysa veya kimlik doğrulamasında bir hata / hata varsa, 404 elde edersiniz, ancak sorunu teşhis etmeye çalışan müşteri / kullanıcı / test cihazı / geliştirici / destek sorumlusu hiçbir fikre sahip olmayabilir. hata mesajından yanlış olan ne

Geliştiriciler, korunan bir kaynağa erişme girişiminde bulunacaklarını belirten günlüklere erişebilmelidir. Müşteriler / Kullanıcılar / Test Grupları, bir geliştiriciye isabet edecek geri bildirimler üretecektir.

Muğlaklıkla güvenlik ... gerçekten mi?

Bu gizlilik tarafından güvenlik değildir. Uygun güvenlik önlemlerine ek olarak gizlilik kullanıyorsunuz .

Öte yandan, "404" almak için geçerli olan talepler, gerekli olmadığında sadece karmaşıklık ve belirsizlik katmaktadır.

Geçerli talepler değil, yetkisiz taleplerdir. Herhangi bir saldırganda önemli bir avantaj elde etmek için küçük bir parçayı değiştiriyorsunuz (403 yerine 404).


Muğlaklıkla güvenlik ... gerçekten mi? Birisi hizmetlerinizi kötü niyetli bir niyetle dürtmeye çalışıyorsa, orada olduğunu biliyorlar. Öte yandan, "404" almak için geçerli olan talepler, gerekli olmadığında sadece karmaşıklık ve belirsizlik katmaktadır.
Steven Evers,

4
@Snorfus: Burada güvenlik ve gizlilik arasında yapılabilecek ince bir ayrım var . Gizlilik, neredeyse tanımı gereği, "belirsizlik tarafından" dir. Bu, kaynak tabanlı bir sistem bağlamında özellikle önemlidir , çünkü bir kaynağın varlığı ya da olmaması, potansiyel olarak önemli bir bilgidir. Bunlarla daha az ilgilenmeme rağmen, güvenlik argümanları da olabilir. Ben ediyorum bu katma karmaşıklığı hakkında daha fazla duymak; İlk yorumunuzun ötesinde bir ayrıntıya girebilir misiniz? (Belki daha kapsamlı bir cevapta mı? 404'lı 403'lerde ısırdın mı?)
Aaronaught

2
@Snorfus: Ayrıca, daha sonra, derinlemesine savunmanın belirsizliğin güvenlik ile aynı olmadığını da eklemek isterim . İkincisi, başka hiçbir koruma aracı olmadığını ima eder . Ancak zaten güvenli olan bir sisteme gizlilik eklemek genellikle iyi bir şey olabilir - yolda başka sorunlara yol açmadığı sürece. Bu durumda, 404'lerin yetki kodu ile yayınlanmasından dolayı sistemin zaten güvende olduğu söylenir.
Aarona,

@Aaronaught: Daha derinlemesine bir cevap göndereceğim, ancak konuyla ilgili: eğer bir kaynak özelse o zaman kamuya açıklanmasının ardındaki sebep nedir?
Steven Evers,

@Snorfus: Bir kaynak, tüm dünyaya değil, müşteriye veya belki de gruba özeldir .
Aarona

0

Bu gerçekten 403 durum kodu tarafından verilen bilgilere bağlıdır. GET /myresource/{id}Kaynak bulunmadığında 404 ile yanıt veren bir API uç noktanız varsa, kaynak mevcut olduğunda ancak mevcut kullanıcıya yetki verilmemişse, son nokta tarafından döndürülen durum kodu idparametrenin tahmin edilebilirliğine ve miktarına bağlı olmalıdır. içerdiği bilginin kendisi.

  • Bir ide-posta adresi veya banka hesap numarası gibi özel bir alan ise, her zaman bir 404'ün arkasına gizlenmelidir. Bir e-posta adresi söz konusu olduğunda spam botların web sitenize kayıtlı geçerli bir e-posta adresleri listesi oluşturmasını engelleyebilir.
  • Eğer idbir kamu kullanıcı adı, (sadece web sitenizin forum sayfasını tarayarak gibi) bu bilgilere erişmek için başka yollarla, zahmet etmeyin.
  • Eğer idopak, ancak tahmin edilebilir tanıtıcısı (örn otomatik artan tamsayı) 'dir, onun başka yollarla elde edemeyeceği saldırgana herhangi bir bilgi vermek yoktur. Yani bence 403 durum kodunu döndürmek güvenlidir.
  • Eğer idopak, (rastgele GUID gibi) öngörülemeyen tanımlayıcı olan, soru daha ince olduğunu. Şahsen ben 403 durum kodunu döndürmede sorun olmadığını düşünüyorum. Bu bilgiler yalnızca bu kimliğinizi kullanarak API'nizde başka bir hatalı son nokta varsa, ancak gerçek kusur diğer son noktanız olduğunda kullanılabilir.

Her durumda üzgün olmaktan daha güvenli olmanın daha iyi olduğunu varsayabilir ve içeriği ne olursa olsun gizleyebilirsiniz, ancak gerçekte herhangi bir güvenlik biçimi sağlamak için bu tür davranışlara güvenemezsiniz . Öte yandan, bu sağlayabilir gizliliği (diğerleri gibi söylediler, veya gizlilik).

Bir güvenlik mekanizması sadece saldırgan için bir hız tümseği olmamalı, aksi takdirde sadece işe yaramaz. Bu durumda, diğer özellikleri doğru bir şekilde kullanmanızı engelleyebilir (tarayıcılar, kullanıcıları engellemek için 403 durum kodu anormal arayan Web Uygulaması Güvenlik Duvarı ...).

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.