Правильно обробляти запит IIS із відсотковою URL-адресою (/%)

14

Я шукаю будь-яке рішення, щоб правильно отримати запит IIS, такий як /programming//% та http://bing.com/%, щоб не відображати сторінку з 400 запитами з поганими запитами , а відображати власну сторінку помилок подібно до того, як роблять http://google.com/% та http://facebook.com/% (очевидно, що ці приклади не є на IIS).

Я вважаю, що я спробував встановити всі застосовні налаштування реєстру http.sys (AllowRestrictedChars, PercentUAllowed) на http://support.microsoft.com/kb/820129, але це не допомогло. Налаштування AllowRestrictedChars та спеціальна сторінка 400 мають фіксовані URL-адреси, такі як /programming//%12, але не /%.

iis iis-7 iis-7.5

— bkaid
джерело

3

Ви розумієте, що це неповна URL-адреса і це поганий запит, тому 400 належним чином обробляє це? PercentU та AllowRestricted насправді не застосовуються

— Rup

Так, я (і /% - це лише приклад URL, але очевидно, що помилка трапляється з кожним недійсним символом втечі). IIS обробляє 400, але я хочу показати власну сторінку 400, як я можу, з іншими кодами статусу в IIS, і, як, як не-IIS-сервери можуть працювати за 400.

— bkaid

У мене є потужні посилання, які вказують на мої веб-сайти, помилково закодовані таким чином. але мені не дозволяється 301 переносити їх на правильну сторінку, натомість це сильна помилка. це неприпустимо.

— бумгауер

20

Це заблоковано прямо на рівні ядра IIS. Як тест я витягнув кожен модуль в IIS, щоб у нього навіть не було статичного обробника сторінки, і він все ще відображав повідомлення про помилку 400.

Я не вірю, що з IIS можна обійти це. Параметри реєстру, які ви згадали, стосуються інших типів обмежених символів. Я не бачив важеля для зміни цієї функціональності.

Яка ваша мета - уникнути цього? Це відкриває вашу поверхню атаки ширше, і я не можу уявити, що законний відвідувач втрачається в результаті блокування неповних послідовностей втечі URL-адреси.

Update2: Ось три чудові посилання на це. І Назим Лала, і Уейд Хілмо з команди IIS обговорили це питання через дискусію навколо вашого питання. Також у Скотта Хензельмана є чудовий пост щодо частини запитів у .NET:

Використання спеціальних символів у IIS - Nazim Lala
Як IIS блокує символи в URL-адресах - Wade Hilmo
Експерименти у весняності - Скотт Гензельман

