Tangani permintaan IIS dengan benar dengan url persen masuk (/%)

14

Saya mencari solusi apa pun untuk mendapatkan permintaan IIS dengan benar seperti /programming//% dan http://bing.com/% untuk tidak menampilkan halaman 400 Permintaan Buruk, tetapi menampilkan halaman kesalahan khusus mirip dengan bagaimana http://google.com/% dan http://facebook.com/% lakukan (jelas contoh-contoh itu tidak ada di IIS).

Saya percaya saya telah mencoba mengatur semua pengaturan registri http.sys yang berlaku (AllowRestrictedChars, PercentUAlowed) per http://support.microsoft.com/kb/820129 tetapi itu tidak membantu. Pengaturan AllowRestrictedChars dan halaman kustom 400 telah memperbaiki url seperti /programming//%12 tetapi tidak /%.

iis iis-7 iis-7.5

— Bkaid
sumber

3

Anda menyadari bahwa ini adalah pelarian URL yang tidak lengkap dan merupakan permintaan yang buruk, jadi 400 apakah benar menanganinya? PercentU dan AllowRestricted tidak benar-benar berlaku

— Rup

Ya saya lakukan (dan /% hanyalah contoh URL, tetapi jelas kesalahan terjadi pada setiap karakter escape yang tidak valid). IIS menangani 400, tetapi saya ingin menampilkan halaman 400 kustom seperti yang saya dapat dengan kode status lainnya di IIS, dan seperti bagaimana server non-IIS dapat untuk 400.

— bkaid

Saya memiliki beberapa tautan kuat yang menunjuk ke situs web saya yang disandikan secara keliru seperti ini. tapi saya tidak diizinkan untuk 301 mereka ke halaman yang benar, sebaliknya itu adalah kesalahan yang sulit. ini tidak bisa diterima.

— boomhauer

20

Ini diblokir tepat di tingkat kernel IIS. Sebagai ujian saya mengeluarkan semua modul di IIS sehingga bahkan tidak memiliki pengendali halaman statis, dan masih menampilkan pesan kesalahan 400.

Saya tidak percaya itu mungkin dengan IIS untuk mengatasi itu. Pengaturan registri yang Anda sebutkan adalah untuk jenis karakter terbatas lainnya. Saya belum melihat tuas untuk mengubah fungsi itu.

Apa tujuan Anda menghindari itu? Ini membuka permukaan serangan Anda lebih luas, dan saya tidak bisa membayangkan pengunjung yang sah hilang karena memblokir urutan URL melarikan diri yang tidak lengkap.

Update2: Berikut adalah tiga tautan bagus untuk ini. Baik Nazim Lala dan Wade Hilmo dari tim IIS telah membuat blog tentang hal ini karena diskusi seputar pertanyaan Anda. Scott Hanselman juga memiliki pos yang bagus di bagian querystring dalam .NET:

Penggunaan Karakter Khusus di IIS - Nazim Lala
Bagaimana IIS memblokir karakter dalam URL - Wade Hilmo
Eksperimen dalam Wackiness - Scott Hanselman

