При работе с ресурсным сайтом (таким как приложение MVC или служба REST) у нас есть два основных варианта, когда клиент пытается GET
использовать ресурс, к которому у него нет доступа:
- 403 , в котором говорится, что клиент не авторизован ; или
- 404 , который говорит, что ресурс не существует (или не может быть найден).
Кажется, что общая мудрость и обычная практика - отвечать правдой, то есть 403. Но мне интересно, действительно ли это правильно.
Системы безопасного входа никогда не сообщают вам причину сбоя входа. То есть, что касается клиента, не существует заметной разницы между несуществующим именем пользователя и неверным паролем. Цель этого состоит в том, чтобы не делать идентификаторы пользователей - или, что еще хуже, адреса электронной почты - доступными для обнаружения.
С точки зрения конфиденциальности , кажется, гораздо безопаснее вернуть 404. Мне напомнили об инциденте, когда кто-то, как сообщается, узнал победителей реалити-шоу (я думаю, Выживший), посмотрев, каких ресурсов не существует на сайт против того, что сделал. Я обеспокоен тем, что 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
запрос является наиболее подходящим.источник
quux
существует. Но не всегда будут внешние доказательства, особенно на сайтах, не относящихся к социальным сетям, где данные клиентов действительно являются конфиденциальными . Любопытное или враждебное пользователь может в конечном счете быть в состоянии вывести , что ты врешь, но не обязательно , которые ресурсами вы лжете о . Я думаю, что существенный момент здесь действительно, не беспокойтесь о 404 ресурсах, если нет других доступных методов обнаружения.Согласно RFC2616
Также обратите внимание, что при доступе к Запрещенным ресурсам авторизация не поможет .
источник
HttpUnauthorizedResult
которое предназначено для использования для привилегированных ресурсов. , Я также понимаю , (очевидно) , что 404 может быть использован вместо; мой вопрос , является ли он или нет , должен быть использован, и что следует учитывать при принятии этого решения.Вы должны? Да .
Ты сам сказал, предай как можно меньше. Если бы я атаковал систему и заметил, что сервер ответил 403 кодами, я бы сосредоточился на них, а не на том, чтобы двигаться дальше. Лучше дверь объявить, что она не существует, тогда объявить, что ее запретили.
Недостатком использования 404 запросов является то, что внешне это будет выглядеть так, как будто страница не существует, и это может привести к конфликтам по сравнению со страницами, которые, как предполагается, существуют, но отсутствуют. Если вы не беспокоитесь о веб-сканерах (аутентифицированные системы в любом случае должны быть полностью запрещены), тогда вам обязательно следует пойти на это. Каждый API, который у меня есть, обрабатывает неавторизованный доступ точно так же, как и StackOverflow . Не можете увидеть эту страницу? Уверяю вас , это действительно существует, хотя она утверждает , что не.
Вы должны признать , запросы , когда ресурс известен существование и доступ запрещен. Неудачный вход в систему не должен приводить к сообщению 404. Вы не должны подтверждать запросы, когда существование самого ресурса должно быть защищено. Доступ к области существует публично, но группы безопасности или роли в ней не существуют.
Разработчики должны иметь доступ к журналам, в которых будет указана попытка доступа к защищенному ресурсу. Клиенты / пользователи / тестеры будут генерировать обратную связь, которая в конечном итоге ударит разработчика.
Это не безопасность по неизвестности. Вы используете неизвестность в дополнение к надлежащим мерам безопасности.
Это не действительные запросы, это неавторизованные запросы. Вы меняете небольшую часть (верните 404 вместо 403), чтобы получить существенное преимущество у любых потенциальных нападающих.
источник
Это действительно зависит от информации, предоставляемой кодом состояния 403. Если у вас есть конечная точка API, отвечающая
GET /myresource/{id}
404, когда ресурс не существует, то код состояния, возвращаемый конечной точкой, когда ресурс существует, но не авторизован для текущего пользователя, должен зависеть от предсказуемостиid
параметра и количества информации, которую он содержит сам по себе.id
это частное поле, такое как адрес электронной почты или номер банковского счета, оно, вероятно, всегда должно быть скрыто за 404. В случае адреса электронной почты это может помешать спам-ботам составить список действительных адресов электронной почты, зарегистрированных на вашем веб-сайте.id
это публичное имя пользователя, не беспокойтесь, есть другие способы получить доступ к этой информации (например, просто просматривая страницу форума вашего сайта).id
это непрозрачный, но предсказуемый идентификатор (например, автоинкрементное целое число), вы не передаете злоумышленнику информацию, которую он не мог получить другими способами. Так что, по моему мнению, можно вернуть код состояния 403.id
это непрозрачный, непредсказуемый идентификатор (например, случайный идентификатор GUID), вопрос более тонкий. Я лично думаю, что нет проблем с возвратом кода состояния 403. Эта информация может быть использована только в том случае, если в вашем API есть другая дефектная конечная точка, использующая этот идентификатор, но реальным недостатком является ваша другая конечная точка.Вы можете предположить, что лучше быть в безопасности, чем сожалеть в любом случае, и скрывать информацию вне зависимости от контекста, но на самом деле вы не можете полагаться на этот тип поведения для обеспечения какой-либо формы безопасности . С другой стороны, он может обеспечить конфиденциальность (или конфиденциальность, как говорили другие).
Механизм безопасности не должен быть просто ударом скорости для злоумышленника, иначе он просто бесполезен. В этом случае это может даже помешать вам правильно использовать другие функции (сканеры, брандмауэр веб-приложений ищет ненормальное количество кодов состояния 403 для блокировки пользователей ...).
источник