Luge 1. Пример не правильный, т.к. ты перекрыл любое значение, полученное из register_globals прямым присваиванием. 2. Пример тоже легко решается проверкой инклудится этот файл, или вызывается. Я хочу, что бы вы привели пример случая, когда программист НЕ МОЖЕТ избежать влияния register_globals на код, вызывая этим проблему безопасности.
PHP: <?php if(!isset($_GET['md']) && passwordOk()) { $module = $_GET['md']; } if(isset($module) && ($module)) { $includefile = $module . $admin . PHP_EXT; } include $includefile; ))
Следующий пример не притянут за уши, а взят из реальной CMS, написаной для сайтов четырех маленьких ООО: PHP: <?php if (isset($login)) // login - имя кнопки submit формы { /* сверка данных формы с данными из БД */ $admin = array(..); // сюда данные залогинившегося админа $login_ok = 1; } // Далее везде, где проверяся на авторизированность if ($login_ok) { .... С помощью register_globals можно не только "авторизироваться", но и использовать произвольные данные "администратора".
мне кажется что флоппик намекает на то что регистр глобалс не является источником ошибок и если хорошо подумать то всегда можно защитится от его влияния - то есть это вопрос проектирования. А вот почему его сделали офф по дефолту, а не убрали совсем: он усложняет разработку так как нужно следить за пересекающимися переменными глобальными и внешними, и второе - ввиду большой распространенности языка - шанс что разработка ведется ответственным профессионалом стремится к 0, а наличие уязвимостей в конечном коде из-за включенного регистр_Глобалс понижает доверие к языку у заказчиков ...
nimistar в виду популярности использования php теми, кто пока или и потом думать не будет и отключили эту штуку, просто они не знают, что просто инициализировав каждую переменную перед использованием все уязвимости с регистрглобалс уходят в никуда
Все равно, что привести пример, когда программист не может избежать инъекции. Естественно, такого примера нет. Тоесть =вредна ли защита от дурака?
флоппик а вот тут ты брось. и смешение пространств имён — это уже не проблема? Ещё какая, причём проблема человеко-часов, убитых на поиск такого перекрытия. а давайте без давайте… так можно любой код, иллюстрирующий возможные проблемы с безопасностью/логикой парой изменений превратить в безопасный. Пример не всегда должен быть реален. Вот один из примеров с php.net: PHP: <?php // define $authorized = true only if user is authenticated if (authenticated_user()) { $authorized = true; } // Because we didn't first initialize $authorized as false, this might be // defined through register_globals, like from GET auth.php?authorized=1 // So, anyone can be seen as authenticated! if ($authorized) { include "/highly/sensitive/data.php"; } ?> тут тоже можно определить заранее $authorized; или даже в if проверить, что $authorized булево, а не NULL, если не определено, или string, если пришло из гет/пост/кук. Но тогда наглядный пример лишится своей наглядности. Когда мелкий лез в огонь, я тоже ему показал как сгорел лист бумаги, а не сувал свою руку, чтоб показать как она обуглится. вот это понравилось для обратной совместимости старых скриптов. В шестом убрали
Ммм, а вопрос то не про безопасность, а про вредность =) Конечно вреден. Потому что одноименные переменные, переданые разными методами перекрывают друг друга. Какое значение окажется конечным, зависит от настройки variables_order.
Я уже хотел подвести итоги, но раз все так уцепились за РГ, то о них и поговорим сейчас На самом деле, там есть пара случаев, когда учесть влияние РГ практически невозможно. Даю намек - это связанно с массивами. Ну, может кто нить напряжется, и выдаст случай, когда это так? )
ты про подмену типов массив <--> строка? что-то типа PHP: <?php $info['user'] = 'Luge'; $info['pass'] = 'HD498734$8dflkj_S(23'; $u = isset($_GET['u'])?trim($_GET['u']):''; $p = isset($_GET['p'])?trim($_GET['p']):''; if($info['user'] == $u && $info['pass'] == $p) { echo 'опаньки'; } ?> http://example.com/file.php?info=ab&u=H&p=H
в данном случае из-за ?info=ab $info определён как строка. И все следующие действия происходят уже со строкой
хотя, $info = array(); сводит всю красоту на ноль и опять возвращаемся к разговору о наглядности примера и возможных способах исправления
Да. Один из примеров. Правда, на него влияет порядок разбора, и обычно оно не сработает, но иногда в зависимости от variables_order который из скрипта изменить нельзя, гарантирует, что ты сможешь его перекрыть всегда. т.е. это первый пример, когда независимо как написан скрипт, от настроек ты не защитишься.
От идиотов вообще защититься сложно, особо когда они могут на что-то повлиять. Но все же не нужно в угоду "страшилкам" придумывать случаи, что кто-то поменял variables_order (тем более, что оно не меняется из скрипта)
MiksIr Зато долбонутых на голову админов на хостингах хватает. Вместо того, что бы обрезать доступ к shell командам, они её вообще отрубают через safe mod, попутно отключая ещё кучу всего. И ещё докажи им что ты не идиот, особенно когда там сидит студент с опытом работы в год, а у тебя за плечами 5-7 лет опыта работы с PHP далеко не с CMS-ками, да и опыта администрирования поболее чем у него. Так что бывает что и variables_order меняют. А вообще к 6-ке много чего убрали паразитивного, и register_globals, и magic_quotes, и safe mode (а сколько хостеров получат по шапке в силу своей некомпетентности когда safe mode просто не будет существовать )
Суть темы то была не в защите от идиотов. Я хотел посмотреть как "молодежь" попытается применить мышление к фактам, на которые нет очевидного ответа. Выяснилось, что они банально тему умело игнорировали, что значит - думать никому не надо. А что Luge, ты и нимистар думать умеют я и так знал. )))) Порадовал Volt(220) который дал на самом деле правильный ответ )