Pembaruan: Saya memeriksa dengan anggota tim IIS untuk mendapatkan jawaban yang sah. Dia menyebutkan bahwa% dianggap sebagai karakter yang tidak aman menurut RFC 1738 ( http://www.ietf.org/rfc/rfc1738.txt ).

Inilah teks yang relevan:

Tidak aman:

Karakter dapat menjadi tidak aman karena sejumlah alasan. Karakter spasi tidak aman karena ruang yang signifikan dapat menghilang dan ruang yang tidak signifikan dapat diperkenalkan ketika URL ditranskripsi atau mengeset atau mengalami perlakuan program pengolah kata. Karakter "<" dan ">" tidak aman karena mereka digunakan sebagai pembatas di sekitar URL dalam teks bebas; tanda kutip ("" ") digunakan untuk membatasi URL di beberapa sistem. Karakter" # "tidak aman dan harus selalu disandikan karena digunakan di World Wide Web dan di sistem lain untuk membatasi URL dari fragmen / jangkar pengidentifikasi yang mungkin mengikutinya. Karakter "%" tidak aman karena digunakan untuk penyandian karakter lain. Karakter lain tidak aman karena gateway dan agen transportasi lain diketahui kadang-kadang memodifikasi karakter tersebut. Karakter-karakter ini adalah "{", "}", "|", "\", "^", "~", "[", "]", dan "` ".

Semua karakter yang tidak aman harus selalu dikodekan dalam URL. Misalnya, karakter "#" harus dikodekan dalam URL bahkan dalam sistem yang biasanya tidak berurusan dengan pengidentifikasi fragmen atau jangkar, sehingga jika URL disalin ke sistem lain yang menggunakannya, tidak perlu mengubah Pengkodean URL.

Jadi IIS secara proaktif memblokir ini di tingkat inti, langkah keamanan proaktif untuk meminimalkan permukaan serangan mereka.

— Scott Forsyth - MVP
sumber

Saya lebih suka untuk masuk dan menangani sendiri semua kesalahan dengan benar untuk memantau setiap kombinasi aneh yang tidak valid dari url yang tidak valid yang secara dinamis dihasilkan di situs saya - jika salah satu url keluar dengan benar.

— Bkaid

1

Ada sesuatu yang bisa dikatakan untuk menangani kesalahan sendiri, tetapi jika kegagalan nyata yang jelas ditangani untuk Anda, itu bonus yang bagus. IIS tidak boleh mengizinkan karakter melalui yang tidak sesuai dengan file atau folder di sistem file NTFS. Itu tidak akan tahu apa yang harus dilakukan dengan jalur folder. Jika itu bukan pola karakter yang sama dengan karakter yang valid, maka perlu membuat keputusan tentang apa yang harus dilakukan. Dalam hal ini tampaknya didedikasikan untuk memblokir daripada mengabaikan karakter yang tidak valid.

— Scott Forsyth - MVP

@ thekaido Seperti yang dikatakan Scott, tidak masuk akal untuk mem-parsing URL yang tidak lengkap. Apa jenis halaman kesalahan khusus yang dapat Anda buat karena Anda tidak tahu apa yang coba dilakukan pengguna (karena permintaan tidak lengkap). Perhatikan bahwa IE9 bahkan tidak akan membiarkan Anda masuk ke server dengan permintaan yang tidak lengkap

— Jim B

Saya mengerti implikasi dari semua hal ini kecuali Apache dan server web lainnya mengizinkannya sebagaimana seharusnya IIS. URL yang lolos secara tidak benar adalah satu-satunya IIS URL yang tidak akan membiarkan Anda menangani yang saya tahu. IIS harus dan memang memungkinkan karakter lain yang tidak memetakan ke sistem file NTFS karena situs saya dibangun menggunakan ASP.NET MVC di mana permintaan akan dialihkan ke sumber daya non-file.

— Bkaid

Sebenarnya saya berdiri dikoreksi tentang% di NTFS. Itu diperbolehkan, bersama dengan sebagian besar karakter lain: en.wikipedia.org/wiki/Ntfs . (cari karakter yang Diizinkan dalam nama file).

— Scott Forsyth - MVP

3

Saya dapat memikirkan 3 cara yang mungkin

Ubah IIS untuk menunjuk ke halaman kustom untuk 400 kesalahan daripada biasanya
Jika ini unik untuk situs web tertentu di IIS, Anda dapat melakukan sesuatu seperti ini di web.config:

<customErrors defaultRedirect = "ErrorPage.aspx" mode = "On">
<error statusCode = "400" redirect = "myCustom400Error.aspx" />
</customErrors>
Tulis httpModule yang memeriksa URL yang masuk dan menanganinya

— Dave Wise
sumber

4

Tak satu pun dari pekerjaan ini - IIS tidak pernah menyampaikan permintaan.

— Bkaid

Opsi # 1 harus berfungsi tidak peduli apa karena itu adalah bagaimana IIS merespons kesalahan

— Dave Wise

4

Saya hanya mencoba opsi 1 dan # 2 lagi dan keduanya tidak berfungsi. IIS menangani permintaan ini secara khusus seperti yang disebutkan Scott.

— Bkaid

3

Satu-satunya cara untuk mengatasi ini adalah dengan memeriksa URL sebelum kernel IIS bisa.

Anda harus mengirim tautan yang dibuat secara dinamis melalui skrip untuk memeriksanya sebelum meneruskan pengguna akhir Anda ke URL itu ...

Kecuali itu, Anda tahu ini adalah satu-satunya situasi di mana IIS tidak akan menanganinya seperti yang Anda inginkan. Jadi, dengan proses eliminasi, jika Anda memiliki permintaan yang tidak ditangani, Anda tahu apa yang menyebabkannya.

Mungkin memeriksa perujuk di halaman 400 kustom akan membantu mempersempit sumber lalu lintas?

— Garrett
sumber

2

Posting ini di forum IIS menunjukkan bahwa HTTP 400 (Permintaan Buruk) diblokir oleh http.sys dan tidak membuatnya ke IIS yang cocok dengan tautan yang disertakan oleh @Scott Forsyth - MVP pada jawaban aslinya.

Anda dapat melihat log permintaan ini di bawah c: \ Windows \ System32 \ LogFiles \ HTTPERR \

Saya tidak tahu apakah Anda dapat mengonfigurasi halaman respons yang dikirim kembali ke pengguna untuk kesalahan semacam ini, tetapi karena bahkan Bing menderita masalah ini, saya menduga itu tidak mungkin atau akan memerlukan beberapa peretasan sistem yang mengerikan.

— Hector Correa
sumber