небольшой вопрос об уязвимостях XSS

Question

Я хочу использовать переключатель в стиле css на живом сервере. Я спрашивал об IRC, и парень сказал, что есть большая дыра в XSS. я не знаю слишком много об уязвимостях XSS. Я надеюсь, что кто-то может помочь мне обеспечить его!

я использовал этот урок для css switcher: http://net.tutsplus.com/tutorials/javascript-ajax/jquery-style-switcher/

и парень сказал, что уязвимость на стороне PHP скрипта!

Любые советы будут высоко оценены!

Кроме того, если бы кто-то мог заново сделать весь сценарий более безопасным способом, потому что - пожалуйста, сделайте много запросов от net.tutsplus.com, которые его используют, будут благодарны!

Answer 1

Проблема, с которой я сталкиваюсь в этом сценарии, состоит в том, что есть значение, которое приходит от клиента $_COOKIE['style'] и напрямую выводится на странице.

<link id="stylesheet" type="text/css" href="css/<?php echo $style ?>.css" rel="stylesheet" />

Возможно, значение cookie может быть взломано внешнимсайт в некоторых конкретных условиях.Кроме того, это значение cookie также устанавливается в style-switcher.php без какой-либо фильтрации на основе параметра GET.

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

Пример:

<?php  
   if(!empty($_COOKIE['style'])) $style = $_COOKIE['style'];  
   else $style = 'day';  

   // List of possible theme //
   $listStyle = array('day', 'night', 'foobar');
   if (!in_array($style, $listStyle)) {
        $style = $listStyle[0];
   }
?> 

Answer 2

href="css/<?php echo $style ?>.css"

Каждый раз, когда вы выводите текстовую строку в HTML, вы должны использовать htmlspecialchars() в качестве значения, в противном случае символы вне диапазона, такие как <, & или в этом случае ", будут ломатьсявне контекста (значения атрибута) и разрешить злоумышленнику вставить произвольный HTML-код на страницу, включая содержимое JavaScript.

Это в дыре для HTML-инъекции, и вы должны это исправить.Однако это еще не является уязвимостью XSS, поскольку источником $style является $_COOKIE.Этот cookie должен быть установлен вашими скриптами или самим пользователем;в отличие от значений $_GET и $_POST, он не может быть установлен в браузере пользователя третьей стороной.Это становится уязвимостью только в том случае, если вы позволяете третьей стороне устанавливать для файлов cookie пользователя произвольные значения.

Однако style-switcher.php делает именно это:

$style = $_GET['style'];  
setcookie("style", $style, time()+604800);

без проверкичтобы убедиться, что $style является утвержденным значением, и нет проверки того, что запрос на переключение стилей был сделан самим пользователем, а не произвольной ссылкой на сторонний сайт: то есть он уязвим для XSRF.Скажем, злоумышленник включил ссылку или img src на страницу, которую посетил пользователь, указывая:

http://www.example.com/style-switcher.php?style="><script>steal(document.cookie);</script>

, что сценарий теперь будет запускаться каждый раз, когда пользователь загружает страницу с вашего сайта.(Технически, символы ", ; и < / > в этом примере необходимо кодировать URL-адресом с %, но я оставил это здесь для удобства чтения.)

(Кроме того, вы действительно должны использовать форму POST для этого, так как она имеет побочный эффект.)

Что еще хуже, тот же скрипт содержит прямую эхо-инъекцию, которая определенно уязвима для XSS:

if(isset($_GET['js'])) {  
    echo $style;  
}

Это отверстие позволяет вводить произвольное содержимое.Хотя обычно вы ожидаете, что этот скрипт с js будет вызываться XMLHttpRequest (через jQuery get()), ничто не мешает злоумышленнику вызвать его, связав пользователя с URL-адресом, например:

http://www.example.com/style-switcher.php?style=<script>steal(document.cookie);</script>&js=on

и в ответ они получат эхо-ответ <script> на странице, которая без явно установленного заголовка Content-Type будет по умолчанию иметь значение text/html, в результате чего на вашем сайте будет выполнен выбор JavaScript злоумышленника.контекст безопасности.

header("Location: ".$_SERVER['HTTP_REFERER']);

Это не очень хорошая идея по другим причинам.Заголовок Referer не гарантированно попадет на ваш сервер.Чтобы убедиться, что это работает, передайте в сценарий URL-адрес для возврата в параметре.

Я, вероятно, не стал бы беспокоиться об этом со стороны PHP.Я бы просто установил соответствующий cookie из JavaScript и location.reload() или изменил бы DOM таблицы стилей для обновления.Сценарий PHP - это попытка заставить коммутатор работать без JavaScript, но если вы не можете быть обеспокоены тем, как правильно и безопасно реализовать его с защитой XSRF, это является ответственностью.

Если вы включаете альтернативные таблицы стилей в виде <link rel="alternate stylesheet"> вы все равно будете предоставлять поддержку переключения таблиц стилей пользователям без JavaScript.

Answer 3

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