Каковы риски безопасности при установке Access-Control-Allow-Origin?


125

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

Ответы:


69

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

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

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


2
Если вы можете привести конкретный пример того, как совместный доступ к аутентификации представляет угрозу безопасности, я поддержу его.
Петрус Терон

1
@Gumbo А как насчет статического контента? (например, статический контент cdn, такой как javascripts, css, статический htmls и т. д.) Есть ли какие-либо проблемы с безопасностью их настройки Access-Control-Allow-Origin: *? Не будет ногинов и т.д, они всем доступны?
Umut Benzer

2
@UmutBenzer Ничего страшного.
Gumbo

25
На самом деле этот ответ не совсем правильный в соответствии с текущим стандартом CORS : «Строка '*' не может использоваться для ресурса, который поддерживает учетные данные». Таким образом, вы не можете заставить запрос использовать временную аутентификацию в виде файлов cookie, кэшированной HTTP-аутентификации или клиентских SSL-сертификатов. Однако, если бы веб-сайт, например, использовал локальное хранилище для аутентификации, это было бы проблемой.
Никлас Б.

2
@NiklasB: Я пробовал этот сценарий, и Chrome действительно следует стандарту CORS, как вы упомянули. т.е. строка " " не поддерживается запросом учетных данных. Вот что сообщает Chrome: «XMLHttpRequest не может загрузить localhost: 12346 / hello . Подстановочный знак» не может использоваться в заголовке «Access-Control-Allow-Origin», если установлен флаг учетных данных. Origin « localhost: 12345 » поэтому доступ запрещен. Режим учетных данных XMLHttpRequest контролируется атрибутом withCredentials ".
factotum

37

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: *.


должно быть «поскольку он разрешает запросы только без файлов cookie» должен быть «поскольку он разрешает запросы только с файлами cookie»?
DJCordhose

3
@DJCordhose no. Access-Control-Allow-Origin: *разрешает запросы только без файлов cookie. Я отредактировал ответ, чтобы немного уточнить.
JaffaTheCake

В чем разница между "*" и регистром без этого заголовка. Это то же самое?
Nigrimmist

Я был бы рад, если бы «В противном случае плохой сценарий мог бы использовать вас как туннель в интрасеть» можно было бы подробнее объяснить.
Сэм Руби

@Nigrimmist Тогда предполетный запрос будет неудачным и доступ к ресурсам будет заблокирован
iamareebjamal

9

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

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

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

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


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

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

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


6
Посмотрите на это с точки зрения неосторожного конечного пользователя. Кто-то может создать вредоносную веб-страницу, которая внедряет JavaScript для передачи данных между реальным сайтом и вредоносным сайтом (допустим, они хотят украсть ваш пароль). Веб-браузер конечного пользователя обычно блокирует это межсайтовое взаимодействие, но если задано Access-Control-Allow-Origin, то оно будет разрешено, и конечный пользователь не станет мудрее.
Brain2000

3
Да, Access-Control-Allow-Origin *настоятельно не рекомендуется устанавливать вредоносный веб-сайт, на котором размещены скрипты для кражи паролей :-)
commonpike

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

5
@commonpike ... пользователь. Другими словами, вы можете просто посетить мой сайт (который может быть даже обычным сайтом, без ничего подозрительного ... возможно, это настоящий законный сайт, который был только что взломан!), Но какой-то JavaScript, который отправляет HTTP-запросы в ваш банк для передачи некоторых средства на мой счет. Банк не знает разницы между запросами со своих страниц и запросами с других страниц. У обоих есть этот файл cookie, позволяющий выполнить запрос.
Брэд

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

6

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

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

- Брэд

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

- Брэд

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


8
Только вот это не сработает. «Строка '*' не может использоваться для ресурса, который поддерживает учетные данные». w3.org/TR/cors/#resource-requests
bayo

@bayotop Как браузер различает страницы, требующие аутентификации, и страницы с другими данными в заголовках?
среда, 08

После прочтения предоставленной ссылки для этой цели используется «флаг поддержки учетных данных». Кажется, что он устанавливается вручную, поэтому предположительно, если кто-то не знал, как правильно настроить CORS, он также мог ошибиться с этим флагом, поэтому я считаю, что вышеуказанные уязвимости возможны.
среда, 08

2
@wedstrom Флаг устанавливает тот, кто делает запрос. В любом случае, приведенные выше сценарии являются примерами CSRF-атак. Разрешение происхождения '*' не сделает вас более уязвимым, чем вы уже являетесь (может быть, немного в редких случаях). В большинстве случаев вы можете сделать злонамеренный межсайтовый запрос, используя формы, поэтому CORS не имеет значения. В случаях, когда вам нужно выполнить запрос AJAX, предполетные запросы будут мешать (это тот момент, когда браузер входит, когда ACAO: '*' и Access-Control-Allow-Credentials: 'true').
Байо

0

В сценарии, когда сервер пытается полностью отключить 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, запущенного в браузере, вредоносный сайт не сможет его подделать.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.