Кодирование HTML предотвращает использование безопасности XSS?
Путем простого преобразования следующего ("большие 5"):
& -> &
< -> <
> -> >
" -> "
' -> '
Вы предотвратите нападения на XSS?
Я думаю, что Вы должны к белому списку на символьном уровне также, предотвратить определенные нападения, но следующий ответ указывает, что сверхусложняет ситуацию.
ОТРЕДАКТИРУЙТЕ Эту страницу детали it does not prevent more elaborate injections, does not help with "out of range characters = question marks" when outputting Strings to Writers with single byte encodings, nor prevents character reinterpretation when user switches browser encoding over displayed page. В сущности просто выход из этих символов, кажется, вполне наивный подход.
2 ответа
Сможете ли вы предотвратить атаки XSS?
Если вы сделаете это, ускользнув от в нужное время (*), то да, вы предотвратите HTML-инъекцию. Это наиболее распространенная форма XSS-атаки. Это не просто вопрос безопасности, вам в любом случае необходимо выполнить экранирование, чтобы строки с этими символами в любом случае отображались правильно. Проблема безопасности - это подмножество проблемы правильности.
Я думаю, что вам нужно внести в белый список и уровень персонажа, чтобы предотвратить определенные атаки.
Нет. HTML-экранирование будет отображать каждую из этих атак как неактивный простой текст на странице, что вам и нужно. Диапазон атак на этой странице демонстрирует различные способы выполнения HTML-инъекций, которые могут обойти глупые «фильтры XSS», которые некоторые серверы развертывают для предотвращения распространенных атак HTML-инъекций. Это демонстрирует, что «фильтры XSS» по своей природе негерметичны и неэффективны.
Существуют и другие формы XSS-атаки, которые могут или не могут повлиять на вас, например, плохие схемы для URI, отправленных пользователем ( javascript: и др.), Внедрение кода в данные, отображаемые в блоке JavaScript. (где вам нужно экранирование в стиле JSON) или в таблицы стилей или заголовки ответов HTTP (опять же, вам всегда нужна соответствующая форма кодирования, когда вы перетаскиваете текст в другой контекст; вы всегда должны быть подозрительными, если увидите что-либо с неэкранированной интерполяцией, например, PHP "строка $ var строка" ).
Также есть обработка загрузки файлов, политика происхождения Flash, чрезмерно длинные последовательности UTF-8 в устаревших браузерах и проблемы с генерацией контента на уровне приложения; все это потенциально может привести к межсайтовому скриптингу. Но HTML-инъекция - это основная проблема, с которой сталкивается каждое веб-приложение, и большинство PHP-приложений сегодня ошибаются.
(*: при вставке текстового содержимого в HTML, и ни в коем случае. Не используйте HTML-экранирование данных отправки формы в $ _ POST / $ _ GET в начале вашего скрипта; это распространенная ошибочная ошибка.)
Меры противодействия зависят от контекста, в который вставляются данные. Если вы вставляете данные в HTML, замена метасимвола HTML на управляющие последовательности (т.е. ссылки на символы) предотвращает вставку HTML-кода.
Но если вы вставляете данные в другой контекст (например, значение атрибута HTML, которое интерпретируется как URL), у вас есть дополнительные метасимволы с различными экранирующими последовательностями, с которыми вам придется иметь дело.