Url oturum açma yüzdesi (/%) ile IIS isteğini düzgün işleyin

14

400 Hatalı İstek sayfasını görüntülememek, ancak özel bir hata sayfası görüntülemek için /programming//% ve http://bing.com/% gibi bir IIS isteğini düzgün bir şekilde almak için her türlü çözümü arıyorum nasıl benzer http://google.com/% ve http://facebook.com/% do (besbelli bu örnekler IIS üzerinde değildir).

Ben bütün başına uygulanabilir http.sys kayıt defteri ayarları (AllowRestrictedChars, PercentUAllowed) ayarını denedi inanıyorum http://support.microsoft.com/kb/820129 ama bu yardım etmedi. AllowRestrictedChars ve özel bir 400 sayfasının ayarlanması, /programming//%12 gibi sabit URL'lere sahip, ancak /% değil.

iis iis-7 iis-7.5

— bkaid
kaynak

3

Bunun eksik bir URL kaçışının olduğunu ve kötü bir istek olduğunu biliyorsunuz, yani 400 bunu düzgün bir şekilde ele alıyor mu? PercentU ve AllowRestricted gerçekten geçerli değil

— Rup

Evet yaparım (ve /% sadece örnek bir URL'dir, ancak açıkçası hata her geçersiz çıkış karakteriyle olur). IIS 400'ü

— yönetiyor, ancak IIS'deki

Web sitelerime yanlışlıkla böyle kodlanmış bazı güçlü bağlantılar var. ancak doğru sayfaya yönlendirmelerine izin verilmiyor, bunun yerine zor bir hata. bu kabul edilemez.

— boomhauer

20

Bu, doğrudan IIS çekirdek düzeyinde engellenir. Bir test olarak IIS'deki her modülü çıkardım , böylece statik bir sayfa işleyicisi bile yoktu ve hala 400 hata mesajını görüntüledi.

IIS ile bu sorunu çözmenin mümkün olduğuna inanmıyorum. Bahsettiğiniz kayıt defteri ayarları, diğer sınırlı karakter türleri içindir. Bu işlevselliği değiştirmek için bir kol görmedim.

Amacınız bundan kaçınmak mı? Saldırı yüzeyinizi daha geniş bir şekilde açıyor ve eksik URL kaçış dizilerini engelleme sonucunda yasal bir ziyaretçinin kaybolduğunu hayal edemiyorum.

Güncelleme2: İşte bu konuda üç harika bağlantı. Hem Nazim Lala hem de IIS ekibinden Wade Hilmo, sorunuzun tartışılması nedeniyle bu konuda blog yazdılar. Ayrıca Scott Hanselman .NET içinde querystring kısmında büyük bir yazı var:

IIS'de Özel Karakter Kullanımı - Nazim Lala
IIS, URL'lerde karakterleri nasıl engeller - Wade Hilmo
Kaçıklık Deneyleri - Scott Hanselman

Güncelleme: Yetkili bir yanıt almak için IIS ekibinin bir üyesiyle görüştüm. RFC 1738'e göre% değerinin güvensiz bir karakter olarak kabul edildiğini belirtti ( http://www.ietf.org/rfc/rfc1738.txt ).

İlgili metin:

güvensiz:

Karakterler çeşitli nedenlerden dolayı güvensiz olabilir. Uzay karakteri güvensizdir, çünkü önemli boşluklar kaybolabilir ve URL'ler kopyalandığında veya kelime işlemci programlarının işlenmesine maruz kaldığında veya yazılırken önemsiz alanlar eklenebilir. "<" Ve ">" karakterleri güvenli değildir, çünkü URL'lerin çevresinde serbest metin olarak sınırlayıcılar olarak kullanılırlar; tırnak işareti ("" ") bazı sistemlerde URL'leri sınırlamak için kullanılır." # "karakteri güvenli değildir ve her zaman kodlanmalıdır; çünkü World Wide Web'de ve diğer sistemlerde bir URL'yi bir parça / bağlantıdan ayırmak için kullanılır tanımlayıcı o arkasından gelebilecek. diğer karakterlerin kodlanması için kullanılır, çünkü karakter "%" güvensiz. Ağ geçitleri ve diğer taşıma aracılarının bazen bu karakterleri değiştirdiği bilinen diğer karakterler güvenli değildir. Bu karakterler "{", "}", "|", "\", "^", "~", "[", "]" ve "` ".

Güvenli olmayan tüm karakterler her zaman bir URL içinde kodlanmalıdır. Örneğin, "#" karakteri, normalde parça veya bağlantı tanımlayıcılarıyla ilgilenmeyen sistemlerde bile URL'ler içinde kodlanmalıdır, böylece URL bunları kullanan başka bir sisteme kopyalanırsa, URL kodlaması.

IIS, proaktif olarak bunu temel düzeyde engeller, saldırı yüzeylerini en aza indirmek için proaktif bir güvenlik önlemi.

— Scott Forsyth - MVP
kaynak

Sitemde dinamik olarak oluşturulan geçersiz URL'lerin geçersiz tuhaf kombinasyonlarını izlemek için tüm hataları kendim düzgün bir şekilde günlüğe kaydetmeyi ve işlemeyi tercih ediyorum - bir URL düzgün bir şekilde kaçmıyorsa.

— bkaid

1

Hataları kendiniz ele almak için söylenecek bir şey var, ancak açık bir şekilde ortaya çıkan başarısızlıklar sizin için halledilirse, bu güzel bir bonus. IIS, NTFS dosya sistemindeki bir dosya veya klasöre karşılık gelmeyen karakterlere izin vermemelidir. Klasör yolu ile ne yapılacağını bilemez. Geçerli bir karaktere eşit bir karakter deseni değilse, ne yapılması gerektiğine karar vermesi gerekir. Bu durumda, geçersiz karakterleri yok saymak yerine engellemeye adanmış gibi görünüyor.

— Scott Forsyth - MVP

@thekaido Scott'ın dediği gibi, eksik URL'leri ayrıştırmak mantıklı değil. Kullanıcının ne yapmaya çalıştığına dair hiçbir fikriniz olmadığından (istek eksik olduğundan) ne tür bir özel hata sayfası yapabilirsiniz. IE9'un sunucuya eksik bir istekle ulaşmanıza bile izin vermeyeceğini unutmayın

— Jim B

Tüm bunların etkilerini anlıyorum, ancak Apache ve diğer web sunucuları IIS'ye izin veriyor. Yanlışlıkla kaçan URL'ler, IIS'nin bildiğim işlemleri yapmanıza izin vermediği tek URL'dir. Sitem, isteklerin dosya tabanlı olmayan kaynaklara yönlendirileceği ASP.NET MVC kullanılarak oluşturulduğundan IIS, NTFS dosya sistemiyle eşleşmeyen diğer karakterlere izin vermelidir.

— bkaid

Aslında NTFS% yaklaşık düzeltildi. Diğer karakterlerle birlikte izin verilir: en.wikipedia.org/wiki/Ntfs . (dosya adlarında İzin verilen karakterleri arayın).

— Scott Forsyth - MVP

3

3 olası yolu düşünebilirim

IIS'yi, normalde olduğundan 400 hata için özel bir sayfayı gösterecek şekilde değiştirin
Bu, IIS'deki belirli bir web sitesine özelse, web.config dosyasında şöyle bir şey yapabilirsiniz:

<customErrors defaultRedirect = "ErrorPage.aspx" mode = "Açık">
<hata statusCode = "400" redirect = "myCustom400Error.aspx" />
</customErrors>
Gelen URL'leri inceleyen ve işleyen bir httpModule yazın

— Dave Wise
kaynak

4

Bunların hiçbiri - IIS hiçbir zaman isteği iletmez.

— bkaid

Seçenek # 1 ne olursa olsun çalışmalıdır, çünkü IIS hataya bu şekilde yanıt verir

— Dave Wise

4

Sadece seçenek 1 ve # 2'yi tekrar denedim ve ikisi de işe yaramıyor. IIS, bu isteği özellikle Scott'ın belirttiği gibi ele alıyor.

— bkaid

3

Bunun tek yolu, IIS çekirdeği önce URL'yi denetlemek gibi görünebilir.

Son kullanıcınızı bu URL'ye yönlendirmeden önce kontrol etmek için dinamik olarak oluşturulan bağlantılarınızı bir komut dosyası aracılığıyla göndermeniz gerekir ...

Buna engel olarak, IIS'nin istediğiniz gibi işlemeyeceği tek durum budur. Yani, eleme süreciyle, ele alınmamış bir talebiniz varsa, neye neden olduğunu bilirsiniz.

Özel bir 400 sayfasındaki yönlendireni kontrol etmek, trafiğin kaynağını daraltmanıza yardımcı olabilir mi?

— Garrett
kaynak

2

IIS forumundaki bu yazı HTTP 400'ün (Kötü İstek) http.sys tarafından engellendiğini ve IIS'ye @Scott Forsyth - MVP'nin orijinal yanıtında bulunan bağlantılarla eşleşmediğini belirtir.

Bu isteklerin günlüğünü c: \ Windows \ System32 \ LogFiles \ HTTPERR \ altında görebilirsiniz.

Bu tür bir hata için kullanıcıya geri gönderilen yanıt sayfasını yapılandırabileceğinizi bilmiyorum ama Bing bile bu sorundan muzdarip olduğundan bunun ya mümkün olmadığını ya da bazı korkunç sistem saldırıları gerektirdiğinden şüpheleniyorum.

— Hector Correa
kaynak