Ожидается ли, что мой сервер вернет 200 для методов HTTP OPTIONS, когда точка подключения запрещена для текущего пользователя? - PullRequest
Новая
       32

Ожидается ли, что мой сервер вернет 200 для методов HTTP OPTIONS, когда точка подключения запрещена для текущего пользователя?

0 голосов
/ 29 января 2019

Читая различные документы (например, w3c CORS ), я должен сказать, что OPTIONS не выглядит настолько хорошо документированным.

Мне интересно,REST-сервер делает все правильно, то есть возвращает 403, если клиент пытается получить доступ к точке подключения, которая запрещена (существует она или нет, даже не всегда имеет значение, хотя иногда сервер может возвращать 404).

Документация OPTIONS, тем не менее, не подразумевает, что такой код возврата действителен.

Я нашел этот стекопоток Q / A , где кажется принятый ответсказать, что мы можем вернуть любой код ошибки.

Я бы предположил, что это была бы дыра в безопасности, позволяющая проходить OPTIONS, когда пользователю не разрешено.В то же время, OPTIONS определяет заголовок Access-Control-Allow-Credentials, и я не понимаю, как бы я мог сделать этот заголовок полезным, если я верну 403 на таких точках соединения.(Другими словами, для меня это звучит противоречиво.)

1 Ответ

0 голосов
/ 29 января 2019

Краткий ответ: Если вы действительно хотите, чтобы ответ OPTIONS был полезен для сервера, поддерживающего CORS, вы не должны возвращать 403 только потому, что пользователь не вошел в систему.

Подробности:

Для сервера никогда не допустимо возвращать 403 для запроса OPTIONS.Протокол CORS не требует, чтобы ваш сервер возвращал 2xx успешный ответ на OPTIONS запрос.Но если ваш сервер не не вернет 2xx для OPTIONS запросов на определенный URL-адрес, тогда CORS preflight OPTIONS запросов на этот URL не будет выполнен.Так что если это то, что вы на самом деле хотите, чтобы произошло, то ответ с 403 - это нормально, то есть ответ с 405 или 501 или любым другим кодом ответа может иметь значение, соответствующееваш конкретный случай.

Но важно помнить, что протокол CORS требует, чтобы браузеры никогда не отправляли учетные данные для аутентификации в рамках запроса CORS preflight OPTIONS.Таким образом, если ваш сервер настроен на требование аутентификации для OPTIONS запросов на получение 2xx успешных ответов, то все предварительные просмотры CORS, поступающие из браузеров, будут давать сбой 100% времени.Другими словами, вы должны быть уверены, что все запросы не будут выполнены, поступающие на сервер из внешнего кода JavaScript, запущенного в браузере, с добавлением пользовательских заголовков ответов (например, Content-Type или Authorization заголовков) и, таким образом, триггераpreflights.

Мне неизвестно о какой-либо конкретной дыре в безопасности, которая может возникнуть при ответе 2xx на неаутентифицированные OPTIONS запросы (от пользователей, которым это не разрешено).Это не позволяет пользователям получать с вашего сервера какую-либо информацию, кроме той, которую вы намеренно включили в заголовки ответов, отправляемых вами в ответ на запрос OPTIONS.И, конечно, это не мешает вам требовать аутентификацию для GET или POST или для любых других методов.Но с точки зрения протокола CORS, это единственный способ для вашего сервера указать, какие методы и заголовки запросов он разрешает в запросах из внешнего интерфейса JavaScript.

Примечание также: текущие активно поддерживаемые требования для CORSопределены в спецификации Fetch https://fetch.spec.whatwg.org. Спецификация https://w3.org/TR/cors устарела и больше не поддерживается и не должна использоваться ни для чего (см. https://w3.org/2017/08/16-webappsec-minutes.html#item03 и ответ на https://stackoverflow.com/a/45926657/441757).

Я не знаю, почему спецификация https://w3.org/TR/cors еще не была явно помечена как устаревшая, но я постараюсь сделать так, чтобы она была помечена как таковая в ближайшее время.

...