XSS и htmlentities

$text = "( = \" ' & \\  </textarea> : ; . " ;

echo htmlentities($text);   

//outputs as -->>     ( = &quot; ' &amp; \  &lt;/textarea&gt; : ; . 

//obviously, htmlentities does nothing to ( ) = ; and .

htmlentities — хорошая линия защиты, но она не помогает в контексте javascript.

не будет ли это написать собственную функцию htmlencode для дальнейшего применения ( ) . ; и символы = также должны быть закодированы?

Таким образом, одна функция сделает вас безопасным по всем направлениям. Я хочу услышать, есть ли проблемы с этим подходом.

Я предполагаю, что вы не сможете исправить javascript, который может навредить вам, без использования одного из следующих 4 символов: ( . ); знак равно


javascript xss html-entities
person Average Joe    schedule 26.03.2012    source источник
comment
Вы размещаете пользовательский контент внутри тега <script>? Это очень плохо...   -  person Niet the Dark Absol    schedule 26.03.2012
comment
Чтобы экранировать данные в JavaScript, используйте json_encode. htmlentities неверно, как и addslashes.   -  person Halcyon    schedule 26.03.2012

Ответы (2)


arrow_upward
0
arrow_downward

не будет ли это написать собственную функцию htmlencode для дальнейшего применения ( ) . ; и символы = также должны быть закодированы?

Нет. JavaScript — это JavaScript, а HTML — это HTML.

Управляющие последовательности, необходимые для безопасного ввода данных в JavaScript, могут привести к появлению посторонних символов в HTML.

Ссылки на символы, необходимые для безопасного ввода данных в HTML, либо нарушат работу JavaScript, либо приведут к появлению неверных символов в выводе JavaScript.

Единственный раз, когда имеет смысл использовать обе функции, это когда вы вставляете необработанные данные в JavaScript, а затем вставляете этот JavaScript в HTML или когда вы вставляете указанные данные в HTML, которые затем вставляются в JS. (Тогда две функции должны будут выполняться над данными последовательно и в правильном порядке).

Я предполагаю, что вы не сможете исправить javascript, который может навредить вам, без использования одного из следующих 4 символов: ( . ); знак равно

Опасное предположение

foo = [1,2,3];
Return value: [1, 2, 3]

Object--
Return value: NaN

foo = [1,2,3]
Error report: Uncaught TypeError: Object NaN has no method 'getOwnPropertyNames'
person Quentin    schedule 26.03.2012
comment
Я вижу, где мой первоначальный вопрос пошел не по плану. Я планировал использовать эту функцию только в контексте html, а под контекстом html я имел в виду не только видимую область содержимого в html, но и содержимое тега; пример: ‹a href='user_generated_content_here' ›text‹/a›. Там user_generated_content_here нужно правильно экранировать. Позаботившись о тех 4 символах, которые а именно ( ); и =, я думал, что буду в безопасности от XSS. Я могу получить некоторую защиту от XSS, например javascript:alert(document.cookies). Добавлением . ( ), который бы умер прямо там. - person Average Joe; 27.03.2012
comment
{ background-url: javascript:alert(1); } или {размер текста: выражение (предупреждение ('XSS')); } . Если я добавлю 4 символа, о которых я упоминал выше, эта попытка javascript умрет. Что касается вашего примера [1,2,3], я не уверен, что вы имели в виду. Какой вред вы можете создать без этих 4 символов, особенно в html-теге! - person Average Joe; 27.03.2012
comment
Если вы помещаете данные в обработчики событий javascript, такие как onclick, вы все равно разрешаете XSS: erlend.oftedal .no/блог/?blogid=124 - person Erlend; 27.03.2012
comment
@John Smith - Если вы принимаете URI от пользователя, вам нужно убедиться, что это настоящий URI и что он использует утвержденную схему (например, HTTP URI). Вы не можете изменить символ ( в URI, чтобы он не работал в URI javascript:, не нарушая URI http:, который включает этот символ. - person Quentin; 27.03.2012
comment
@John Smith. Моя точка зрения заключалась в том, что если JavaScript выполняется, то можно прервать создание объекта для всей страницы без использования (, ), = или ;. - person Quentin; 27.03.2012
comment
@Erlend — Вот почему вам нужно надлежащим образом экранировать данные перед их вставкой в ​​JavaScript, как сказано в моем ответе. До сих пор нет способа сделать данные безопасными для JavaScript, и для HTML, и для JavaScript в HTML, и для HTML в JavaScript с помощью одной-единственной функции. - person Quentin; 27.03.2012
comment
@Quentin - Да, я отвечал на комментарий Джона Смита чуть выше моего. Извините за путаницу. - person Erlend; 27.03.2012

arrow_upward
0
arrow_downward

Вам нужны разные кодировки в зависимости от контекста. Не существует «универсального» кодировщика, который мог бы обрабатывать все сразу. Опасны не персонажи, а контекст, в котором они интерпретируются.

Значения в JavaScript требуют json_encode($value) (другие функции, такие как addslashes(), не будут обрабатывать все крайние случаи. json_encode экранирует </, как того требует HTML <script>).

Значения в JavaScript в атрибутах HTML требуют обоих: htmlspecialchars(json_encode($value)), потому что каждый "уровень" синтаксиса выполняет собственное декодирование при интерпретации данных.

person Kornel    schedule 26.03.2012