Вам нужно преобразовать что-либо помимо кавычек (") в (") внутри:
<input type="text" value="$var">
Я лично не вижу, как вы можете вырваться из этого, не используя " on*=....
Правильно ли это?
Изменить. По-видимому, некоторые люди считают, что мой вопрос слишком расплывчатый;
<input type="text" value="<script>alert(0)</script>"> не выполняется. Таким образом, невозможно исключить использование без использования ".
Правильно ли это?
На самом деле есть два вопроса, которые вы задаете (или, по крайней мере, можно интерпретировать):
Можно ли вводить цитируемый атрибут value input[type="text"], если кавычки запрещены?
Можно ли вводить произвольный цитируемый атрибут элемента, если кавычки запрещены.
Второе тривиально показано следующим образом:
<a href="javascript:alert(1234);">Foo</a>
Или
<div onmousemove="alert(123);">...
Первое немного сложнее.
В соответствии с спецификацией HTML5:
Значения атрибутов представляют собой смесь текстовых и символьных ссылок, за исключением дополнительного ограничения того, что текст не может содержать неоднозначный амперсанд.
который далее уточняется в цитируемых атрибутах:
Имя атрибута, за которым следуют ноль или более символов пробела, за которым следует одиночный символ U + 003D EQUALS SIGN, за которым следуют ноль или более пробелов, за которым следует один символ "(U + 0022), за которым следует значение атрибута, которое в дополнение к требованиям, приведенным выше для значений атрибутов, не должно содержать буквенных символов U + 0022 ЦИТАТЫ ЦИКЛА (" ) и, наконец, следует за вторым одиночным символом "" " (U + 0022).
Короче говоря, любой символ, кроме "неоднозначного амперсанда" (&[a-zA-Z0-9]+;, когда результат не является допустимой ссылкой на символ), и символ кавычки является допустимым внутри атрибута.
HTML 4.01 менее описателен, чем HTML5 о синтаксисе (одна из причин, по которой HTML5 был создан в первую очередь). Однако он скажет это:
Когда script или данные стиля являются значением атрибута (стиля или атрибутов внутренних признаков), авторы должны избегать появления разделительной метки одного или двойного кавычки в пределах значения в соответствии с языком script или стилем условность. Авторы также должны избегать появления "&" если "&" не означает начало символьной ссылки.
Заметьте, это говорит, что должен делать автор, а не то, что должен делать парсер. Таким образом, синтаксический анализатор может технически принять или отклонить неверный ввод (или привести его в действие).
XML 1.0 Spec определяет атрибут как:
Атрибут:: = Имя Eq AttValue
где AttValue определяется как:
AttValue:: = ' "' ([^ &" ] | Ссылка) * '' '| "'" ([^ < & '] | Ссылка) * "'"
& похож на концепцию "двусмысленного амперсанда" из HTML5, однако в основном он говорит "любой неуправляемый амперсанд".
Обратите внимание, что он явно отклоняет < от значений атрибута.
Таким образом, хотя HTML5 позволяет это, XML1.0 явно отрицает это.
Это означает, что для совместимого и безболезного анализатора HTML5 игнорирует символы < в атрибуте, а XML будет ошибочно.
Это также означает, что для совместимого и безболезненного анализатора HTML 4.01 будет вести себя неуказанными и потенциально нечетными способами (поскольку спецификация не описывает поведение).
И это доходит до сути проблемы. Раньше HTML был такой свободной спецификацией, что в каждом браузере были несколько разные правила для того, как он будет обрабатывать искаженный html. Каждый попытается "исправить" его или "интерпретировать" то, что вы имели в виду. Это означает, что, хотя браузер, совместимый с HTML5, не будет запускать JS в <input type="text" value="<script>alert(0)</script>">, нечего сказать, что браузер, совместимый с HTML 4.01, не будет. И нечего сказать, что ошибка может отсутствовать в парсере XML или HTML5, который заставляет его выполнять (хотя это было бы довольно значительной проблемой).
THAT, почему OWASP (и большинство экспертов по безопасности) рекомендуют вам кодировать либо все не-альфа-числовые символы, либо &<" внутри значения атрибута. Там нет затрат, только добавленная безопасность зная, как интерпретатор браузера будет интерпретировать значение.
У вас есть? нет. Но глубокая защита предполагает, что, поскольку нет никаких затрат на это, потенциальная выгода стоит того.
Когда пользователи отправляют данные, вы должны убедиться, что они предоставили что-то, что вы ожидаете.
Например, если вы ожидаете число, убедитесь, что представленные данные являются числом. Вы также можете лить пользовательские данные в другие типы. Все отправленные изначально обрабатываются как строка, поэтому форсирование известных числовых данных в виде целого числа или float делает санитацию быстрой и безболезненной.
Вам нужно убедиться, что поля, в которых не должно быть содержимого HTML, фактически не содержат HTML. Существуют различные способы решения этой проблемы.
Вы можете попробовать избежать ввода HTML с помощью htmlspecialchars. Вы не должны использовать htmlentities для нейтрализации HTML, так как он также будет выполнять кодирование акцентированных и других символов, которые, по его мнению, также должны быть закодированы.
Вы можете попробовать удалить любой возможный HTML. strip_tags является быстрым и легким, но также неаккуратным. HTML-очиститель делает гораздо более тщательную работу как с удалением всего HTML, так и с помощью выборочного белого списка тегов и атрибутов.
Вы можете использовать OWASP PHP Filters. Они действительно просты в использовании и эффективны.
Вы можете использовать расширение фильтра которое обеспечивает комплексный способ дезинфекции ввода пользователя.
<сильные > Примеры
приведенный ниже код удалит все теги HTML из строки:
$string = "<h1>Hello, World!</h1>";
$new_string = filter_var($string, FILTER_SANITIZE_STRING);
// $new_string is now "Hello, World!"
Приведенный ниже код гарантирует, что значение переменной является допустимым IP-адресом:
$ip = "127.0.0.1";
$valid_ip = filter_var($ip, FILTER_VALIDATE_IP);
// $valid_ip is TRUE
$ip = "127.0.1.1.1.1";
$valid_ip = filter_var($ip, FILTER_VALIDATE_IP);
// $valid_ip is FALSE
Санитарная обработка и проверка адресов электронной почты:
<?php
$a = '[email protected]';
$b = 'bogus - at - example dot org';
$c = '([email protected])';
$sanitized_a = filter_var($a, FILTER_SANITIZE_EMAIL);
if (filter_var($sanitized_a, FILTER_VALIDATE_EMAIL)) {
echo "This (a) sanitized email address is considered valid.\n";
}
$sanitized_b = filter_var($b, FILTER_SANITIZE_EMAIL);
if (filter_var($sanitized_b, FILTER_VALIDATE_EMAIL)) {
echo "This sanitized email address is considered valid.";
} else {
echo "This (b) sanitized email address is considered invalid.\n";
}
$sanitized_c = filter_var($c, FILTER_SANITIZE_EMAIL);
if (filter_var($sanitized_c, FILTER_VALIDATE_EMAIL)) {
echo "This (c) sanitized email address is considered valid.\n";
echo "Before: $c\n";
echo "After: $sanitized_c\n";
}
?>
Ссылка:
Каковы наилучшие функции деструкции ввода PHP?
http://code.tutsplus.com/tutorials/sanitize-and-validate-data-with-php-filters--net-2595
Если ваш вопрос: "Какие типы xss-атак возможны", тогда вам лучше это сделать. Я просто оставлю несколько примеров того, почему вы должны санировать ваши входы
Если ввод генерируется echo '<input type="text" value="$var">', тогда простой ' прерывает его.
Если ввод является простым HTML на странице PHP, тогда value=<?php deadly_php_script ?> прерывает его
Если это обычный HTML-код в HTML файле, то преобразования двухбуквенных номеров должно быть достаточно.
Хотя преобразование других специальных символов (например, <, > и т.д.) является хорошей практикой. Ввод делается для ввода информации, которая будет храниться на сервере\передана на другую страницу \script, поэтому вам нужно проверить, что может сломать эти файлы. Скажем, у нас есть эта настройка:
index.html
<form method=post action=getinput.php>
<input type="text" name="xss">
<input type="submit"></form>
getinput.php:
echo $_POST['xss'];
Входное значение ;your_deadly_php_script полностью разрушает его (в этом случае вы также можете очистить серверную сторону)
Если этого недостаточно - предоставьте дополнительную информацию по вашему вопросу, добавьте больше примеров вашего кода.
Я считаю, что человек имеет в виду атаки на межсайтовый скриптинг. Они отметили это как php, security и xss
возьмите, например,
<input type="text" value=""><script>alert(0)</script><"">
Вышеприведенный код выполнит код окна предупреждения;
<?php $var= "\"><script>alert(0)</script><\""; ?>
<input type="text" value="<?php echo $var ?>">
Это также выполнит окно предупреждения. Чтобы решить эту проблему, вам нужно сбежать ", < > и еще несколько, чтобы быть в безопасности. PHP имеет несколько функций, которые стоит посмотреть, и у каждого есть свои взлеты и падения!
htmlentities() - Convert all applicable characters to HTML entities
htmlspecialchars() - Convert special characters to HTML entities
get_html_translation_table() - Returns the translation table used by htmlspecialchars and htmlentities
urldecode() - Decodes URL-encoded string
Что вы должны быть осторожны, так это то, что вы передаете переменную, и есть способы создания ошибок и т.д., чтобы вызвать ее. Лучше всего убедиться, что данные не отформатированы исполняемым образом в случае ошибок. Но вы правы, если они не являются кавычками, которые вы не можете вырваться, но есть способы, по которым вы или я не понимаем на этом этапе, что позволит это произойти.
$var = "><script>alert(0);</script> будет работать... Если вы можете закрыть кавычки, вы можете закрыть тег и открыть еще один... Но я думаю, что вы правы, не закрывая цитаты, инъекция невозможна..