Комментарии 4
Как я понимаю, для реализации что №1, что №2 должен быть скомпрометирован бэкэнд. Иначе каким образом может прийти "левый" JSON или CSS (https мы предполагаем априори)? А если это так, то вариантов навредить становится не один и не два, а сотни. Сегодня XSS возможен только если вы сами "попросили" прислать вам сомнительную фигню со стороннего URL.
Добрый день.
На самом деле, https не гарантирует вам "чистый" JSON - сертификаты также можно подделать различными способами, но это тема для отдельной статьи.
Вариантов навредить действительно не один и не два. Их количество ограничивается исключительно фантазией хакера.
XSS действительно в большинстве случаев происходит из-за того, что пользователь сам, как вы сказали, "просит" прислать ему что-то сомнительное. В статье как раз об этом и говорится: хакер не будет "в лоб" атаковать жертву. Он использует методы социальной инженерии и человеческий фактор, чтобы пользователь сам попался в его ловушку.
Третий – ассоциация с IP-адресов авторизованного пользователя. После успешной авторизации в payload токена можно положить какие-то однозначно идентифицирующие сведения о пользователе, например, его IP.
Лучше так не делать, ибо при использовании мобильного инета ip может часто меняться и пользователя будет постоянно выкидывать из авторизации. Можно использовать что-то более стабильное, например, user-agent.
Фантастические веб-уязвимости и где они обитают