Comments 7
Ещё немного добавлю про HSTS, из того кусочка про этот заголовок можно сделать неверный вывод, что он призван быть аналогом редиректа на httpS, но не сработает, если заходим в первый раз и поэтому нужно дополнительно делать редиректор на сервере. Тут все верно, но можно подумать, что редирект на сервере спасёт больше нежели этот заголовок и его по сути можно не устанавливать, если редирект уже прописан на сервере. Как минимум мне приходилось объяснять почему это не так. Кроме этого, обошли вниманием предзагрузку заголовка и вот почему это важно: есть такой вид атак, как атаки на понижение (downgrade-attacks), которые являются больше частным случаем атаки человек-посредине, но более хитрые, потому что они позволяют либо ухудшить или вовсе убрать шифрование обращений к сайту. И от этих атак редирект на сервере не спасёт, а вот правильно настроенный заголовок - да.
Смысл атаки такой, запрашивая первый раз сайт пользователь передаёт запрос без шифрования (то есть попросту вбивает google.com в браузере) и если в браузере нет (старый) или не настроена функция открывать по умолчанию httpS, то этот запрос может перехватить злоумышленник и от своего имени отправить запрос к сайту, где уже он получит и редирект (если есть) и заголовок из примера в статье и далее уже все запросы будут идти шифрованными… к злоумышленнику, который будет их расшифровывать (своим же ключом, т.к. он и будет «легитимным» пользователем для сервера) и отдавать незашифрованный контент пользователю и при этом у злоумышленника не будет необходимости мучаться с сертификатом - пользователь не будет получать шифрованный контент (ну или будет получать шифрованный, но с ухудшенным шифрованием, которые подвержено расшифровке, что по сути недалеко от этого ушло). Защититься от этого можно двумя способами: 1) пересадить всех пользователей на новые версии браузеров, которые используют открытие сайта по умолчанию по httpS или 2) добавить свой сайт в список сайтов, которые всегда работают по httpS, а для этого понадобиться дописать preload в заголовок; Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. Это, согласен, что вызывает некоторые трудности иногда (если вдруг нужно открыть локальную версию без шифрования и так получилось, что локальная версия открывается как поддомен основного сайта), но все это можно легко решить.
а для этого понадобиться дописать preload в заголовок
В принципе никто не мешает MITM-у дропать все эти лишние заголовки в своей выдаче. Или тут рассчёт на то что этим никто заниматься не будет?
Расчет на то, что юзер один раз когда-то открыл этот сайт у себя дома(без MITMа), и браузер запомнил, что на этот сайт надо ходить по HTTPS. И в следующий раз, даже если юзер попробует открыть его по HTTP, подключившись к открытому вайфаю в кафешке, браузер все равно пойдет на сайт по HTTPS. Расстроив козни злоумышленника
Список сайтов с постоянным httpS (о чем я и писал) обновляется как минимум в Хроме и там уже без разницы дропается заголовок или нет. Нельзя в хроме (не древних версий) открыть сервисы гугла по http по этой причине, даже при выключенном открытии сайтов по умолчанию по httpS
If you own a site that you would like to see included in the preloaded HSTS list you can submit it at https://hstspreload.org. (https://www.chromium.org/hsts)
Но вы выше пишете:
добавить свой сайт в список сайтов, которые всегда работают по httpS, а для этого понадобиться дописать preload в заголовок; Strict-Transport-Security
Собственно это меня и удивило. Всего лишь добавить заголовок и ты в глобальном HSTS? Да ладно?!
Не я понимаю, что Chrome может шпионить за пользователями и собирать свою статистику по этому заголовку, и, по достижению некоего лимита, автоматически принудительно заносить домен в список HSTS… Но звучит диковато.
По ссылке выше указано что нужно маниуально отправлять заявку в спортлото.
Для этого нужно задолго до имплементации мониторить трафик, вся суть HSTS в том чтоб браузер пользователя запомнил что на конкретную веб-страницу нужно ходить только по HTTPS.
Раздел про SOP вышел довольно невнятным - и даже неверным. Как будто автор устал к концу статьи (статья в целом годная!)
"Происхождение скриптов" совершенно неважно в контексте SOP (но важно в контексте CSP, который их может просто заблокировать).
X-Frame-Options регулируют то, разрешает ли ваш сайт внедрять свои страницы как iframe на чужих доменах. (При этом еще надо, чтобы и сам чужой домен разрешил нас внедрять - посредством своей CSP)
Access-Control-Allow-Origin - как раз направлен на то, чтобы разрешать кросс-доменные запросы в определенных сценариях, а не запрещать их. Если этого заголовка нет, то кросс-доменный запрос будет отклонен браузером.
Еще до кучи можно добавить, что Same Origin Policy оперирует понятием Origin (кэп?). А вот SameSite cookie (SameSite=Strict, SameSite=Lax) - с понятием Site. И это не всегда одно и то же! (Одно - подмножество другого)
Frontend Security: о чем вы хотели бы забыть, но не сможете