Register_globals=on? Вы в опасности!

[Creator]

Моя 2-я статья: register_globals=oN? Вы в опасности!

 

[DnAp]

Но давайте вдумаемся, зачем нам «загрязнять» массив $GLOBALS? Для этого у нас есть специальные массивы, хранящие данные, переданные методами GET (массив $_GET) и POST (массив $_POST).

А как-же вечная фраза "так легче", ну согласитесь что нам совсем не жалко 10 переменных на компе у которого 2 гиги оперативки(приблизительно столько на современных серверах)...
А доступ к массиву $GLOBALS осуществляеться напрямую... не надо писать никаких $_GET['..'] или $_POST['..'] написали $.. и все
А чтоб забыть о безопасности достаточно написать

error_reporting(E_ALL);

После этого у вас код:

<?
error_reporting(E_ALL);
if($_POST['login']=='login'&&$_POST['pass']=='pass')
{
	$valid_user=TRUE; // Юзер корректный
}

if($valid_user)
{
   echo 'Здравствуйте, пользователь';
}
else echo 'В доступе отказано'
?>

выведет не

В доступе отказано

а

Notice: Undefined index: login in PHPDocument1 on line 3

Notice: Undefined variable: valid_user in PHPDocument1 on line 8

В доступе отказано

Из этих строчек явно видно что переменная valid_user может содержать все что угодно...
Кстати тут же еще есть но если пользователь попал на эту страницу не нажаием кнопки то не зачем ему писать что отказано в доступе...

сделав в начале файла маленькую запись $valid_user=NULL; мы избавляемся от этого...
Кстати error_reporting(E_ALL); можно сделать и через файл .htaccess

 

[Creator]

А как-же вечная фраза "так легче"

Ну у меня рулит фраза "так логичнее".

ну согласитесь что нам совсем не жалко 10 переменных на компе у которого 2 гиги оперативки(приблизительно столько на современных серверах)...

Это заведомо гиблый стиль, для того люди ищут наиболее выгодные решения в плане производительности, тем более, это все не страшно, если у тебя посещаемость небольшая, но потом могут возникнуть серьезные проблемы.

error_reporting(E_ALL);

Да, ты этим сообщаешь интерпретатору PHP выводить все ошибки и примечания.

Из этих строчек явно видно что переменная valid_user может содержать все что угодно...Кстати тут же еще есть но если пользователь попал на эту страницу не нажаием кнопки то не зачем ему писать что отказано в доступе...

Ну это уже придирка, я же написал самый простой вариант, который наглядно раскрывает суть проблемы, а не рабочую идентификацию

сделав в начале файла маленькую запись $valid_user=NULL; мы избавляемся от этого...

Да все верно, но логичнее:

<?if($_POST['login']=='login'&&$_POST['pass']=='pass')
{	
	$valid_user=TRUE; // Юзер корректный
}
else $valid_user=FALSE;

if($valid_user)
{   
 echo 'Здравствуйте, пользователь';
}
else echo 'В доступе отказано';
?>

Т.е. по факту, если верный то получи "пряник", если неверный то получи "кнут"

 

[DnAp]

Логичнее - это так как написал ты... я седня после получасогого разбора чужих регулярных выражений находился в небольшем ступоре... И я уверен что его код был бы логичней с его точки зрения..
Дело не в этом...
Я не вижу не достаточно доводов для отказа от error_reporting(E_ALL);
И почему после этого я остаюсь в опасности?
Именно это я и хотел отметить в статье, тема раскрыта односторонне!!..
И не учитывает альтернативные способы решения проблеммы!!!

 

[Creator]

Я не вижу не достаточно доводов для отказа от error_reporting(E_ALL);

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

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

Именно это я и хотел отметить в статье, тема раскрыта односторонне!!..
И не учитывает альтернативные способы решения проблеммы!!!

Хм, ну ладно, у тебя свое мнение у меня свое, давай подождем, как кто-нибудь выскажется по этому поводу.

Как вы считаете, раскрыта ли суть проблемы в статье или нет и ее надо доработать?

 

[Renard]

ИМХО статья достаточно раскрывает тему, хотя бы для того чтобы человек задумался над вопросом безопасности своих скриптов.
И неважно, включен этот режим, или выключен, не о том разговор в общем то... Просто всегда нужно относить с недоверием ко всему что поступает от пользователя. Приводить к нужному типу переменные, экранировать кавычки, резать строку по необходимой длине. Дальше все зависит от прямоты рук программиста.
А переменные при выключенном register_globals достаются оч просто

extract($_GET, EXTR_SKIP);
extract($_POST, EXTR_OVERWRITE);

 

[v0rbis]

тема раскрыта

 

[Creator]

Напоминаю, основной сутью статьи является не программирование с включенным global_register или поиска альтернативных решений. Её истинная цель – убедить вас избавиться от global_register пока не поздно.
Т.е. если после прочтения статьи вы отключили global_register => значит она свою миссию выполнила.
А теперь поднимите руки, кто отключил global_register.

 

[mrM]

2Creator: БОЛЬШОЙ ТЕБЕ РЕСПЕКТ!!!
Я прочитал твою статью! После прочтения начал проверять свой скрипт и нашел дырку как раз при включенном register_globals, отключил и все тип топ. Вообще, очень рад что ты нас радуешь такими классными статьями. Лично я буду ждать новых.
Еще раз молодец!

 

[LeopART]

Я недавно как раз на globals попалась... Кре, респект! Шоб я еще его в режиме on? Да никогда в жизни! если уж заботиться о безопасности - то по полной программе. А статья эта меня навела на путь истинный )

 

[v0rbis]

а у нас на работе ВКЛ... тока ненада нас ломать. )

 

[Creator]

v0rbis, докажи, что ты понял статью))

 

[The J4s]

познавательно очень, респ