У меня есть текстовое поле формы, которое принимает URL-адрес. Когда форма отправлена, я вставляю это поле в базу данных с надлежащей анти-sql-инъекцией. Мой вопрос, хотя и о xss.
Это поле ввода является URL-адресом, и мне нужно его снова отобразить на странице. Как защитить его от xss на пути в базу данных (я думаю, что ничего не нужно, поскольку я уже позаботился о SQL-инъекции) и на выходе из базы данных?
Давайте сделаем вид, что у нас это так, я упрощаю это, и, пожалуйста, не беспокойтесь о SQL-инъекции. Куда я пойду отсюда после этого?
$url = $_POST['url'];
благодаря
Предполагая, что это будет помещено в содержимое HTML (например, между <body>
и </body>
или между <div>
и </div>
), вам нужно закодировать 5 специальных символов XML (&, <,>, «,»), а OWASP рекомендует включать в себя слэш (/). PHP builtin, htmlentities()
будет выполнять первую часть для вас, а простая str_replace()
может выполнять слэш:
function makeHTMLSafe($string) { $string = htmlentities($string, ENT_QUOTES, 'UTF-8'); $string = str_replace('/', '/', $string); return $string; }
Если, однако, вы будете помещать значение tainted в атрибут HTML, например, предложение href=
для <a
, тогда вам нужно будет закодировать другой набор символов ([пробел]% * +, – /; <=> ^ и |) – и вы должны дважды указывать свои HTML-атрибуты:
function makeHTMLAttributeSafe($string) { $scaryCharacters = array(32, 37, 42, 43, 44, 45, 47, 59, 60, 61, 62, 94, 124); $translationTable = array(); foreach ($scaryCharacters as $num) { $hex = str_pad(dechex($num), 2, '0', STR_PAD_LEFT); $translationTable[chr($num)] = '&#x' . $hex . ';'; } $string = strtr($string, $translationTable); return $string; }
Последней проблемой являются незаконные символы UTF-8 – при доставке в некоторые браузеры некорректная последовательность байтов UTF-8 может вырваться из объекта HTML. Чтобы защитить это, просто убедитесь, что все символы UTF-8, которые вы получили, действительны:
function assertValidUTF8($string) { if (strlen($string) AND !preg_match('/^.{1}/us', $string)) { die; } return $string; }
Модификатор u
в этом регулярном выражении делает его регулярным выражением Unicode. Согласование одного символа,. , мы уверены, что вся строка действительна Unicode.
Поскольку это все зависит от контекста, лучше всего сделать любую из этих кодировок в самый последний возможный момент – перед представлением вывода пользователю. Быть в этой практике также позволяет легко увидеть любые места, которые вы пропустили.
OWASP предоставляет большую информацию об их чит-листах по предотвращению XSS .
Перед отображением пользователю необходимо закодировать его с помощью htmlspecialchars
. Обычно этого достаточно при работе с данными вне тегов <script> и / или атрибутов HTML-тегов.
Не откатывайте свою собственную XSS-защиту, есть слишком много способов, чтобы что-то могло проскальзывать (я больше не могу найти ссылку на определенную XSS-demopage, но количество возможностей ошеломляет: Broken IMG-теги, странные атрибуты и т.д.).
Используйте существующую библиотеку, такую как sseq-lib или извлеките из установленной структуры.
Обновление: вот XSS-demopage .