Уязвимость XSS в PHP-скриптах - PullRequest
3 голосов
/ 07 января 2012

Я искал везде, чтобы попытаться найти решение этой проблемы.Недавно я проводил сканирование на наших веб-сайтах, чтобы найти любые уязвимости для XSS и SQL-инъекций.Некоторые элементы были доведены до моего сведения.

Все данные, введенные пользователем, теперь проверяются и очищаются с помощью filter_var ().

Моя проблема сейчас связана с XSS и людьми, которые манипулируют URL.Простой, который, кажется, везде:

http://www.domainname.com/script.php/">< script>alert('xss');< /script >

Это затем изменяет некоторые из $_SERVER переменных и делает все мои относительные пути к CSS, ссылкам, изображениям и т. Д. Недействительными истраница загружается неправильно.

Я очищаю все переменные, которые используются в скрипте, но я не уверен, как мне удастся удалить эти нежелательные данные в URL.

Заранее спасибо.

Дополнение: Это приводит к тому, что простая ссылка в файле шаблона:

<a href="anotherpage.php">Link</a>

фактически ссылается на:

"http://www.domainname.com/script.php/">< script> alert ('xss'); /anotherpage.php

Ответы [ 3 ]

2 голосов
/ 07 января 2012

Это затем изменяет некоторые переменные $_SERVER и приводит к тому, что все мои относительные пути к CSS, ссылкам, изображениям и т. Д. Становятся недействительными, и страница загружается неправильно.

Звучит так, что вы допустили большую ошибку на своем веб-сайте, и вам следует заново продумать, как вы вводите информацию о ссылках из входных данных в свои выходные.

Только фильтрация входных данных здесь не помогает, вам нужно отфильтроватьвывод также.

Часто легче, если ваше приложение получает запрос, который не совпадает с расширенным набором разрешенных запросов, чтобы вернуть ошибку 404.

Я не уверен, какЯ удаляю эти нежелательные данные в URL.

На самом деле, запрос уже отправлен, поэтому URL задан.Вы не можете "изменить" это.Это просто информация, которая была запрошена.

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


Редактировать: Теперь вы написали более конкретно, что вас беспокоит.Я бы сказал здесь с dqhendricks : кого это волнует?

Если вы действительно чувствуете себя некомфортно из-за того, что пользователь просто использует свой браузер и вводит любой URL, который он считает свободным, сделать этоНу, технически правильный ответ:

400 Неверный запрос ( ref )

И вернуть страницу без или только с полной квалификациейURI (абсолютные URI) или переопределение Base-URI , в противном случае браузер примет URI, введенный в его адресную строку, как Base-URI .См. Унифицированный идентификатор ресурса (URI): общий синтаксис RFC 3986; Раздел 5. Справочное разрешение Характеристики .

1 голос
/ 07 января 2012

Во-первых, если кто-то добавляет это дерьмо в свой URL, кого это волнует, если страница неправильно загружает изображения? также, если запрос недействителен, зачем ему загружать какую-либо страницу? почему вы все равно используете переменные SERVER для получения путей?

во-вторых, вы также должны избегать ввода данных, отправленных пользователем, с помощью соответствующего метода для вашей конкретной базы данных, чтобы избежать внедрения sql. filter_var вообще не поможет.

в-третьих, от xss просто защититься. Любые предоставленные пользователем данные, которые должны отображаться на любой странице, должны быть экранированы с помощью htmlspecialchars (). это легче гарантировать, если вы используете класс представления, в который вы можете встроить этот выход.

0 голосов
/ 07 января 2012

К вашей озабоченности по поводу XSS: измененный URL не попадет на вашу страницу, если вы не используете вслепую связанные переменные $ _SERVER. Тот факт, что относительные ссылки, похоже, включают в себя скрипт, внедренный в URL, является поведением браузера, которое рискует только сломать ваши относительные ссылки. Поскольку вы не ослепляете, используя переменные $ _SERVER, вам не о чем беспокоиться.

К вашему беспокойству о нарушении ваших относительных путей: не используйте относительные пути. Укажите все свои ресурсы, указав путь как минимум к корневому домену (начиная с косой черты), и такого рода повреждение URL-адресов не нарушит работу вашего сайта, как вы описали.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...