Изменение размера входного значения HTML

Ответ 1

На самом деле есть два вопроса, которые вы задаете (или, по крайней мере, можно интерпретировать):

• Можно ли вводить цитируемый атрибут value input[type="text"], если кавычки запрещены?

• Можно ли вводить произвольный цитируемый атрибут элемента, если кавычки запрещены.

Второе тривиально показано следующим образом:

<a href="javascript:alert(1234);">Foo</a>

Или

<div onmousemove="alert(123);">...

Первое немного сложнее.

HTML5

В соответствии с спецификацией HTML5:

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

который далее уточняется в цитируемых атрибутах:

Имя атрибута, за которым следуют ноль или более символов пробела, за которым следует одиночный символ U + 003D EQUALS SIGN, за которым следуют ноль или более пробелов, за которым следует один символ "(U + 0022), за которым следует значение атрибута, которое в дополнение к требованиям, приведенным выше для значений атрибутов, не должно содержать буквенных символов U + 0022 ЦИТАТЫ ЦИКЛА (" ) и, наконец, следует за вторым одиночным символом "" " (U + 0022).

Короче говоря, любой символ, кроме "неоднозначного амперсанда" (&[a-zA-Z0-9]+;, когда результат не является допустимой ссылкой на символ), и символ кавычки является допустимым внутри атрибута.

HTML 4.01

HTML 4.01 менее описателен, чем HTML5 о синтаксисе (одна из причин, по которой HTML5 был создан в первую очередь). Однако он скажет это:

Когда script или данные стиля являются значением атрибута (стиля или атрибутов внутренних признаков), авторы должны избегать появления разделительной метки одного или двойного кавычки в пределах значения в соответствии с языком script или стилем условность. Авторы также должны избегать появления "&" если "&" не означает начало символьной ссылки.

Заметьте, это говорит, что должен делать автор, а не то, что должен делать парсер. Таким образом, синтаксический анализатор может технически принять или отклонить неверный ввод (или привести его в действие).

XML 1.0

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 (и большинство экспертов по безопасности) рекомендуют вам кодировать либо все не-альфа-числовые символы, либо &<" внутри значения атрибута. Там нет затрат, только добавленная безопасность зная, как интерпретатор браузера будет интерпретировать значение.

У вас есть? нет. Но глубокая защита предполагает, что, поскольку нет никаких затрат на это, потенциальная выгода стоит того.

Ответ 2

Когда пользователи отправляют данные, вы должны убедиться, что они предоставили что-то, что вы ожидаете.

Например, если вы ожидаете число, убедитесь, что представленные данные являются числом. Вы также можете лить пользовательские данные в другие типы. Все отправленные изначально обрабатываются как строка, поэтому форсирование известных числовых данных в виде целого числа или 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

https://security.stackexchange.com/q/42498/71827

http://php.net/manual/en/filter.examples.sanitization.php

Ответ 3

Если ваш вопрос: "Какие типы 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 полностью разрушает его (в этом случае вы также можете очистить серверную сторону)

Если этого недостаточно - предоставьте дополнительную информацию по вашему вопросу, добавьте больше примеров вашего кода.

Ответ 4

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

Что вы должны быть осторожны, так это то, что вы передаете переменную, и есть способы создания ошибок и т.д., чтобы вызвать ее. Лучше всего убедиться, что данные не отформатированы исполняемым образом в случае ошибок. Но вы правы, если они не являются кавычками, которые вы не можете вырваться, но есть способы, по которым вы или я не понимаем на этом этапе, что позволит это произойти.

Ответ 5

$var = "><script>alert(0);</script> будет работать... Если вы можете закрыть кавычки, вы можете закрыть тег и открыть еще один... Но я думаю, что вы правы, не закрывая цитаты, инъекция невозможна..