Атака XSS для обхода функции htmlspecialchars() в атрибуте value

Скажем, у нас есть эта форма, и возможная часть для пользователя, которая вводит вредоносный код, находится ниже

...
<input type=text name=username value=
       <?php echo htmlspecialchars($_POST['username']); ?>>
...

Мы не можем просто поместить тег или javascript: alert(); вызов, потому что значение будет интерпретироваться как строка, а htmlspecialchars отфильтровывает <, > , ', ", поэтому мы не можем закрыть значение с помощью котировок.

Мы можем использовать String.fromCode(.....), чтобы обойти кавычки, но я все еще не могу получить простое окно предупреждения.

Любые идеи?

Ответ 1

Кроме того, важно упомянуть, что предоставление пользователям возможности вводить HTML или JavaScript на вашу страницу (а не ваш источник данных) не несет в себе собственной угрозы безопасности. Уже существуют расширения браузера, которые позволяют вам изменять DOM и скрипты на веб-страницах, но поскольку они только на стороне клиента, они будут единственными, которые будут знать.

Где XSS становится проблемой, когда люди a) используют ее для обхода проверки на стороне клиента или фильтрации ввода или б) когда люди используют ее для манипулирования полями ввода (например, изменение значений тегов OPTION в ACL для предоставления их разрешения у них не должны быть). Единственный способ предотвратить эти атаки - это очищать и проверять входные данные на стороне сервера, а не на валидации на стороне клиента.

Для дезинфекции HTML вне ввода, htmlspecialchars вполне адекватен, если вы не хотите разрешать определенные теги, и в этом случае вы можете использовать библиотеку, такую как HTMLPurifier. Если вы размещаете пользовательский ввод в HREF, ONCLICK или любом атрибуте, который позволяет создавать сценарии, вы просто просите о проблемах.

EDIT: глядя на ваш код, похоже, что вы не цитируете свои атрибуты! Это довольно глупо. Если кто-то поместил свое имя пользователя:

john onclick="alert('hacking your megabits!1')"

Затем ваш script будет анализировать как:

<input type=text name=username value=john onclick="alert('hacking your megabits!1')">

ВСЕГДА используйте кавычки вокруг атрибутов. Даже если они не введены пользователем, это хорошая привычка вступать.

<input type="text" name="username" value="<?php echo htmlspecialchars($_POST['username']); ?>">

Ответ 2

Там один путь. Вы не передаете htmlspecialchars() третий параметр кодирования или правильно проверяете кодировку, поэтому:

$source = '<script>alert("xss")</script>';
$source = mb_convert_encoding($source, 'UTF-7');
$source = htmlspecialchars($source); //defaults to ISO-8859-1
header('Content-Type: text/html;charset=UTF-7');
echo '<html><head>' . $source . '</head></html>';

Работает только в том случае, если вы можете: a) установить страницу для вывода UTF-7 или b) обмануть страницу для этого (например, iframe на странице без набора четких наборов символов). Решение состоит в том, чтобы гарантировать, что все входные данные имеют правильное кодирование и что ожидаемое кодирование правильно установлено на htmlspecialchars().

Как это работает? В UTF-7 символы < > "имеют разные кодовые точки, чем UTF-8/ISO/ASCII, поэтому они не экранируются, если не преобразовать вывод в UTF-8 для обеспечения (см. Расширение iconv).

Ответ 3

value является нормальным атрибутом HTML и не имеет ничего общего с Javascript.
Поэтому String.fromCharCode интерпретируется как буквальное значение и не выполняется.

Чтобы ввести script, сначала нужно заставить синтаксический анализатор закрыть атрибут, с которым будет трудно обойтись без >'".

Вы забыли поставить кавычки вокруг значения атрибута, поэтому все, что вам нужно, это пробел.

Даже если вы указали значение, оно все равно может быть уязвимым; см. эта страница.

Ответ 4

Боже мой, когда вы читаете самый голосующий ответ, в котором говорится, что xss - это риск, только если он хранится, мы знаем, что хакерам и багам Охотнику за головами будет непросто в течение следующего десятилетия. Пришел новый разработчик и примет это предложение как истину... Редактировать: добавить источник https://www.owasp.org/index.php/XSS#Stored_and_Reflected_XSS_Attacks https://portswigger.net/web-security/cross-site- сценарии # отраженного кросс-сайт-сценарии