Чи повинен MVC / REST повернути 403 або 404 за ресурси, що належать іншим користувачам?

Працюючи з сайтом, що базується на ресурсах (наприклад, програма MVC або послуга REST), ми маємо два основні варіанти, коли клієнт намагається GETотримати ресурс, до якого він не має доступу:

• 403 , де йдеться про те, що клієнт несанкціонований ; або
• 404 , де йдеться про те, що ресурс не існує (або його не можна було знайти).

Здається, загальна мудрість і звичайна практика відповідати правдою - тобто 403. Але мені цікаво, чи це насправді правильно робити.

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

З точки зору конфіденційності , здається, набагато безпечніше повернути 404. Мені пригадується інцидент, коли хтось, як повідомляється, дізнався переможців реаліті-шоу (Survivor, я думаю), переглядаючи, які ресурси не існували на сайт проти того, що робили. Мене хвилює те, що 403 потенційно може передавати конфіденційну інформацію, наприклад, серійний номер або номер рахунку.

Чи є вагомі причини не повернути 404? Чи може політика 404 мати негативні побічні ефекти в інших місцях? Якщо ні, то чому практика не є більш поширеною?

Існує загальна помилкова думка (і неправильне використання), пов’язана з цим 403 Forbidden: це не повинно давати нічого про те, що сервер думає про запит. Він спеціально розроблений, щоб сказати:

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

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

Це має значення для клієнтів, які обробляють запити від імені користувачів: якщо користувач не входить у систему, або помилки помилки, клієнт, що обробляє запит, повинен відповісти "Вибачте, але я нічого не можу зробити" після першого разу він отримує 403та припиняє обробляти майбутні запити. Очевидно, що якщо ви хочете, щоб користувач все-таки міг запитувати доступ до своєї особистої інформації після відмови, це поведінка, яка сприймає користувачі.

403на відміну від того 401 Authorization Required, що не дає сервера обробляти запит до тих пір, поки ви передасте правильні облікові дані. Про це зазвичай думають люди, коли чують 403.

Це також на відміну від того, 404 Page Not Foundщо, як зазначають інші, покликане не просто сказати "я не можу знайти цю сторінку", а й запропонувати клієнту, що сервер не претендує на успіх чи невдачу для майбутніх запитів.

Із, 401і 404сервер нічого не каже клієнтові або UA про те, як вони повинні діяти: вони можуть продовжувати намагатись отримати іншу відповідь.

Це 404правильний спосіб обробки сторінки, яку ви не хочете показувати всім, але не хочете нічого віддавати про те, чому ви не будете показувати її в певних ситуаціях.

Зрозуміло, це передбачає, що клієнт, який робить запит, піклується про дрібну простоту RFC. Досить зловмисний клієнт не піклується про повернений код статусу, окрім випадкового випадку. Хтось знатиме, що це прихована сторінка користувача (або потенційна прихована сторінка користувача), порівнюючи її з іншими, відомими сторінками користувачів.

