Вернуть «правильный» код ошибки или защитить конфиденциальность?

Question

Хорошо, наверное, лучше привести здесь пример того, что я имею в виду.

Представьте себе систему форумов, основанную на веб-технологиях, в которой аутентификация пользователя выполняется неким внешним методом, о котором знает система.

Теперь, например, пользователь вводит URL-адрес для потока, к которому у него нет доступа. Для этого я должен вернуть 403 (Запрещено), сообщая пользователю, что он должен попробовать другой метод аутентификации, или 404, не давая им знать, что есть что-то для доступа.

Предполагая, что я возвращаю 403, я должен также вернуть 403, когда они получают доступ к URL для темы, которая еще не существует?

Редактировать: приведенный выше пример был скорее примером того, что что-то IRL.

Другой пример, скажем, я выставляю что-то вроде

/adminnotes/user

если есть замечания администратора о пользователе. Теперь возвращение 403 позволит пользователю узнать, что там что-то говорится о них. А 404 ничего не сказал бы.

Но, если бы я вернул 403 - я мог бы вернуть его для adminnotes / * - что решило бы эту проблему.

Редактировать 2: еще один пример. Софт удаленные Вопросы здесь возвращают 404. Тем не менее, с правильной аутентификацией и доступом, вы все равно можете видеть их (я бы предположил)

Answer 1

Помимо всего прочего, соответствует спецификации HTTP. Возвращать 403 вместо 404 - не очень хорошая вещь. Возвращение 404 вместо 403, вероятно, нормально (или не большая ошибка), но я бы просто позволил программному обеспечению сказать правду . Если пользователь знает только идентификатор темы, это не так уж и много. И он может попробовать время атаки , чтобы определить, существует ли эта тема.

Answer 2

Я бы пошел на перенаправление 307 на NoSuchPageOrNoPermissions.html, где вы приятно говорите пользователю, что он набрал неверный URL или не имеет разрешений.

Это не нарушит соответствие и не отправит неверное сообщение.

Если вы очень параноик, вы можете подождать случайное ожидание перед возвратом перенаправления, чтобы анализ времени был сложнее.

Как и все люди, спрашивающие, зачем защищать каталоги, попробуйте эти примеры

1. Имя пользователя

Представьте, что мы провайдер, и мы предоставляем каждому пользователю веб-страницу по адресу www.isp.example / home / USERNAME и адрес электронной почты USERNAME@isp.example. Если злоумышленник выполняет атаку по словарю, отправляя запросы по адресу www.isp.example / home / [Random] и может определить, является ли это действительное имя пользователя, мы можем теперь создать список действительных адресов электронной почты для продажи плохим людям.

2. Какая папка

Боб баллотируется на должность, у него есть аккаунт на постере и он использует свой сайт для хранения личной информации. Но он обеспечил это, сделав это личной папкой, на которой находятся его общедоступные страницы: www.example.com/Bob и его секретная папка www.example.com/Bob/IceCream, он пометил это как личное, так что любой запрашивающий получает 403. Однако www.example.com/Bob/Cake возвращает 404 как секрет Бобса. мороженое не торт

Алиса, репортер, проводит словарную атаку на сайт Бобса, пытаясь

• www.example.com / Bob / Cake - 404
• www.example.com / Bob / Donuts - 404
• www.example.com / Bob / Lollies - 404
• www.example.com / Bob / IceCream - 403

Теперь Алиса знает секреты Бобса и может дискредитировать его как любителя мороженого.

Answer 3

Я думаю, вам следует отправить 307 (временное перенаправление) для запросов на "/ adminnotes / user", чтобы перенаправить непривилегированных клиентов на "/ adminnotes /". Таким образом, клиент делает запрос на «/ adminnotes /», поэтому вы можете отправить обратно 403, потому что это запрещено.

Таким образом, ваше приложение остается HTTP-совместимым, и непривилегированные пользователи мало что узнают о защищенных данных.

Answer 4

Какая «конфиденциальность» защищена, скрывая от пользователей существование определенного потока?

Я бы сказал, что возвращение 403 или 404 в потоке, к которому они не могут получить доступ, в порядке. Возврат 403 в несуществующем потоке - это плохая идея.

Answer 5

Не забывайте, что 404 также может технически раскрывать информацию. Например, вы могли бы сказать, у кого не было adminnotes. В зависимости от обстоятельств это может быть так же плохо, как указание на то, что ресурс существует.

На мой взгляд, ошибки не должны лгать. Если вы дадите 404, то всегда должно быть так, что ресурс не существует.

Если вы имеете дело с конфиденциальной информацией, то вы всегда можете сказать, что у пользователя нет разрешения на ресурс. Это не обязательно требует наличия ресурса. Клиент может не иметь права даже знать, существует ли ресурс. Поэтому вам нужно будет предоставить ошибку отказа в разрешении для любой комбинации /adminnotes/.

Тем не менее, официальная спецификация, похоже, не согласна, вот что говорит официальный rfc об ошибках в http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html:

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

10.4.5 404 Не найдено Сервер не нашел ничего, соответствующего Request-URI. Не указано, является ли состояние временным или постоянным. Код состояния 410 (пропал) СЛЕДУЕТ использовать, если сервер через некоторый внутренне конфигурируемый механизм знает, что старый ресурс постоянно недоступен и не имеет адреса пересылки. Этот код состояния обычно используется, когда сервер не хочет точно указывать, почему запрос был отклонен или когда другой ответ не применим.

Я не эксперт, но я думаю, что глупо давать "не найдено", когда ресурс может существовать. Я бы предпочел «запрещенный», без гарантии, что ресурс существует, подразумевая, что вам нужно будет как-то пройти аутентификацию, чтобы узнать.

Answer 6

Я не понимаю, почему вы беспокоитесь о проблеме конфиденциальности из URL. В случае переполнения стека, вы можете поместить любой текст после номера QuestionID. Например, Вернуть «правильный» код ошибки или защитить конфиденциальность? все еще возвращается к этому вопросу.

Answer 7

Ни один веб-сайт в мире не делает то, что вы предлагаете, поэтому из этого примера мы видим, что, вероятно, лучше всего следовать стандарту и возвращать 404, когда ресурс не существует, и 403, когда он запрещен.

Answer 8

Мое предложение:

1. Если Not Exists_Thread, вернуть 404
2. Если не User_Can_Access_to_this_Thread, вернуть 403

Answer 9

Допустим, вы вернули ошибку «страница не найдена», когда обнаружили, что у пользователя нет правильных прав доступа. Злоумышленник с намерением взлома скоро обнаружит, что вы вернете его вместо запрещенного доступа.

Но настоящие пользователи, которые неправильно набирают URL-адрес или используют неверный логин и т. Д., Будут сбиты с толку, и для объяснения вашей позиции клиентам, TAC и т. Д. Не потребуется никаких объяснений и примечаний к выпуску.

Намерение хорошее, но я боюсь, что предложенная вами политика может не сработать так, как вы этого хотели.