TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
XSS , CSRF атаки, SQL-injections и защита от них...
  • Привет, всем!

    Вопрос про защиту:

    Почему-то многие пишут статьи на эту тему, приводят много вариантов защиты от атак и других попыток взлома, но никто не предлагает воспользоваться каким-то универсальным решением (классом) написанным грамотно.

    Даже в Koohana в версии 3.х был исключен clean и в доке сейчас ссылаются на использование Purifier для XXS атак:

    "If you allow users to submit HTML to your application, it is highly recommended to use an HTML cleaning tool such as HTML Purifier or HTML Tidy."


    Господа, или я чего-то не понимаю и не знаю про то, почему нужно писать защиту обязательно самому или я просто не могу найти универсальное решение (потому что не там и не то ищу)?

  • Господа, или я чего-то не понимаю и не знаю про то, почему нужно писать защиту обязательно самому или я просто не могу найти универсальное решение (потому что не там и не то ищу)?


    На сколько я помню, то XSS атаки страшны только когда изменение настроек юзера или посты от его имени реализованы посредством GET запросов. Если вы это исключаете, то вы 100% исключаете возможность XSS атаки на ваш сайт (кроме дос-атак). Что же касается XSS атаки с вашего сайта на сторонний сайт, то обычно просто вырезаются почти все теги HTML, в которых можно спрятать линк на "файл" со стороннего сайта. Делайте так же, а если хотите дать возможность юзерам форматировать текст, то используйте ВВ-коды.
  • Суть этой фразы сводится к тому, что абсолютной защиты не бывает: ломали и apache.org и php.org и причем не на заре их создания. HTML Purifier гарантирует более высокий уровень очистки от html, чем, скажем, strip_tags(), но не гарантирует абсолютной защиты. Последние скандалы с американским АНБ очень хорошо показывают, что достаточно много искусственных уязвимостей, как на уровне GJ, так и на уровне протоколов и даже железа, а что внедрили одни могут найти и другие.
  • Да, я понимаю, что абсолютной защиты не бывает... Я не понимаю, почему написано так много статей об использовании фильтров, токинов и т.п. Но никто не написал класс с этими манипуляциями над данными или в сессии, который можно взять и использовать. И если что-то надо еще, то расширить его новыми методами.
    Почему каждый изобретает свой велосипед?
  • For XSS either use:
    HTML::chars or HTML::entities
    or use Zend/Escaper:
    https://github.com/zendframework/zf2/blob/master/library/Zend/Escaper/Escaper.php
    Zend guys are trying to push it into PHP core, see here:
    https://wiki.php.net/rfc/escaper

    For CSRF, you can use the token:
    http://kohanaframework.org/3.3/guide-api/Security#token

    For SQL-injection, use DB module
  • @alex_han как верно сказал @enov функционал логично распределен по модулям. В большинстве случаев защита уже встроена в кохану: Database\ORM имеют защиту от sql инъекций, Form используют HTML::chars\HTML::entities для экранирования тегов, Route фильтрует значения параметров, Kohana фильтрует данные глобальных переменных и т.д. Также предусмотрена защита от CSRF в Security. Это не гарантирует 100%, но для большинства проектов этого вполне достаточно, разработчики не пытались создать свой велосипед и включили только самое необходимое, все остальное Вы легко можете подключить самостоятельно (например Captcha, Zend/Escaper и т.д.), это обеспечивает гибкость и ресурсоемкость фреймворка, позволяет разработчику использовать привычные для него инструменты.

  • Спасибо за ответы Enov и WinterSilence!

    Просто у меня была в голове "каша" с защитой от всяких атак и т.п. Сейчас все, вроде бы, разложил по полочкам при помощи ваших сообщений и 3х-4х статей на эти темы.

    У меня вопрос еще один по SQL-injection - в одной статье встретил инфу, что ORM защищает только от первого уровня SQL-injection... А что значит второй уровень? Сходу не нашел этой информации.

  • @alex_han это эффект бумеранга :) допустим есть форма добавления комментов к новостям: вписываем туда какой-нибудь злобный js скрипт:

    < script type="text/javascript" >alert('Бу-у-умеранг!');< / script >

    в базу такой код попадает без проблем и вреда никакого не наносит, но вот когда мы выводим комменты из базы, то ср-р-рабатывает Бу-у-умеранг! А чтобы такого не было настраиваем фильтрацию ORM::filters + HTML::chars\HTML::entities и по степени параноидальности валидацию ORM::rules

  • На сколько я помню, то "второй уровень" инъекций означает атаку в несколько этапов, например, когда код для скрипта разбиваться на куски:

    1. <script type="text/javascript"> /* - это идет в первом сообщении и не всегда вырезается, поскольку нет закрытия блока
    2. */ alert('я прорвался сквозь систему безопасности'); </script> - а такое идет со вторым сообщением и тоже может не восприниматся за злостный код

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

  • В том числе и поэтому не стоит рассчитывать на "чистые" данные в БД, так как ORM защищает только от SQL-инъекций, но не от XSS. Экранирование в шаблонах - важная часть защиты от XSS, об этом забывать не стоит.

  • Попробовал HTML Purifier, пока все понравилось. Прикручивается легко, в использовании удобно. Памяти, конечно, отжирает около 4-х метров, но для моей задачи это не критично.

    За основу взят кохановский модуль https://github.com/shadowhand/purifier

    В общем коде выгляди так фильтр в модели:

        public function filters() {
            return array(
                'short' => array(
                    array('trim'),
                    array(array($this, 'purifier'), array(':value', array(
                        'HTML.AllowedElements' => array('i', 'strike', 'u', 'a'),
                        'AutoFormat.RemoveEmpty' => true,
                        'AutoFormat.RemoveEmpty.RemoveNbsp' => true
                    )))
                ),
            );
        }
    

    Метод purifier сделан статическим в расширяемом ORM и выглядит так:

        public static function purifier($value, $config) {
            return Security::htmlpurifier()->purify($value, $config);
        }
    

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion