А как все-таки Cors нас защищает?

Почитал я разные статьи про Cors, но до конца не понял, от чего эта политика браузеров нас защищает. Опишу, как я понимаю ситуацию. Пусть я захожу на вредоносный сайт. Сайт делает запрос на сервер ВК и вуаля - от моей страницы появляется объявление "Кокаин по закупочным ценам" или что-то вроде того. Из статей в интернете я понял, что уязвимость именно такого рода. То есть, если у нас открыта сессия с каким-то сайтом (ВК например) и, допустим, такая вещь как Cors не существует, тогда, якобы можно нарваться на описанную выше ситуацию и если бы не Cors, то по интернету было бы не безопасно ходить, а мошенникам было бы очень легко гнать трафик. Возможно я неправильно понял уязвимость, но что-то у меня не сходится. Пусть авторизационная сессия, например ВК, работает на кукисах. А для каждого сайта свои куки. Я захожу на вредоносный сайт и у него моих ВК кук нет. Как тогда он сделает запрос будучи не авторизованным? Или ему придется "украсть" куки другим способом? Что мошенникам тогда мешает с их сервера отправить запрос на сервер ВК с моими куками? Суть вопроса в следующем. Опишите, пожалуйста, кратко, от чего нас защищает Cors и что было бы если бы не Cors.


Ответы (2 шт):

Автор решения: nick

Например на форуме вы загружаете страницу в которой один скрипт выполняет запрос на https://myIP.org и передает данные (если бы не CORS) другому скрипту, на той же странице который отправляет ваш IP или еще что то куда то там... В общем это такая штука, которая позволяет 98% юзеров немного расслаблять булки при интернет шопинге, а остальных она просто бесит...

→ Ссылка
Автор решения: Qwertiy

Пусть авторизационная сессия, например ВК, работает на кукисах. А для каждого сайта свои куки. Я захожу на вредоносный сайт и у него моих ВК кук нет

Это не совсем так. Стало не совсем, а было - совсем не.


Независимо от того, с какого сайта идёт запрос, запрос (если он не делается намеренно анонимным) включает куки того сайта, на который он отправляется.

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

Именно за счёт этого работают такие штуки как google adds и другие рекламные сети, а так же, вероятно, гугл-аналитика и яндкек-метрика (про них точно не уверен, но думаю, что да) и куча других вещей.


Теперь насчёт того, что изменилось со временем:

  1. Браузеры могут в соответствии с настройками пользователя блокировать сторонние куки. Я не уверен, какие куки считаются сторонними и спасёт ли это вместо cors. В любом случае, мало кто так поступает.
  2. Теперь сайт может с помощью атрибута SameSite задать для кук, при каких условиях они ему передаются. Насколько я понимаю, Strict и Lax защитят от атаки, None - нет. Причём браузеры забили на обратную совместимость и по умолчанию ставят Lax.

И ещё один момент: cors призван давать защиту по умолчанию. При желании сайт может проверить referer или origin и отфутболить запрос, но разработчик сайта должен это сам запрограммировать. cors же предоставляет защиту как бы из коробки - программист не сделал ничего, но злоумышленник просто так его сайтом не воспользуется.

Впрочем, это работает только при более-менее адекватном сайте, поскольку некоторые запросы всё равно посылаются как есть, но если заголовки не будут соответствовать, то запросивший не получит ответ:

  • все head- и get-запросы - они не должны менять данные, если сайт настолько плох, что что-то меняет на get-запрос, то он уязвим
  • post-запросы с типом отправки формы - видимо, тут обратная совместимость и необходимость отправлять формы на другой сайт перевесили

Также не особо понятны эти мутки с OPTIONS запросом перед, например, пост запросом с контенттайпом application/json. Зачем этот OPTIONS? От чего он спасает?

Опять же пассивная защита. Если сайт получил запрос, то он его может исполнить. Если же послали options, то сайт в любом случае не исполнит требования post-запроса, если браузер ему его не пришлёт.

Что касается application/json. Разрешено отправлять только формы (видимо, так исторически сложилось, что их решили не закрывать cors'ом получив потенциально возможный csrf). Форму отправить как json нельзя, а значит, json запрещён.


А все эти ограничения действуют только на клиентской стороне. С сервера - ходи не хочу. Верно ведь?

Да. Браузер защищает своего пользователя. У пользователя в браузере хранятся его куки от все сайтов и браузер не хочет, чтобы с помощью них пользователю был нанесён вред.

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

Кстати, у fetch добавлен режим запроса mode: "no-cors", в котором cors игнорируется, но и куки не посылаются. Так что, с клиента тоже можно посылать запрос и даже получить ответ, но безопасно для пользователя браузера.

→ Ссылка