Comments 3
samesite=strict cookies;
Это какой-то неполноценный атрибут всего с 3 вариантами strict/lax & none из-за чего приходиться ставить none при использовании iframe и надеятся на cors и/или Access-Control-Allow-Credentials
Статья классная интересно было прочитать. Но не совсем понял про CSRF.
Правильно понял, что:
Хакер, оставляет ссылку на сайте. Пользователь переходит, и с ним на хакерский сайт отправляются сессионные куки.
Как тогда защищает CSRF-токен?
Не обязательно на сайте, это просто отдельный пример. Хакер может скинуть ссылку где угодно, например в личных сообщениях на хабре. Что то типа: "посмотри, какая интересная статья". Запрос пойдет на уязвимый сайт:
POST /change_pwd HTTP/1.1
....
new_pass=hacked
Если для действия требуется правильно сделанный CSRF-токен, то запрос будет выглядеть иначе:
POST /change_pwd HTTP/1.1
....
new_pass=hacked&csrf_token=Bjkhwiewojinfdewjbldsjhoo
Токен нужно будет как-то взять с сайта, например с кнопки в HTML. Это является чтением данных и не будет простым запросом, поэтому отправить запрос с CSRF-токеном от имени пользователя в одностороннем порядке невозможно.
Чтобы все таки реализовать атаку, придется сначала как-то получить токен, например от имени пользователя получить страницу HTML, где будет токен для данного действия, а потом отправить второй запрос с действием, включающем валидный токен.
Ликбез по распространенным Client-Side уязвимостям