Предотвращая сценарии серверной стороны, XSS
Там кто-либо предварительно сделан сценариями, которые я могу использовать для PHP / MySQL для предотвращения сценариев серверной стороны и инжекций JS?
Я знаю о типичных функциях, таких как htmlentities, специальные символы, представляю замену в виде строки и т.д., но есть ли простой бит кода или функции, которая является отказоустойчивым для всего?
Любые идеи были бы прекрасными. Большое спасибо :)
Править: Что-то универсальное, которое разделяет что-нибудь, что могло быть опасным, т.е. больше, чем / меньше, чем знаки, точки с запятой, слова как "ОТБРАСЫВАНИЕ", и т.д.?
Я в основном просто хочу сжать все, чтобы быть алфавитно-цифровым, я предполагаю...?
5 ответов
Никогда не выводите в поток HTML какие-либо биты данных, которые не были переданы через htmlspecialchars () , и все готово. Простое правило, которому легко следовать, полностью исключает любой риск XSS.
Но как программист это ваша работа.
Вы можете определить
function h(s) { return htmlspecialchars(s); }
, если htmlspecialchars () слишком длинный для записи 100 раз на файл PHP. С другой стороны, использование htmlentities () совсем не обязательно.
Ключевой момент: есть код и есть данные. Если вы их смешаете, то последуют неприятности.
В случае HTML код - это элементы, имена атрибутов, сущности, комментарии. Данные - это все остальное. Данные должны быть экранированы , чтобы их не ошибочно приняли за код.
В случае URL-адресов код - это схема, имя хоста, путь, механизм строки запроса (? , & , = , # ). Данные - это все в строке запроса: имена и значения параметров. Они должны быть экранированы , чтобы их не приняли за код.
URL-адреса, встроенные в HTML , должны быть дважды экранированы (экранированием URL и HTML-экранированием), чтобы гарантировать надлежащее разделение кода и данных.
Современные браузеры способны преобразовывать поразительно сломанную и некорректную разметку во что-то полезное. Однако эту возможность не следует подчеркивать. Тот факт, что что-то происходит, работает (например, URL-адреса в без надлежащего экранирования HTML), не означает, что это хорошо или правильно. XSS - это проблема, которая коренится в: а) людях, не знающих о разделении данных / кода (т. Е.«убегающие») или небрежные и б) люди, которые стараются быть умными в отношении того, какую часть данных им не нужно убирать.
XSS достаточно легко избежать, если вы убедитесь, что не попадаете в категории a) и b).
есть ли простой фрагмент кода или функция, которая является отказоустойчивой для всего?
Нет.
Представление данных, выходящих из PHP, должно быть преобразовано / закодировано специально в соответствии с тем, куда они направляются. И поэтому его следует преобразовывать / кодировать только в том месте, где он выходит из PHP.
С.
для чистого использования пользовательских данных
html_special_chars (); str_replace () и другие функции для удаления небезопасных данных.
Отвечу на вашу редакцию: все, кроме символов <> , не имеет ничего общего с XSS.
И htmlspecialchars () может с ними справиться.
Нет ничего плохого в слове DROP table в тексте страницы;)
Нет, это не так. Риски зависят от того, что вы делаете с данными, вы не можете написать что-то, что делает данные безопасными для всего (если только вы не хотите отбросить большую часть данных)
.