Что такое origin?

Если кратко, то Origin — это адрес, с которого отправлен запрос. Он состоит из протокола, домена и порта. Его отправляют в заголовке HTTP-запроса.

Вот пример простейшего origin’a

• Схема (scheme): https — указывает на использование защищенного протокола HTTP.
  
• Хост (host) / eTLD+1: античат — это доменное имя, являющееся одновременно eTLD+1 в данном случае, так как не содержит поддоменов (например, www.codeby.games). « .games » — это домен верхнего уровня (TLD).
  
• Порт (port): 443 — это номер порта, используемый для соединения. 443 — стандартный порт для HTTPS, его часто опускают в записи origin, поскольку он подразумевается по умолчанию, если используется схема https.

Но origin также может содержать большее количество составляющих, например

https://forum.antichat.xyz/attachmen...921ac61dc6.png

Теперь, когда у нас сформировалось понимание данного термина можно задаться вопросом, зачем мы это пытались понять, не правда ли?

Так вот, на данный момент все действия в интернете происходят в парадигме «клиент-серверного» взаимодействия, значит клиент (origin), что-то отправляет, а сервер что-то получает (site) или наоборот.

https://forum.antichat.xyz/attachmen...4095631278.png

Представим, что клиент — это наш браузер, а сервер — это сайт, с которым мы взаимодействуем. Мы спокойно отправляем запросы на сервер, он их обрабатывает, но вдруг мы инициируем выполнение какого-либо JavaScript кода на сайте, который хочет получить наши сессионные cookie, наш клиент отправляет все куки, которые у него есть, а сервер получает куки от всех активных вкладок и в случае, если у нас открыто, например банковское приложение, то благодаря этим сессионым куки файлам злоумышленник может получить доступ к нашему аккаунту.

Только, что мы с вами пришли к атаке типа CSRF (cross-site request forgery), не будем сильно останавливаться не ней, лишь отметим, что суть данной атаки заключается в цепочки действий, позволяющих злоумышленнику с помощью мошеннического сайта или скрипта заставить браузер пользователя выполнять на доверенном сайте действия от его имени: отправлять сообщения, менять пароли, переводить деньги и тд.

Одним из способов защиты от подобных действий является настройка политики SOP.

Что же все-таки за SOP?

Политика одинакового источника (same-origin policy) определяет как документ или скрипт, загруженный из одного источника (origin), может взаимодействовать с ресурсом из другого источника. Это помогает изолировать потенциально вредоносные документы, снижая количество возможных векторов атак.

Здесь мы вспоминаем понятие origin и учимся их отличать. У нас есть ресурс, с которого какой-то скрипт делает запрос, который имеет право на взаимодействие с origin: http://example[.]com/dir/page.html

Рассмотрим возможные варианты взаимодействий при наличии SOP:

Сравниваемый URLПроверкаПричинаhttp[:]//www.example.com/dir/page[.]htmlСоответствуетТот же протокол и доменhttp[:]//www.example.com/dir2/other[.]htmlСоответствуетТот же протокол и доменhttp[:]//username[:]password@www[.]example[.]com/dir2/other.htmlСоответствуетТот же протокол и доменhttp[:]//www[.]example[.]com[:]81/dir/other[.]htmlНе соответствуетТот же протокол и домен, но другой портhttps[:]//www[.]example[.]com/dir/other[.]htmlНе соответствуетОтличается протоколhttp[:]//en[.]example.com/dir/other[.]htmlНе соответствуетОтличается доменhttp[:]//example[.]com/dir/other[.]htmlНе соответствуетОтличается домен (требуется полное соответствие)http[:]//v2[.]www[.]example[.]com/dir/other[.]htmlНе соответствуетОтличается домен (требуется полное соответствие)http[:]//www[.]example[.]com[:]80/dir/other[.]htmlНе определеноЯвное указание порта. Зависит от реализации в браузере.

Практика

Теперь мы понимаем как работает политика SOP, давайте попробуем посмотреть на практике как выглядит импакт, который она приносит.

Для этого создадим два виртуальных сервера NGINX, один будет называться hacker.com, а второй bank.com, но для начала установим и сконфигурируем NGINX

Bash:


https://forum.antichat.xyz/attachments/4938870/1.png

Теперь пропишем конфигурации для наших двух виртуальных хостов, для этого перейдем в директорию
и создадим два файла
и
ФАЙЛ hacker.com

server {
listen 80;
server_name hacker.com;
root /var/www/hacker.com;
index index.html;
}ФАЙЛ bank.com

server {
listen 80;
server_name bank.com;
root /var/www/bank.com;
add_header Set-Cookie "user=bankUser; Secure; HttpOnly; SameSite=None";
index index.html;
}

Далее создадим простейшие начальные страницы для каждого сайта
https://forum.antichat.xyz/attachments/4938870/2.png

Bash:


Теперь нам осталось только «активировать» наши создание виртуальные сервера, перезапустить nginx и добавить наши origin в файл
, а сделать это можно с помощью команд

Bash:


https://forum.antichat.xyz/attachments/4938870/4.png

Теперь у нас есть два собственных сайта,

https://forum.antichat.xyz/attachments/4938870/5.png

Теперь настало время воровать куки, для этого сначала создадим js код, который будет воровать cookie с домена bank.com (представим, что эти куки используются для подтверждения входа в ЛК банка)

Для этого пишем скрипт hack.html

https://forum.antichat.xyz/attachments/4938870/6.png

И пытаемся его выполнить в нашем браузере и видим в запросах успешно вернувшийся ответ от bank.com, который содержит наши cookie

https://forum.antichat.xyz/attachments/4938870/7.png

И вуаля, наши cookie у нас в кармане
Заключение

SOP является одним из фундаментальных механизмов обеспечения безопасности в веб-приложениях. Эта политика играет ключевую роль в предотвращении атак, направленных на кражу данных, таких как CSRF. SOP ограничивает взаимодействие между различными источниками, изолируя потенциально опасные запросы и минимизируя риск несанкционированного доступа.

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