Присоединяйтесь к нашему инвестиционному форуму, на котором уже 490,881 пользователей. Чтобы получить доступ ко многим закрытым разделам и начать общение - зарегистрируйтесь прямо сейчас.
Все, что относится к Web-Программированию (PHP, Perl, JavaScript, MySQL, XML и т.д.)
Ответить
Старый 11.07.2019, 16:51
#1
 
Регистрация: 22.09.2018
Сообщений: 9
Благодарностей: 0
КП: 0.000
Универсальная защита от xss-атак и sql-инъекций

Я не занимаюсь технической поддержкой сайтов, но так уж сложилось, что ко мне часто обращаются за помощью. С одной стороны отказывать неудобно, да и не выгодно с коммерческой точки зрения, с другой за большое спасибо в магазине тоже не расплатишься. Поэтому я решил написать универсальное решение, но столкнулся с некоторыми проблемами.
Суть решения заключается в том, чтобы отловить данные POST, GET, COOKIE и обработать их еще до того, как сайт произведет с ними какие-либо действия.
Вот собственно сам код

$jsxss="onabort,oncanplay,oncanplaythrough,ondurat ionchange,onemptied,onended,onerror,onloadeddata,o nloadedmetadata,onloadstart,onpause,onplay,onplayi ng,onprogress,onratechange,onseeked,onseeking,onst alled,onsuspend,ontimeupdate,onvolumechange,onwait ing,oncopy,oncut,onpaste,ondrag,ondragend,ondragen ter,ondragleave,ondragover,ondragstart,ondrop,onbl ur,onfocus,onfocusin,onfocusout,onchange,oninput,o ninvalid,onreset,onsearch,onselect,onsubmit,onabor t,onbeforeunload,onerror,onhashchange,onload,onpag eshow,onpagehide,onresize,onscroll,onunload,onkeyd own,onkeypress,onkeyup,altKey,ctrlKey,shiftKey,met aKey,key,keyCode,which,charCode,location,onclick,o ndblclick,oncontextmenu,onmouseover,onmouseenter,o nmouseout,onmouseleave,onmouseup,onmousemove,onwhe el,altKey,ctrlKey,shiftKey,metaKey,button,buttons, which,clientX,clientY,detail,relatedTarget,screenX ,screenY,deltaX,deltaY,deltaZ,deltaMode,animations tart,animationend,animationiteration,animationName ,elapsedTime,propertyName,elapsedTime,transitionen d,onerror,onmessage,onopen,ononline,onoffline,onst orage,onshow,ontoggle,onpopstate,ontouchstart,onto uchmove,ontouchend,ontouchcancel,persisted,javascr ipt";
$jsxss = explode(",",$jsxss);
foreach($_POST as $k=>$v)
{
if(is_array($v))
{
foreach($v as $Kk=>$Vv)
{
$Vv = preg_replace ( "'<script[^>]*?>.*?</script>'si", "", $Vv );
$Vv = str_replace($jsxss,"",$Vv);
$Vv = str_replace (array("*","\\"), "", $Vv );
$Vv = strip_tags($Vv);
$Vv = htmlentities($Vv, ENT_QUOTES, "UTF-8");
$Vv = htmlspecialchars($Vv, ENT_QUOTES);
$_POST[$k][$Kk] = $Vv;
}
}
ELSE
{
//Сначала удаляем любые скрипты для защиты от xss-атак
$v = preg_replace ( "'<script[^>]*?>.*?</script>'si", "", $v );
//Вырезаем все известные javascript события для защиты от xss-атак
$v = str_replace($jsxss,"",$v);
//Удаляем экранированание для защиты от SQL-иньекций
$v = str_replace (array("*","\\"), "", $v );
//Экранируем специальные символы в строках для использования в выражениях SQL
$v = mysql_real_escape_string( $v );
//Удаляем другие лишние теги.
$v = strip_tags($v);
//Преобразуеv все возможные символы в соответствующие HTML-сущности
$v = htmlentities($v, ENT_QUOTES, "UTF-8");
$v = htmlspecialchars($v, ENT_QUOTES);
//Перезаписываем GET массив
$_POST[$k] = $v;
}

}
Тоже самое я сделал по аналогии с _GET и _COOKIE
Основные недостатки.

