Новости из Блогов Когда integer не защитит от SQL injection?

Discussion in 'Мировые новости. Обсуждения.' started by VY_CMa, 29 May 2013.

  1. VY_CMa

    VY_CMa Green member

    Joined:
    6 Jan 2012
    Messages:
    917
    Likes Received:
    492
    Reputations:
    724
    Считается, данные числового типа полностью защищают от атаки типа SQL инъекции.

    Давайте рассмотрим простой пример:

    PHP:
    $action $_GET['do'];
    $r=$db->query("select role".((int)$action)." from users where id=".((int)$_SESSION['user_id']));
    if(
    $row=$r->fetchArray()){
            if((int)
    $row[0]!==1){
                    die(
    'permission denied');
            }else{
                    
    doAction($action);
            }
    }
    Приведенный код выглядит вполне безопасным, но это не так.

    Не стоит забывать о двух важных вещах:
    • Существуеи SQL оператор минус.
    • Число может быть отрицательным.

    Теперь рассмотрим логику SQL в данном случае (без инъекций):

    PHP:
    select role0 from users where id=0
    И атаку типа SQL Injection:

    PHP:
    select role-1 from users where id=0
    Таким образом злоумышленник может обойти авторизацию.
    В этих примерах требуется наличие таблиц role и role0 в базе данных.

    Автор: Vladimir // перевод VY_CMa
    Дата: 13 мая 2013 г.
    http://lab.onsec.ru/2013/05/when-integer-cannot-protect-you-from.html​
     
    _________________________
    #1 VY_CMa, 29 May 2013
    Last edited: 30 May 2013
  2. Gar|k

    Gar|k Moderator

    Joined:
    20 Mar 2009
    Messages:
    1,166
    Likes Received:
    266
    Reputations:
    82
    $action=(int)preg_replace("/\D/",'',$_GET['do']);
     
    _________________________
  3. попугай

    попугай Elder - Старейшина

    Joined:
    15 Jan 2008
    Messages:
    1,520
    Likes Received:
    401
    Reputations:
    196
    Слишком натянуто как-то. Если action передается через переменную, то подразумевается, что это так заложено в логике приложения, чтоб шло обращение к колонкам role[0-65536]. Это не инъекция, а сознательный допуск девелопера ко всем колонкам из этого диапазона role[0-65536].

    Внедрения хакером своих операторов не происходит, все в точности в тех пределах, задуманных создателем этого приложения.
     
    #3 попугай, 30 May 2013
    Last edited: 30 May 2013
  4. Eich3

    Eich3 Member

    Joined:
    27 Jan 2013
    Messages:
    22
    Likes Received:
    7
    Reputations:
    5
    Пример явно синтетический. В нормальных движках и фреймворках информация о привилегиях подгружается в сессию на стадии авторизации, а ID действия вообще недоступен для изменения пользователем, т.к. задается функцией, выполняющей запрос.

    Далее, зачем заводить отдельную колонку под каждый тип действия? Если это, например, права на редактирование текста статьи, то у многих там будут стоять нули - а это бессмысленный расход дискового пространства. Лучше сделать Many-To-Many связь. И тогда эта проблема отпадет - action_id будет передаваться в предложении WHERE.

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