Недавно мне пришлось установить Access-Control-Allow-Originзначение *, чтобы иметь возможность выполнять вызовы ajax между субдоменами.
Теперь я не могу не чувствовать, что подвергаю свою среду угрозе безопасности.
Пожалуйста, помогите мне, если я делаю что-то не так.

Отвечая Access-Control-Allow-Origin: *, запрашиваемый ресурс разрешает совместное использование с каждым источником. Это в основном означает, что любой сайт может отправить запрос XHR на ваш сайт и получить доступ к ответу сервера, чего не было бы, если бы вы не реализовали этот ответ CORS.

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

Это действительно создает угрозу безопасности, особенно если вы разрешаете совместное использование ресурсов не только для выбранных ресурсов, но и для каждого ресурса. В этом контексте вам следует обратить внимание на то, когда безопасно включать CORS? ,

Access-Control-Allow-Origin: *полностью безопасно добавлять к любому ресурсу, если этот ресурс не содержит личные данные, защищенные чем-то иным, кроме стандартных учетных данных (файлы cookie, базовая аутентификация, клиентские сертификаты TLS).

Например: данные, защищенные файлами cookie, безопасны.

Представьте https://example.com/users-private-data, что может открывать личные данные в зависимости от состояния входа пользователя в систему. В этом состоянии используется файл cookie сеанса. Это безопасно , чтобы добавить Access-Control-Allow-Origin: *к этому ресурсу, так как этот заголовок позволяет получить доступ к ответу , только если запрос сделан без печенья и печенье требуется , чтобы получить личные данные. В результате утечки личных данных не происходит.

Например: данные, защищенные местоположением / IP / внутренней сетью, небезопасны (к сожалению, часто встречаются в интрасетях и бытовой технике):

Представьте https://intranet.example.com/company-private-data, что предоставляет данные частной компании, но доступ к ним возможен только в том случае, если вы находитесь в сети Wi-Fi компании. Это не безопасно , чтобы добавить Access-Control-Allow-Origin: *к этому ресурсу, так как он защищен использовать что - то другое , чем стандартные учетные данные. В противном случае плохой сценарий может использовать вас в качестве туннеля в интрасеть.

Практическое правило

Представьте, что увидел бы пользователь, если бы обратился к ресурсу в окне инкогнито. Если вы довольны тем, что все видят этот контент (включая исходный код, полученный браузером), можно безопасно добавить Access-Control-Allow-Origin: *.

AFAIK, Access-Control-Allow-Origin - это просто HTTP-заголовок, отправленный с сервера в браузер. Ограничение его определенным адресом (или его отключение) не делает ваш сайт более безопасным, например, для роботов. Если роботы хотят, они могут просто игнорировать заголовок. Обычные браузеры (Explorer, Chrome и т. Д.) По умолчанию учитывают заголовок. Но такое приложение, как Postman, просто игнорирует это.

Сторона сервера фактически не проверяет «источник» запроса, когда возвращает ответ. Он просто добавляет заголовок http. Это браузер (клиентская часть), который отправил запрос, решает прочитать заголовок контроля доступа и действовать в соответствии с ним. Обратите внимание, что в случае XHR он может использовать специальный запрос OPTIONS, чтобы сначала запросить заголовки.

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

См. Также Возможные проблемы безопасности при настройке Access-Control-Allow-Origin .

Теперь, чтобы ответить на вопрос

Я не могу не чувствовать, что подвергаю свою среду угрозе безопасности.

Если кто-то захочет атаковать вас, он может легко обойти Access-Control-Allow-Origin. Но, включив «*», вы дадите злоумышленнику еще несколько «векторов атаки» для игры, например, с использованием обычных веб-браузеров, которые поддерживают этот HTTP-заголовок.

Вот 2 примера, опубликованных в виде комментариев, когда использование подстановочных знаков действительно проблематично:

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

- Брэд

Предположим, у вас есть обычный домашний маршрутизатор, например Linksys WRT54g или что-то в этом роде. Предположим, что маршрутизатор разрешает запросы из разных источников. Сценарий на моей веб-странице может выполнять HTTP-запросы к общим IP-адресам маршрутизатора (например, 192.168.1.1) и перенастраивать ваш маршрутизатор для разрешения атак. Он даже может использовать ваш маршрутизатор напрямую как узел DDoS. (У большинства маршрутизаторов есть тестовые страницы, которые позволяют выполнять эхо-запросы или простые проверки HTTP-сервера. Этим можно злоупотреблять в массовом порядке.)

- Брэд

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

В сценарии, когда сервер пытается полностью отключить CORS, задав заголовки ниже.

• Access-Control-Allow-Origin: * (сообщает браузеру, что сервер принимает межсайтовые запросы от любого ORIGIN)

• Access-Control-Allow-Credentials: true (сообщает браузеру, что межсайтовые запросы могут отправлять файлы cookie)

В браузерах реализован отказоустойчивый режим, который приведет к ошибке ниже

"Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’"

Так что в большинстве сценариев установка «Access-Control-Allow-Origin» *не будет проблемой. Однако для защиты от атак сервер может поддерживать список разрешенных источников и всякий раз, когда сервер получает запрос на перекрестное происхождение, он может проверить заголовок ORIGIN на соответствие списку разрешенных источников, а затем повторить то же самое в Access-Control-Allow-Origin. заголовок.

Поскольку заголовок ORIGIN не может быть изменен с помощью javascript, запущенного в браузере, вредоносный сайт не сможет его подделать.