Комментарии 8
Вы забыли упомянуть о Mutated XSS в списке типов
Да, забыл. В русской версии страницы об XSS на википедии оно не упомяналось.
Почитал об этом виде XSS пару статей. И правда этот вид XSS является самым неуловимым, а поэтому и самым интересным для дальнейшего его изучения. В будущем буду более тщательно искать информацию, чтобы не упустить подобных интересных фактов.
Столько воды, что у меня телефон умер.
Делаем XSS на клиенте
Удивляемся, что XSS работает
"Нужно использовать стандартные инструменты, которые работают наиболее очевидным образом"(на самом деле, сейчас везде SPA и дотнет будет отдавать всё данные по API приложению на ангуляре / реакте / вью).
Rocket science просто, особенно рекомендации для webforms / aspx, которые остались на фреймворке и не поддерживаются на core / .net 5+.
Я понимаю, что многие современные приложения уже не используют webforms / aspx, однако все еще остались веб-приложения или сайты, в которых все еще используется webforms / aspx. И те кто будет их дорабатывать или переписывать могут не знать о возможности защиты от XSS при помощи возможностей данного фреймворка. Поэтому я и решил упомянуть об этом.
Замечание насчет React / Vue: некорректное использование их компонентов или просто наличие уязвимостей в данных фреймворках (которые просто еще не заметили и не исправили) могут все еще привести к появлению XSS уязвимостей. Не обязательно что уязвимости будут иметься в самих фреймворках, возможно сочетание данных фреймсворков с другими технологиями может привести к XSS уязвимостям. Поэтому даже грамотное испольщзование этих фреймворков модет привести к XSS уязвимости при интеграции с другой технологией.
Из моего небольшого опыта веб-программирования я знаю, что в локальном хранилище браузера иногда хранятся токены для проверки аутентификации пользователя на нескольких сайтах или в нескольких веб-приложениях.
если в локальном хранилище в браузере пользователя имеется необходимый токен, то аутентификация игнорируется и сразу предоставляется доступ к аккаунту пользователя;
если токена в локальном хранилище браузера нет, то вначале пользователь проходит аутентификацию.
Дополнительно стоит еще и IP-адрес при запросе проверять — если не совпадает с адресом при аутентификации, то токен считается устаревшим и пользователь отправляется на переаутентификацию. Теоретически помогает от описанного воровства токенов…
Спасибо за информацию. Постараюсь не забыть об IP-адресе, если буду разрабатывать веб-приложение, использующее подобные токены. А насет защиты от XSS, то возможно в этом случае проверка IP-адреса и поможет, однако в статье приводится простейший пример XSS уязвимости. В других же случаях проверка IP- адреса может не помочь защититься от XSS.
Ест-но... Не всегда проверка по ip допустима (привет мобильным сетям и кафешкам), не защищает от внутренних угроз и NAT и пр..
Но для критичных вещей, да ещё и вкупе с коротким временем жизни токена вполне востребована
XSS: атака и защита с точки зрения C# программирования