Оновлення: я поспілкувався з членом команди IIS, щоб отримати авторитетну відповідь. Він зазначив, що% вважається небезпечним символом згідно з RFC 1738 ( http://www.ietf.org/rfc/rfc1738.txt ).

Ось непотрібний текст:

Небезпечно:

Персонажі можуть бути небезпечними з кількох причин. Символ простору небезпечний, оскільки значні пробіли можуть зникати, а незначні пробіли можуть бути введені під час транскрибування або набору URL-адрес або піддаються обробці програм для обробки тексту. Символи "<" та ">" небезпечні, оскільки вони використовуються як роздільники навколо URL-адрес у вільному тексті; лапка ("" ") використовується для розмежування URL-адрес у деяких системах. Символ" # "небезпечний і завжди повинен бути закодований, оскільки він використовується у всесвітній павутині та в інших системах для розмежування URL-адреси від фрагмента / якоря. ідентифікатор, який може слідувати за ним. Символ "%" небезпечний, оскільки використовується для кодування інших символів. Інші символи небезпечні, тому що, як відомо, шлюзи та інші транспортні агенти іноді змінюють такі символи. Це символи "{", "}", "|", "\", "^", "~", "[", "]" і "` ".

Усі небезпечні символи завжди повинні бути закодовані в межах URL-адреси. Наприклад, символ "#" повинен бути закодований в URL-адресах, навіть у системах, які зазвичай не мають ідентифікаторів фрагмента чи прив'язки, так що якщо URL-адреса буде скопійована в іншу систему, яка їх використовує, не потрібно буде змінювати Кодування URL-адрес.

Таким чином, IIS попередньо блокує це на базовому рівні, проактивний захід безпеки для мінімізації їхньої атаки.

— Скотт Форсайт - MVP
джерело

Я вважаю за краще правильно реєструвати та обробляти всі помилки, щоб відстежувати будь-яку недійсну дивну комбінацію недійсних URL-адрес, які динамічно генеруються на моєму веб-сайті - у випадку, якщо один не отримує належного URL-адреси.

— bkaid

1

Щось сказати, щоб самостійно попрацювати з помилками, але якщо явно очевидні збої вирішуються для вас, це приємний бонус. IIS не повинен допускати символів, які не відповідають файлу чи папці у файловій системі NTFS. Він би не знав, що робити з доріжкою папки. Якщо це не характерний зразок, що дорівнює дійсному символу, то йому потрібно буде прийняти рішення, що робити. У цьому випадку виявляється, що він був призначений для блокування, а не ігнорування недійсних символів.

— Скотт Форсайт - MVP

@thekaido Як сказав Скотт, немає сенсу розбирати неповні URL-адреси. Яку сторінку користувацької помилки ви можете зробити, оскільки ви не маєте уявлення про те, що намагався зробити користувач (оскільки запит є неповним). Зауважте, що IE9 навіть не дозволить вам потрапити на сервер із неповним запитом

— Jim B

Я розумію наслідки всіх цих речей, але Apache та інші веб-сервери дозволяють це робити, як і IIS. Неправильно пропущені URL-адреси - це єдиний IIS URL-адреси, який не дозволить вам обробляти те, про що я знаю. IIS повинен і дозволяє дозволити іншим символам, які не відображаються у файловій системі NTFS, оскільки мій сайт побудований за допомогою ASP.NET MVC, де запити будуть перенаправлені на нефайлові ресурси.

— bkaid

Насправді я виправданий щодо% у NTFS. Це дозволено, як і більшість інших символів: en.wikipedia.org/wiki/Ntfs . (пошук дозволених символів у назви файлів).

— Скотт Форсайт - MVP

3

Я можу придумати 3 можливі способи

Змініть IIS, щоб вказати на користувацьку сторінку на 400 помилок, ніж це зазвичай
Якщо це унікально для певного веб-сайту в IIS, ви можете зробити щось подібне в web.config:

<customErrors defaultRedirect = "ErrorPage.aspx" mode = "On">
<error statusCode = "400" redirect = "myCustom400Error.aspx" />
</customErrors>
Напишіть httpModule, який перевіряє вхідні URL-адреси та обробляє їх

— Дейв Мудрий
джерело

4

Жодна з цих робіт - IIS ніколи не передає запит.

— bkaid

Варіант №1 повинен працювати незалежно від того, тому що IIS реагує на помилку

— Дейв Мудрий

4

Я просто спробував варіант 1 і №2 знову, і жоден з них не працює. IIS обробляє цей запит спеціально, як згадує Скотт.

— bkaid

3

Єдиний спосіб цього звучить як перевірка URL-адреси перед ядром IIS.

Вам потрібно буде надіслати свої динамічно створені посилання через скрипт, щоб перевірити їх, перш ніж переслати кінцевого користувача на цю URL-адресу ...

Якщо це заблокувати, ви знаєте, що це єдина ситуація, коли IIS не буде обробляти її так, як вам хочеться. Тож, у процесі усунення, якщо у вас є необроблений запит, ви знаєте, що це спричинило.

Можливо, перевірка реферала на користувальницькій сторінці 400 допоможе зменшити джерело трафіку?

— Гаррет
джерело

2

Ця публікація на форумі IIS вказує на те, що HTTP 400 (поганий запит) блокується http.sys і не перетворює його на IIS, що відповідає посиланням, які @Scott Forsyth - MVP включені в його оригінальну відповідь.

Журнал цих запитів можна побачити у розділі c: \ Windows \ System32 \ LogFiles \ HTTPERR \

Я не знаю, чи можете ви налаштувати сторінку відповідей, яка надсилається користувачеві на подібні помилки, але оскільки навіть Bing страждає від цієї проблеми, я підозрюю, що це неможливо або потребує деяких жахливих системних хакерів.

— Гектор Кореа
джерело