Статья Так все-таки SOP или СУП?

Нет, в этой статье не пойдет речь о приготовлении вкусного томатного или сырного супа. В данной статье пойдет речь о таком инструменте как Same-origin Policy и от чего он помогает защищаться, но перед тем, как разбираться, что такое “SAME” и “POLICY” нужно понимать значение термина ORIGIN, с ним и разберемся в первую очередь.

Что такое origin?

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

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

Посмотреть вложение 77885

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

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

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

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

Представим, что клиент — это наш браузер, а сервер — это сайт, с которым мы взаимодействуем. Мы спокойно отправляем запросы на сервер, он их обрабатывает, но вдруг мы инициируем выполнение какого-либо 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

sudo apt install nginx
sudo service nginx start

Теперь пропишем конфигурации для наших двух виртуальных хостов, для этого перейдем в директорию /etc/nginx/sites-available и создадим два файла hacker.com и bank.com

ФАЙЛ 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; }

Далее создадим простейшие начальные страницы для каждого сайта

sudo mkdir -p /var/www/hacker.com /var/www/bank.com
echo '<html><body><h1>Hacker.com</h1></body></html>' > /var/www/hacker.com/index.html
echo '<html><body><h1>Bank.com</h1></body></html>' > /var/www/bank.com/index.html

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

sudo ln -s /etc/nginx/sites-available/hacker.com /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/bank.com /etc/nginx/sites-enabled/
sudo systemctl restart nginx

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

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

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

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

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

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

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