Универсальная защита от xss-атак и sql-инъекций

Тема в разделе "PHP", создана пользователем superpupervest, 11 июл 2019.

  1. superpupervest

    superpupervest

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

    Код:
    $jsxss="onabort,oncanplay,oncanplaythrough,ondurationchange,onemptied,onended,onerror,onloadeddata,onloadedmetadata,onloadstart,onpause,onplay,onplaying,onprogress,onratechange,onseeked,onseeking,onstalled,onsuspend,ontimeupdate,onvolumechange,onwaiting,oncopy,oncut,onpaste,ondrag,ondragend,ondragenter,ondragleave,ondragover,ondragstart,ondrop,onblur,onfocus,onfocusin,onfocusout,onchange,oninput,oninvalid,onreset,onsearch,onselect,onsubmit,onabort,onbeforeunload,onerror,onhashchange,onload,onpageshow,onpagehide,onresize,onscroll,onunload,onkeydown,onkeypress,onkeyup,altKey,ctrlKey,shiftKey,metaKey,key,keyCode,which,charCode,location,onclick,ondblclick,oncontextmenu,onmouseover,onmouseenter,onmouseout,onmouseleave,onmouseup,onmousemove,onwheel,altKey,ctrlKey,shiftKey,metaKey,button,buttons,which,clientX,clientY,detail,relatedTarget,screenX,screenY,deltaX,deltaY,deltaZ,deltaMode,animationstart,animationend,animationiteration,animationName,elapsedTime,propertyName,elapsedTime,transitionend,onerror,onmessage,onopen,ononline,onoffline,onstorage,onshow,ontoggle,onpopstate,ontouchstart,ontouchmove,ontouchend,ontouchcancel,persisted,javascript";
    $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) Ну и жду других советов по данному вопросу.