Comments 35
Думаю, стоило бы добавить информацию и о CSRF.
Поправьте по тексту
>> Используйте экранирование выходных данных
входных
>> Используйте экранирование выходных данных
входных
Стоит добавить о случаях, когда никакие экранирования/конвертации символов и т.п. вещи не помогут
- Небезопасное использование JSONP. Использование кастомных callback'ов может привести не только к утечке данных, но и к XSS. Случай раз, два
- Ссылки в href. Пользователь может подставить в тэг <a> ссылку вида javascript:func();, что может привести к XSS. В javascript: нет никаких спец. символов, которые преобразуются функциями для защиты от подобных атак
- Скрипты редиректа. Схожий случай с пунктом выше. Редиректы через js, вида document.location=USER_VALUE также могут привести к XSS.
- Если пользователь может задать свой кастомный CSS стиль — у него есть возможность выполнить произвольный JS (например, в IE 7)
Об остальном знал, кроме второго пункта — есть ли какие-то статьи, в которых говорится о том, как защититься от подобной уязвимости (javascript в href)?
Использовать регулярки, вида ^(http|https), которые строго укажут начало строки для ссылок.
Для примера, URL для подключания jQuery: //code.jquery.com/jquery-1.10.2.min.js
Извините, но не понял комментария.
Всмысле, что корректрый URL не обязательно начинается с http или https.
Согласен, но непонятно, зачем давать подобные трик с // пользователю, когда его данные подставляются в <a href=...">
Согласен, экзотика, натянуто и вряд ли будет нужно в 99.9% случаев.
Я просто пытался проиллюстрировать, что собственные регулярки надо использовать крайне осторожно, очень хорошо разбираясь как в регулярках, так и в формате того, что именно прогоняется через регулярку. А по возможности лучше использовать встроенные средства языка или популярные библиотеки.
Например подставляя строку:
которая проходит проверку регуляркой ^(http|https)
в шаблон
получаем выполнение произвольного JS.
Я просто пытался проиллюстрировать, что собственные регулярки надо использовать крайне осторожно, очень хорошо разбираясь как в регулярках, так и в формате того, что именно прогоняется через регулярку. А по возможности лучше использовать встроенные средства языка или популярные библиотеки.
Например подставляя строку:
http://" onmouseover="javascript:alert('ha-ha')которая проходит проверку регуляркой ^(http|https)
в шаблон
<a href="%url%">bla-bla</a>получаем выполнение произвольного JS.
Фильтровать входящие данные на уровне php-приложения с помощью функции filter_var(), для URL пример:
if(filter_var($_POST['url'], FILTER_VALIDATE_URL)) {
echo 'okay bro';
}
Есть статьи такие: php.net/manual/ru/function.urlencode.php
По п.1:
Меня уже забавляет как настойчиво предлагают эти функции для фильтрации данных.
Это не камень в огород автора. Отнюдь.
То же самое предлагают и разработчики Synfony, например.
Но. Если мы заглянем внутрь, то неожиданно обнаружим, что на самом деле разработчики эти функции не используют.
Лучше использовать расширение
ua2.php.net/manual/ru/book.filter.php
Эти функции работают гораздо лучше, имеют гибкую настройку, поддерживают callable.
Это позволяет создать хороший, легко расширяемый и адаптируемый класс валидации и фильтрации данных в вашем проекте.
Меня уже забавляет как настойчиво предлагают эти функции для фильтрации данных.
Это не камень в огород автора. Отнюдь.
То же самое предлагают и разработчики Synfony, например.
Но. Если мы заглянем внутрь, то неожиданно обнаружим, что на самом деле разработчики эти функции не используют.
Лучше использовать расширение
ua2.php.net/manual/ru/book.filter.php
Эти функции работают гораздо лучше, имеют гибкую настройку, поддерживают callable.
Это позволяет создать хороший, легко расширяемый и адаптируемый класс валидации и фильтрации данных в вашем проекте.
В первую очередь нужно использовать мозг, а уже потом «экранирование входных\выходных данных».
А так все и лепят mysql_escape_string(addslases(htmlspecialchars(strip_tags($data))), просто потому-что слышали, что это защищает от каких-то «плохих» данных.
А так все и лепят mysql_escape_string(addslases(htmlspecialchars(strip_tags($data))), просто потому-что слышали, что это защищает от каких-то «плохих» данных.
От себя мог бы дать только один совет: используйте нормальные фреймворки (symfony 2, yii, laravel 4), и вам не придётся писать очередные костыли.
Проблему нужно понимать, а не советовать волшебные функции/фреймворки которые защищают от чего-то страшного и непонятного, зашифрованного в аббревиатуре XSS.
От XSS можно ещё забавно защищаться на клиент сайде. Писал однажды такое решение. Это когда все пришедшие с сервера данные прогоняются через функцию, которая режет недопустимые тэги и параметры допустимых. Для веб приложений это решение актуально тем, что после ввода пользователем некоторых данных хочется тут же их отобразить до прогона соединения на сервер и обратно.
Самое полезное здесь — это список литературы.
Не совсем. Эту статью пишет студент, молодой специалист в области ИБ. Он изучил материал и делится им. Понятно, что такие специалисты, как BeLove, это знают уже давно :)
Пост рассчитан на начинающих специалистов, которые хотят также, как и автор, научиться. А PentestIT помогает ему это сделать.
Пост рассчитан на начинающих специалистов, которые хотят также, как и автор, научиться. А PentestIT помогает ему это сделать.
UFO just landed and posted this here
Перед автором стояла задача объединить уже имеющиеся лучшие практики в одной статье, поэтому в ней отсутствует какая-либо новизна.
Если отклонить все остальное, то фамилия д’Арк будет отклонена — лучше отклонить достоверную информацию, чем принять вредоносные данные.
И где эти данные могут навредить? Лучше бы это правило на эту статью применить
Если отклонить все остальное, то фамилия д’Арк будет отклонена — лучше отклонить достоверную информацию, чем принять вредоносные данные.
Очень полезный совет. Пользователи будут безмерно рады, что вы встроили отличную защиту.
>> Используйте экранирование входных\выходных данных. Применяйте встроенные функции для очистки кода от вредоносных скриптов. К ним относятся такие функции как htmlspecialchar(), htmlentities() и strip_tags().
Очистки? Замена < на < перед сохранением в базу — это какой-то вредный совет, а не очистка.
Пользователи потом удивляются, почему у них символы «больше», «меньше» не выводятся
Вообще никогда никакие входные plain/text данные не приходится вот так вот мучать, если они выводятся нормальным способом.
Очистки? Замена < на < перед сохранением в базу — это какой-то вредный совет, а не очистка.
Пользователи потом удивляются, почему у них символы «больше», «меньше» не выводятся
Вообще никогда никакие входные plain/text данные не приходится вот так вот мучать, если они выводятся нормальным способом.
Sign up to leave a comment.
Лучшие практики и рекомендации по защите php-приложений от XSS-атак