Существуют ли какие-либо готовые сценарии, которые я могу использовать для PHP / MySQL для предотвращения серверных сценариев и инъекций JS?
Я знаю о типичных функциях, таких как htmlentities, специальные символы, замену строк и т. Д., Но есть ли простой бит кода или функция, которая является безотказной для всего?
Любые идеи были бы замечательными. Большое спасибо 🙂
EDIT: Что-то общее, которое удаляет все, что может быть опасным, т.е. больше / меньше знаков, полуколоний, слов типа «DROP» и т. д.?
Я просто хочу сжать все, чтобы быть буквенно-цифровым, я думаю …?
Никогда не htmlspecialchars() какой-либо бит данных в поток HTML, который не был передан через htmlspecialchars() и все готово. Простое правило, легко следовать, полностью устраняет любой риск XSS.
Тем не менее, программист – это ваша работа.
Вы можете определить
function h(s) { return htmlspecialchars(s); }
если htmlspecialchars() слишком длинный, чтобы писать 100 раз за PHP-файл. С другой стороны, использование htmlentities() вообще не требуется.
Ключевым моментом является: есть код, и есть данные. Если вы смешиваете два, то возникают плохие вещи.
В случае HTML код – это элементы, имена атрибутов, сущности, комментарии. Данные – все остальное. Данные должны быть экранированы, чтобы не ошибиться в коде.
В случае URL-адресов код – это схема, имя хоста, путь, механизм строки запроса ( ? , & , = , # ). Данные – это все в строке запроса: имена и значения параметров. Их нужно избегать, чтобы не ошибиться в коде.
URL-адреса, встроенные в HTML, должны быть дважды экранированы (путем экранирования URL-адресов и экранирования HTML), чтобы обеспечить надлежащее разделение кода и данных.
Современные браузеры способны разбирать удивительно сломанную и неправильную разметку во что-то полезное. Тем не менее, эта способность не должна быть подчеркнута. Тот факт, что что-то работает (например, URL-адреса в <a href> без надлежащего применения HTML-экранирования) не означает, что это хорошо или правильно. XSS – это проблема, которая коренится в: а) людях, которые не знают о разделении данных / кода (т. Е. «Экранировании») или о неаккуратных и б) людях, которые пытаются быть умными в отношении того, какую часть данных им не нужно бежать.
XSS достаточно легко избежать, если вы убедитесь, что не попадете в категории a) и b).
Я думаю, что Google-caja может быть решением. Я пишу анализатор taint для Java-приложения для обнаружения и предотвращения XSS автоматически. Но не для PHP. Я думаю, что научиться использовать caja не плохо для веб-разработчика.
Нет, нет. Риски зависят от того, что вы делаете с данными, вы не можете написать что-то, что делает данные безопасными для всего (если вы не захотите отказаться от большинства данных)
есть ли простой бит кода или функция, которая является безотказной для всего?
Нет.
Представление данных, выходящих из PHP, должно быть преобразовано / закодировано конкретно в зависимости от того, куда оно идет. И поэтому он должен быть преобразован / закодирован только в том месте, где он покидает PHP.
C.
Вы можете обратиться к OWASP, чтобы лучше понять атаки XSS:
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
Чтобы избежать js-атак, вы можете попробовать этот проект, предоставляемый с помощью преимуществ с открытым исходным кодом:
https://www.opensource-excellence.com/shop/ose-security-suite.html
Раньше у моего сайта были атаки js, и этот инструмент помогает мне блокировать все атаки каждый день. Я думаю, это может помочь вам, ребята, избежать этой проблемы.
Кроме того, вы можете добавить фильтр в свой php-скрипт для фильтрации всех js-атак, вот один шаблон, который может выполнять работу:
if (preg_match ('/ (?: [".] script \ s * () | (?: \ $ \ $? \ s * (\ s * [\ w"]) | (?: / [\ w \ s] + /) | (:.?.? = \ S * / \ ш + / \ с *) | (:( ?: это | окно | топ | родитель | кадры | самостоятельно | содержание) [\ s * [( , "] \ s [\ w \ $]) | (?:, \ s * new \ s + \ w + \ s * [,;) / ms ', strtolower ($ POST [' VARIABLENAME ']))) {filter_variable ($ POST ['VARIABLENAME']);}
Чтобы ответить на ваше издание: все, кроме символов <> , не имеет ничего общего с XSS.
И htmlspecialchars () может справиться с ними.
Нет вреда в слове DROP table в тексте страницы;)
для использования чистых пользовательских данных используйте html_special_chars(); str_replace() html_special_chars(); str_replace() и другие функции для сокращения небезопасных данных.