Тобто, скажімо, ваш обробник users/*. Якщо я знаю users/foo, users/barі users/baazробота, сервер повертаючи 401, 403або 404для users/quuxне означає , що я не збираюся спробувати, особливо якщо у мене є підстави вважати , що там єquux користувач. Стандартний приклад сценарію - Facebook: мій профіль приватний, але мої коментарі до публічних профілів - ні. Зловмисний клієнт знає, що я існую, навіть якщо ви повернетесь 404на сторінку мого профілю.

Тож коди статусу не для випадків шкідливого використання, а для клієнтів, які грають за правилами. А для цих клієнтів найбільш підходящим є 401або 404запит.

Відповідно до RFC2616

10.4.4 403 Заборонено

Сервер зрозумів запит, але відмовляється його виконувати. Авторизація не допоможе, і запит НЕ повинен повторюватися. Якщо метод запиту не був HEAD і сервер бажає оприлюднити, чому запит не був виконаний, він ДОЛЖЕН описувати причину відмови в організації.Якщо сервер не бажає надавати цю інформацію клієнту, замість цього може використовуватися код статусу 404 (Не знайдено).

також зауважте, що при доступі до заборонених ресурсів авторизація не допоможе .

Ви повинні? Так .

Ви самі це сказали, зрадьте якомога менше. Якби я атакував систему і помітив, що сервер відповів 403 кодами, я б зосередився на них, а не рухався далі. Краще, щоб двері проголосили, що її не існує, а потім оголосити про заборону.

Недоліком використання 404 запитів є те, що зовні воно виглядатиме так, ніби сторінки не існує, і це може мати конфлікти у порівнянні зі сторінками, які повинні існувати, але замість цього відсутні. Якщо ви не турбуєтесь про веб-сканери (аутентифіковані системи в будь-якому випадку повністю відмовлятимуться), вам слід зовсім не робити це. Кожен API, який я обробляю несанкціонований доступ, точно так само, як і StackOverflow . Не можете бачити цю сторінку? Запевняю вас , це дійсно існує, хоча вона стверджує , що ні.

Ви повинні підтвердити запити, коли відомо, що ресурс існує, а доступ заборонений. Помилка входу не повинна призводити до повідомлення 404. Ви не повинні визнавати запити, коли існування самого ресурсу має бути захищено. Доступ до царини існує у громадськості, але групи безпеки чи ролі в ній не є.

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

Розробники повинні мати доступ до журналів, що вказуватиме на спробу доступу до захищеного ресурсу. Клієнти / Користувачі / Тестери генерують зворотній зв'язок, який врешті-решт потрапить на розробника.

Безпека від незрозумілості ... справді?

Це не безпека через невідомість. Ви використовуєте невідомість на додаток до правильних заходів безпеки.

Дійсні запити, отримуючи "404" з іншого боку, лише додають складності та неясності там, де це не потрібно

Вони не є дійсними запитами, це несанкціоновані запити. Ви змінюєте невелику частину (поверніть 404 замість 403), щоб отримати істотну перевагу у будь-яких потенційних нападників.

Це дійсно залежить від інформації, наданої кодом статусу 403. Якщо у вас є кінцева точка API, що відповідає GET /myresource/{id}404, коли ресурс не існує, код статусу, який повертається кінцевою точкою, коли ресурс існує, але поточний користувач не має права, повинен залежати від передбачуваності idпараметра та суми інформації, яку вона містить сама по собі.

• Якщо idце приватне поле, наприклад електронна адреса або номер банківського рахунку, воно, ймовірно, завжди повинно бути прихованим за номером 404. У випадку електронної адреси це може запобігти спам-ботам не складати список дійсних адрес електронної пошти, зареєстрованих на вашому веб-сайті.
• Якщо id це загальнодоступне ім’я користувача, не турбуйтеся, є інші способи отримати доступ до цієї інформації (наприклад, просто переглянувши сторінку форуму вашого веб-сайту).
• Якщо idце непрозорий, але передбачуваний ідентифікатор (наприклад, ціле число, що автоматично збільшується), ви не надаєте зловмиснику жодної інформації, яку він не зміг отримати іншим способом. Тому, на мою думку, безпечно повернути код статусу 403.
• Якщо idце непрозорий і непередбачуваний ідентифікатор (як випадковий GUID), питання є більш тонким. Я особисто думаю, що немає проблеми з поверненням коду статусу 403. Цією інформацією можна скористатися, лише якщо у вашому API є інша недолікова кінцева точка, яка використовує цей ідентифікатор, але реальний недолік - Ваша інша кінцева точка.

Ви можете припустити, що краще бути безпечним, ніж у будь-якому випадку шкодувати та приховувати інформацію незалежно від контексту, але ви фактично не можете розраховувати на такий тип поведінки, щоб забезпечити будь-яку форму безпеки . З іншого боку, це може забезпечити конфіденційність (або конфіденційність, як це казали інші).

Механізм безпеки не повинен бути просто швидким для нападника, інакше це просто марно. У цьому випадку це може навіть перешкодити правильному використанню інших функцій (сканери, брандмауер веб-додатків, які шукають ненормальну кількість 403 кодів стану для блокування користувачів ...).