Предотвращение серверных сценариев, XSS

Question

Существуют ли какие-либо готовые сценарии, которые я могу использовать для PHP / MySQL для предотвращения серверных сценариев и инъекций JS?

Я знаю о типичных функциях, таких как htmlentities, специальные символы, замена строк и т. Д., Но есть ли простой фрагмент кода или функция, которая является отказоустойчивой для всего?

Любые идеи были бы великолепны. Большое спасибо:)

РЕДАКТИРОВАТЬ: Что-то общее, что удаляет все, что может быть опасным, т.е. знаки «больше / меньше», точки с запятой, такие слова, как «DROP» и т. д.?

Я просто хочу сжать все, чтобы они были буквенно-цифровыми, наверное ...?

Answer 1

Никогда не выводите какой-либо бит данных в поток 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).

Answer 2

Я думаю Google-caja может быть решение. Я пишу анализатор заражения для веб-приложения Java для автоматического обнаружения и предотвращения XSS. Но не для PHP. Я думаю, научиться использовать Caja не плохо для веб-разработчика.

Answer 3

Есть ли простой фрагмент кода или функция, которая является отказоустойчивой для всего?

номер

Представление данных, выходящих из PHP, должно быть конвертировано / закодировано в соответствии с тем, куда они движутся. И поэтому следует преобразовывать / кодировать только в том месте, где он покидает PHP.

C.

Answer 4

Нет, нет. Риски зависят от того, что вы делаете с данными, вы не можете написать что-то, что делает данные безопасными для всего (если вы не хотите отбрасывать большую часть данных)

Answer 5

Вы можете обратиться к OWASP, чтобы лучше понять атаки XSS:

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

Чтобы избежать js-атак, вы можете попробовать этот проект с открытым исходным кодом:

https://www.opensource -excellence.com / магазин / ОСЭ-безопасности suite.html

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

Кроме того, вы можете добавить фильтр в ваш php-скрипт для фильтрации всех js-атак, вот один шаблон, который может выполнять работу:

if (preg_match ('/ (?: [".] Script \ s * () | (?: \ $ \ $? \ S * (\ s * [\ w"]) | (?: / [ \ ш \ S] + /) | (:.?.? = \ S * / \ ш + / \ с *) | (:( ?: это | окно | топ | родитель | кадры | самостоятельно | содержание) [\ s * [(, "] \ s [\ w \ $]) | (?:, \ S * new \ s + \ w + \ s * [,;) / ms ', strtolower ($ POST [ 'VARIABLENAME']))) { filter_variable ($ POST [ 'VARIABLENAME']); }

Answer 6

для чистого использования пользовательских данных html_special_chars(); str_replace() и другие функции для вырезания небезопасных данных.

Answer 7

Чтобы ответить на ваше издание: все, кроме <> символов, не имеет ничего общего с XSS.
И htmlspecialchars () может справиться с ними.

Нет слов в слове DROP table в тексте страницы;)