PHP 4.2.0, 4.2.1 проблемы безопасности

бла бла бла, опять траблы с php :(
на 4.1.2 эта проблема никак не отражается ?

Там свои проблемы... Так что -- стоит обновится до 4.2.2

С 4.1.2 вроде все пучком..., там проблемы были с версиями ниже чем 4.1.2

А это собственно и не новость. PHP-и в описаниях своих конфигов пишут что будут прибивать ветки разбора $HTTP_POST и $HTTP_GET ибо они да ужаса дырявые. Взамен ставят $_GET и $_POST ну или УНИ: $_REQUEST. (Я наружные переменные уже давно через реквесты в скрипты ввожу и обратно).

OpenStorm покажи плиз хоть одно сообщение где утверждается, что ветки разбора $HTTP_POST и $HTTP_GET будут прибивать?

; Global variables are no longer registered for input data (POST, GET, cookies, ; environment and other server variables). Instead of using $foo, you must use ; you can use $_REQUEST["foo"] (includes any variable that arrives through the ; request, namely, POST, GET and cookie variables), or use one of the specific ; $_GET["foo"], $_POST["foo"], $_COOKIE["foo"] or $_FILES["foo"], depending ; on where the input originates. Also, you can look at the ; import_request_variables() function. ; Note that register_globals is going to be depracated (i.e., turned off by ; default) in the next version of PHP, because it often leads to security bugs. ; Read http://php.net/manual/en/security.registerglobals.php for further ; information.

Я конечно извиняюсь - погорячился насчет прибивать (это же не микрософт :))). Но то что "Глобальные переменные" дыра - факт. и $HTTP_POST_VARS ... и все остальное к ним помоему также относится. А с переменными прийдется работать через API-функции.

Практический пример: переносим портал в VHOST какого-нибудь сервера с апаче с настроеным секьюрити. (То есть дырки заклеяны). И просим админа включить global_variables. В результате нас посылают подальше, ибо из-за нашего PHP-кода никто дырявить сервак не будет. Я к примеру нет. И что нам делать нужно будет тогда? перелапачивать весь PHP-код под сервер. А не просто ли стараться писать под default options насколько это возможно? WEB-разработчиков туча и если каждому конфиг фиксить, замотаешься потом "зверей" отстреливать. На сайтах МВД тоже пооткрывали подобные дырки. И чего?! Стоял файрвол и все дела. И камня на камне не оставили.

P.S.: Умные учатся на чужих ошибках, те кто не очень - на своих... Просто пословица ( не хотел никого обидеть ).

Проблема в том, что большинство скриптов написанных до настоящего момента , никто не собирается пока переписывать... =( Так что иногда тактика M$ -- "удави и нет проблем" работает как нельзя лучше...

А какие еще проблемы с глобальными переменными, кроме тех, что описаны в http://php.net/manual/en/security.registerglobals.php ??? А те, что там описаны - так это проблемы головы, тех кто такие скрипты пишет. А от первой проблемы так и $_REQUEST не спасает... Нафиг тогда вообще эту байду городить?

Согласен с предыдущим оратором - хотя использование глобальных переменных и провоцирует возможные ляпы, это не основание их выносить (иначе можно сказать, что язык С виноват в дырах типа vsnprintf ;) - в своё время простота попадания параметров из GET/POST помогла PHP приобрести сторонников.
Это же просто - писать так, чтобы использовать только ожидаемые переменные. Если же челеовек не способен отследить, что он пишет - то он с выключенными глоб. переменными делов наделает.
Мы у себя спорили - так к единому мнению и не пришли.
А вообще, здорово напрягает что как в perl нельзя my сказать.

Как говорится, на вкус и цвет мануала нет. Практический пример: попробуйте в качестве action указать пост-инструкцию "somepage.php?someproperty=somevalue&...etc" и в самой странице somepage.php потом через $HTTP_POST_VARS и $HTTP_GET_VARS подоставать/поустанавливать переменные POST - от action так и POST от формы. Геморой с пропаданием значений переменных - гарантирую. Когда сие происходит, точно до сих пор не выловил. Как нашел эту дыру, прочитал рекомендации PHP секьюрити/перфоманс и стал использовать $_GET, $_POST и $_REQUEST и забыл про эту проблему. Я настаиваю чтоли отказаться от $HTTP_POST/GET? Да используйте их сколько угодно, мне если честно фиолетово. Я просто сказал что знаю эту дыру и поделился как она латается (или не открывается в PHP)и обходится в PHP-коде, а "байду городить" никто не собирался. Я только и хотел сказать что достаю значения POST-ируемых переменных через "$_REQUEST" без открытия глобальных переменных в конфиге. (можешь прочитать последнее еще раз если не дошло с первого раза.)

OpenStorm - дак я против тебя ничего не имею... Можешь у себя все поменять - дак и хорошо. А вот если проект на 1000 файлов - то тут проще удавиться, чем все глобальные переменные на $_REQUEST поменять.

Похоже еще один гвоздь в гроб PHP. По крайней мере уже запросто начальника переубедить переходить на Java технологию из-за этих проблем в PHP.

Куда переходить да гвозди загонять???

Example 1. Java Example

<?php // get instance of Java class java.lang.System in PHP $system = new Java("java.lang.System");

// demonstrate property access print "Java version=".$system->getProperty("java.version")." <br>"; print "Java vendor=" .$system->getProperty("java.vendor")." <br>"; print "OS=".$system->getProperty("os.name")." ". $system->getProperty("os.version")." on ". $system->getProperty("os.arch")." <br>";

// java.util.Date example $formatter = new Java("java.text.SimpleDateFormat", "EEEE, MMMM dd, yyyy 'at' h:mm:ss a zzzz");

print $formatter->format(new Java("java.util.Date")); ?> Example 2. AWT Example

<?php // This example is only intented to be run as a CGI.

$frame = new Java("java.awt.Frame", "Zend"); $button = new Java("java.awt.Button", "Hello Java world!");

$frame->add("North", $button); $frame->validate(); $frame->pack(); $frame->visible = True;

$thread = new Java("java.lang.Thread"); $thread->sleep(10000);

$frame->dispose(); ?>

:)))

Про JAVA - ну-ну - переходите, переходите...
Прежде чем говорить, ознакомьтесь сначала с BUGTRAQ что ли для начала...;-)

а про $_REQUEST и "1000 файлов" - что, команды find или sed отменили?8)