1) У меня так и не вышло обработать, а точнее перезаписать их внутри функции и передать _POST, _GET и _COOKIE в качестве переменных, а главное, как следствие, обработать многомерные массивы данных рекурсивно. Соответственно $_POST[][], $_POST[][][] и тд уже обработать не выйдет и каждый такой массив надо вставлять отдельно. Массив может быть бесконечно большой, а код получится бесконечно громозкий.

2) Не охота убирать функцию mysql_real_escape_string ведь никогда не знаешь, где ее забыли упомянуть, но возникает проблема излишнего экранирования символов.

3) strip_tags удаляет все теги. Мне бы не хотелось убирать все, а лишь самые опасные теги, но беда в том, что в дополнительных параметрах можно указать только теги, которые нужно оставить. Конечно, можно использовать регулярные выражения, но к сожалению, нет уверенности в том, что не забудешь что-нибудь важное, поэтому если у кого-то есть отличная замена этому, то предлагаю собрать все в кучу и избавиться от strip_tags

4) Ну и жду других советов по данному вопросу.
superpupervest вне форума
Старый 14.08.2019, 18:22
#2
Интересующийся
 
Пол: Мужской
Инвестирую в: Другое
Регистрация: 10.08.2019
Сообщений: 10
Благодарностей: 0
КП: 0.000
Re: Универсальная защита от xss-атак и sql-инъекций

Моё имхо в данном вопросе:

1. Обрабатывать всё на уровне $_POST/$_GET - совсем не выход, так как всегда бывают исключения. Безопасность продукта должна закладываться в момент написания кода. Жаль что так не всегда делают.
2. Об исключениях - с тем же хтмл, почему бы не разрешить пользователям безвредные теги форматирования. Но при этом нужно на выходе всегда вырезать лишние теги из текстов, вводимых пользователями. Дополнительно можно валидировать на входе.
3. Защита от SQL-инъекций должна делаться там, где данные вставляются в базу. Не все что приходит в посте сразу идет туда. Поэтому и говорю что безопасность должны делать те кто делал сайт.
4. Фреймворки и разные профессиональные обертки - наше все. Хорошая обертка для работы с базой (не обязательно ORM, любая библиотека вида "query builder") сама очищает все входящие параметры. Но опять-таки, если её не использовали изначально...

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

UPD: Давно не писал на php, последнее время на node и все как-то SPA. В случае с нодой просто использовать knex (обертка для работы с бд), не вставлять пользовательского ввода напрямую в knex.raw - и с sql все будет хорошо. Для очистки HTML - на фронте фреймворк по умолчанию экранирует хтмл, где нужно не экранировать - используется библиотека sanitize-html с кастомными настройками (разрешены только теги форматирования). Есть другие проблемы безопасности в современном мире - например некоторые гении не проверяют на бэкэнде что пользователь запрашивает свой ресурс, а не чужой. И вторая - вредоносный код в сторонних библиотеках, которым аудит обычно никто не проводит (так как некогда, их и используют ради экономии времени)

UPD2:

Цитата:
Сообщение от superpupervest Посмотреть сообщение
strip_tags удаляет все теги. Мне бы не хотелось убирать все, а лишь самые опасные теги, но беда в том, что в дополнительных параметрах можно указать только теги, которые нужно оставить. Конечно, можно использовать регулярные выражения, но к сожалению, нет уверенности в том, что не забудешь что-нибудь важное, поэтому если у кого-то есть отличная замена этому, то предлагаю собрать все в кучу и избавиться от strip_tags
Для пхп нашел http://htmlpurifier.org/, должно помочь
__________________
tradary.com - умный дневник трейдера

Последний раз редактировалось Tradary; 14.08.2019 в 18:38.
Tradary вне форума
Ответить
Войдите, чтобы оставить комментарий.
Опции темы

Быстрый переход
Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Защита вашего проекта от DDoS атак! Rybak85 Сайт & Серверное администрирование 16 05.11.2014 11:58
Защита серверов от ddos атак lineage2, wow, rf, mu online MacHoster Прочее 3 19.07.2012 12:02
DDOS защита от атак любого уровня. kostich Web Хостинг 16 30.04.2010 19:45
Защита от DDoS атак, выделенные сервера в Швейцарии GDCSupport Web Хостинг 0 21.02.2009 18:43