Сегoдня мы рассмотрим эксплуатацию критической 1day-уязвимости в популярной CMS Joomla, которая прогремела на просторах интернета в конце октября. Речь пойдет об уязвимостях с номерами CVE-2016-8869 , CVE-2016-8870 и CVE-2016-9081 . Все три происходят из одного кусочка кода, который пять долгих лет томился в недрах фреймворка в ожидании своего часа, чтобы затем вырваться на свободу и принести с собой хаос, взломанные сайты и слезы ни в чем не повинных пользователей этой Joomla. Лишь самые доблестные и смелые разработчики, чьи глаза красны от света мониторов, а клавиатуры завалены хлебными крошками, смогли бросить вызов разбушевавшейся нечисти и возложить ее голову на алтарь фиксов.

WARNING

С чего все началось

6 октября 2016 года Дэмис Пальма (Demis Palma) создал топик на Stack Exchange , в котором поинтересовался: а почему, собственно, в Joomla версии 3.6 существуют два метода регистрации пользователей с одинаковым названием register() ? Первый находится в контроллере UsersControllerRegistration , а второй - в UsersControllerUser . Дэмис хотел узнать, используется ли где-то метод UsersControllerUser::register() , или это лишь эволюционный анахронизм, оставшийся от старой логики. Его беспокоил тот факт, что, даже если этот метод не используется никаким представлением, он может быть вызван при помощи сформированного запроса. На что получил ответ от девелопера под ником itoctopus, подтвердившего: проблема действительно существует. И направил отчет разработчикам Joomla.

Далее события развивались самым стремительным образом. 18 октября разработчики Joomla принимают репорт Дэмиса, который к тому времени набросал PoC, позволяющий регистрировать пользователя. Он опубликовал заметку на своем сайте , где в общих чертах рассказал о найденной проблеме и мыслях по этому поводу. В этот же день выходит новая версия Joomla 3.6.3, которая все еще содержит уязвимый код.

После этого Давиде Тампеллини (Davide Tampellini) раскручивает баг до состояния регистрации не простого пользователя, а администратора. И уже 21 октября команде безопасности Joomla прилетает новый кейс. В нем речь уже идет о повышении привилегий . В этот же день на сайте Joomla появляется анонс о том, что во вторник, 25 октября, будет выпущена очередная версия с порядковым номером 3.6.3, которая исправляет критическую уязвимость в ядре системы.

25 октября Joomla Security Strike Team находит последнюю проблему, которую создает обнаруженный Дэмисом кусок кода. Затем в главную ветку официального репозитория Joomla пушится коммит от 21 октября с неприметным названием Prepare 3.6.4 Stable Release , который фиксит злосчастный баг.

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

27 октября исследователь Гарри Робертс (Harry Roberts) выкладывает в репозиторий Xiphos Research готовый эксплоит , который может загружать PHP-файл на сервер с уязвимой CMS.

Детали

Что ж, с предысторией покончено, переходим к самому интересному - разбору уязвимости. В качестве подопытной версии я установил Joomla 3.6.3, поэтому все номера строк будут актуальны именно для этой версии. А все пути до файлов, которые ты увидишь далее, будут указываться относительно корня установленной CMS.

Благодаря находке Дэмиса Пальмы мы знаем, что есть два метода, которые выполняют регистрацию пользователя в системе. Первый используется CMS и находится в файле /components/com_users/controllers/registration.php:108 . Второй (тот, что нам и нужно будет вызвать), обитает в /components/com_users/controllers/user.php:293 . Посмотрим на него поближе.

286: /** 287: * Method to register a user. 288: * 289: * @return boolean 290: * 291: * @since 1.6 292: */ 293: public function register() 294: { 295: JSession::checkToken("post") or jexit(JText::_("JINVALID_TOKEN")); ... 300: // Get the form data. 301: $data = $this->input->post->get("user", array(), "array"); ... 315: $return = $model->validate($form, $data); 316: 317: // Check for errors. 318: if ($return === false) 319: { ... 345: // Finish the registration. 346: $return = $model->register($data);

Здесь я оставил только интересные строки. Полную версию уязвимого метода можно посмотреть в репозитории Joomla.

Разберемся, что происходит при обычной регистрации пользователя: какие данные отправляются и как они обрабатываются. Если регистрация пользователей включена в настройках, то форму можно найти по адресу http://joomla.local/index.php/component/users/?view=registration .

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

За работу с пользователями отвечает компонент com_users . Обрати внимание на параметр task в запросе. Он имеет формат $controller.$method . Посмотрим на структуру файлов.

Имена скриптов в папке controllers соответствуют названиям вызываемых контроллеров. Так как в нашем запросе сейчас $controller = "registration" , то вызовется файл registration.php и его метод register() .

Внимание, вопрос: как передать обработку регистрации в уязвимое место в коде? Ты наверняка уже догадался. Имена уязвимого и настоящего методов совпадают (register), поэтому нам достаточно поменять название вызываемого контроллера. А где у нас находится уязвимый контроллер? Правильно, в файле user.php . Получается $controller = "user" . Собираем все вместе и получаем task = user.register . Теперь запрос на регистрацию обрабатывается нужным нам методом.

Второе, что нам нужно сделать, - это отправить данные в правильном формате. Тут все просто. Легитимный register() ждет от нас массив под названием jform , в котором мы передаем данные для регистрации - имя, логин, пароль, почту (см. скриншот с запросом).

• /components/com_users/controllers/registration.php: 124: // Get the user data. 125: $requestData = $this->input->post->get("jform", array(), "array");

Наш подопечный получает эти данные из массива с именем user .

• /components/com_users/controllers/user.php: 301: // Get the form data. 302: $data = $this->input->post->get("user", array(), "array");

Поэтому меняем в запросе имена всех параметров с jfrom на user .

Третий наш шаг - это нахождение валидного токена CSRF, так как без него никакой регистрации не будет.

• /components/com_users/controllers/user.php: 296: JSession::checkToken("post") or jexit(JText::_("JINVALID_TOKEN"));

Он выглядит как хеш MD5, а взять его можно, например, из формы авторизации на сайте /index.php/component/users/?view=login .

Теперь можно создавать пользователей через нужный метод. Если все получилось, то поздравляю - ты только что проэксплуатировал уязвимость CVE-2016-8870 «отсутствующая проверка разрешений на регистрацию новых пользователей».

Вот как она выглядит в «рабочем» методе register() из контроллера UsersControllerRegistration:

• /components/com_users/controllers/registration.php: 113: // If registration is disabled - Redirect to login page. 114: if (JComponentHelper::getParams("com_users")->get("allowUserRegistration") == 0) 115: { 116: $this->setRedirect(JRoute::_("index.php?option=com_users&view=login", false)); 117: 118: return false; 119: }

А так в уязвимом:

• /components/com_users/controllers/user.php:

Ага, никак.

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

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!

На прошлом уроке мы разобрались из каких блоков будет состоять шаблон trip , поэтому можно приступать к работе. Для начала создадим две папки:

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

ВНИМАНИЕ: В папке images шаблона не размещается графика контента!

css - эта папка будет содержать в себе файлы каскадных таблиц стилей . Для начала поместим в нее пустой файл template.css, с помощью которого будет осуществляется назначение различных стилей оформления элементам сайта.

Далее можно приступать к созданию самого главного файла index.php , который будет определять визуальное расположение элементов сайта и сообщать CMS Joomla в какой блок поместить различные компоненты и модули. Файл является комбинацией PHP и HTML.

Я всегда при написании кода использую только Macromedia Dreamweaver . Отличная программа, настоятельно советую ее новичкам, т.к. если в процессе работы над кодом вы сделали ошибку, программа обязательно подсветит ваш косяк.

На сайте вы найдете самоучитель по Macromedia Dreamweaver . Если вы собираетесь заниматься разработкой сайтов, то программку эту стоит освоить, хотя бы на начальном уровне, чтобы редактировать коды шаблонов без ошибок.

Позиционирование элементов (блоков) страницы производится при помощи кода HTML, конкретно мы будем использовать теги DIV. Но так, как сайт наш будет работать на движке Joomla, т.е. он будет динамическим, то придется использовать еще и язык PHP. С его помощью мы определим в каких блоках будут находится позиции для вывода модулей, и как эти позиции будут называться, будут ли сворачиваться блоки или нет. Подключим таблицы стилей из внешних файлов, язык контента, установим, как будет меняться размер сайта и пр.

index.php

Заголовок файла

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

< ?php
defined ("_JEXEC" ) or die ;
JHtml::_("behavior.framework" , true ) ;
$app = JFactory::getApplication() ;
?>
< ?php echo "< ?" ; ?> xml version= "1.0" encoding= "< ?php echo $this - > _charset ?> " ?>

DOCTYPE – это очень важный параметр, на основании которого браузер решает, как ему отображать эту страницу и как интерпретировать CSS.

< ! DOCTYPE html PUBLIC "- / / W3C/ / DTD XHTML 1.0 Strict/ / EN" "http:/ / www.w3.org/ TR/ xhtml1/ DTD/ xhtml1- strict.dtd" >

Следующий фрагмент извлекает установленный язык из глобальной конфигурации.

< html xmlns= "http:/ / www.w3.org/ 1999/ xhtml" xml:lang= "< ?php echo $this - > language; ?> " lang= "< ?php echo $this - > language; ?> " dir = "< ?php echo $this - > direction; ?> " >

Далее идет фрагмент кода, который включает дополнительную информацию для заголовка, которая задана в глобальной конфигурации. Эту информацию вы можете увидеть посмотрев исходный код любой веб-страницы. В частности – это мета-теги, о которых вы уже знаете.

< head>
< jdoc:include type= "head" / >

Следующие строки в заголовке содержат ссылки на основные CSS стили Joomla.

< link rel= "stylesheet" href= "< ?php echo $this - > baseurl ?> / templates/ system / css/ system .css" type= "text/ css" / >
< link rel= "stylesheet" href= "< ?php echo $this - > baseurl ?> / templates/ system / css/ general.css" type= "text/ css" / >

Чтобы задействовать стили оформления шаблона, делаем ссылку на файл, содержащий каскадные таблицы стилей template.css, который лежит в папке CSS . Не важно, что этот файл пока пустой, главное его подключить, оформлением займемся потом, когда инсталлируем шаблон на Joomla. Так будет проще наблюдать за результатом.

< link rel= "stylesheet" href= "< ?php echo $this - > baseurl ?> / templates/ < ?php echo $this - > template ?> / css/ template.css" type= "text/ css" / >

Следующий фрагмент кода позволяет нам сворачивать левую или правую колонки, если в позициях «left» и « right» не расположено ни одного модуля. В случае если свернуты обе колонки, то контент занимает 100% ширины страницы. Если включена только одна колонка, то контент занимает 80%. При двух включенных колонках на контент приходится 60% ширины страницы.

< ?php
if ($this - > countModules("left and right" ) = = 0) $contentwidth = "100" ;
if ($this - > countModules("left or right" ) = = 1) $contentwidth = "80" ;
if ($this - > countModules("left and right" ) = = 1) $contentwidth = "60" ;
?>

Заголовок закрывается

< / head>

< body>

Блок «page» содержит оформление только страницы сайта, именно она и будет шириной 950рх.

< div id= "page" >

Блок "top" находится в самом верху страницы и содержит в себе два блока "logo " и "user1".

< div id= "top" >

В боке «logo» мы разместим графический файл логотипа, это будет прописано в таблицах стилей. А вот автоматический вывод названия сайта прописываем в файле index.php, причем название помещаем в тег H1, что очень важно для поисковой оптимизации.

< div id= "logo" >
< h1> < ?php echo $app - > getCfg("sitename" ) ; ?> < / h1>
< / div>

Определим позицию «user1» в одноименном блоке для вывода модуля поиска по сайту.

< div id= "user1" >
< jdoc:include type= "modules" name= "user1" style= "xhtml" / >
< / div>
< / div> < ! - - конец блока top - - >

Вывод модуля горизонтального меню в блоке «user2» в позиции «user2» . Блок будет сворачиваться, если в этой позиции не будет модуля.

< ?php if ($this - > countModules("user2" ) ) : ?>
< div id= "user2 " >
< jdoc:include type= "modules" name= "user2" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Дальше идет блок шапки сайта «header» . В нем мы определим позицию «header» для вывода модулей. Блок будет сворачиваться, если в этой позиции не будет модуля. Я намеренно расширила возможности этого блока, чтобы иметь возможность разместить в нем не только картинку шапки, но и ротаторы изображений.

< ?php if ($this - > countModules("header " ) ) : ?>
< div id= "header " >
< jdoc:include type= "modules" name= "header " style= "xhtml" / >
< / div>
< ?php endif ; ?>

В блоке «user3» определим позицию «user3» для вывода модулей.

Блок будет сворачиваться, если в этой позиции «user3» не будет выводится модуль.

< ?php if ($this - > countModules("user3" ) ) : ?>
< div id= "user3" >
< jdoc:include type= "modules" name= "user3" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Открывается блок левой колонки, которая будет сворачиваться, если в позиции «left» не будет ни одного модуля.

< ?php if ($this - > countModules("left" ) ) : ?>
< div id= "left" >
< jdoc:include type= "modules" name= "left" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Открывается самый важный блок контента, который может занимать 100% ширины страницы, 80% и 60%, в зависимости от количества включенных колонок.

< div id= "content< ?php echo $contentwidth ; ?> " >

Вывод сообщений в компонентах

< jdoc:include type= "message" / >

Вывод содержимого контента.

< jdoc:include type= "component" style= "xhtml" / >
< / div> < ! - - конец блока контента- - >

Открывается блок правой колонки, которая будет сворачиваться, если в позиции «rigth» не будет ни одного модуля.

< ?php if ($this - > countModules("right" ) ) : ?>
< div id= "rigth" >
< jdoc:include type= "modules" name= "right" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Вывод блока «footer» , предназначенного для вывода модуля «HTML код» с информацией об авторских правах. Можно также разместить здесь нижнее горизонтальное меню или модуль представления контента. Блок будет сворачиваться, если в этой позиции «footer» не будет выводится не один модуль

< ?php if ($this - > countModules("footer" ) ) : ?>
< div id= "footer" >
< jdoc:include type= "modules" name= "footer" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Закрываются блок страницы сайта «page», body и весь код.

< / div> < ! - - конец блока page- - >
< / body> < ! - - конец блока body - - >
< / html> < ! - - конец кода- - >

Мы создали полноценный файл index.php . Теперь вы знаете, при помощи каких команд, и в какой последовательности выводятся блоки шаблона.

ВНИМАНИЕ: Для того, чтобы код шаблона читался из админпанели joomla, то файл index.php необходимо открыть в редакторе AkelPad и сохранить в кодировке UTF-8, при этом снять галочку BOM. Если вы использовали для работы с файлом программу Macromedia Dreamweaver , то необходимо в вернем меню выбрать пункт "Изменить" > "Свойства страницы" и выбрать кодировку документа Юникод (utf-8), при этом снять галочку "включить сигнатуры юникода (ВОМ)". Однако настоятельно не советую вам редактировать код из админки Joomla, если, что-то накосячите - обратной дороги нет, в отличии от программы Macromedia Dreamweaver , где всегда можно отменить сделанные изменения.

Само оформление блоков будет описано в template.css. Но настраивать таблицы стилей мы будем после инсталляции шаблона на Joomla 3 (joomla 2.5), а для этого необходимо создать

Для начала мы усовершенствуем страничку регистрации, добавив возможность загружать аватар. Исходное изображение должно быть формата jpg, gif или png. Так же оно должно быть не более 2 Мб. Не беспокойтесь, после его сжатия скриптом, размер аватара будет около 3 кб и формат jpg. Откройте страницу reg. php и допишите в теге < form > строчку enctype="multipart/form-data" ,как в примере:

Регистрация

print <<
Вы вошли на сайт, как $_SESSION (выход)


Эта ссылка доступна только зарегистрированным пользователям

Ваш аватар:




HERE;

//************************************************************************************
//при удачном входе пользователю выдается все, что расположено ВЫШЕ между звездочками.
}
?>

6. Необходимо сделать возможность выйти из аккаунта пользователям, которые вошли. На главной странице уже была ссылка на выход. Но этого файла пока не существует. Так создадим новый файл exit.php с кодом:

session_start();
if (empty($_SESSION["login"]) or empty($_SESSION["password"]))
{
//если не существует сессии с логином и паролем, значит на этот файл попал невошедший пользователь. Ему тут не место. Выдаем сообщение об ошибке, останавливаем скрипт
exit ("Доступ на эту страницу разрешен только зарегистрированным пользователям. Если вы зарегистрированы, то войдите на сайт под своим логином и паролем
Главная страница");
}

unset($_SESSION["password"]);
unset($_SESSION["login"]);
unset($_SESSION["id"]);// уничтожаем переменные в сессиях
exit("");
// отправляем пользователя на главную страницу.
?>

Ну вот и все! Пользуйтесь на здоровье! Удачи!

Решил написать эту заметку, потому как надоело отвечать 100500 раз одно и то же на ВиО.

Многие начинающие веб-программисты рано или поздно сталкиваются с задачей внедрения в свой сайт человеко-понятных линков (ЧПУ). До внедрения ЧПУ все ссылки имеют вид /myscript.php или даже /myfolder/myfolder2/myscript3.php, что тяжело для запоминания и ещё хуже для SEO. После внедрения ЧПУ линки принимают вид /statiya-o-php или даже на кириллице /статья-о-пхп.

Кстати о SEO. Человекопонятные линки на САМОМ деле придумали не для удобного запоминания, а в основном для повышения индексируемости сайта, потому что совпадение поискового запроса и части URL даёт хорошее преимущество в рейтинге поиска.

Эволюция начинающего PHP-программиста может быть выражена следующей последовательностью шагов:

1. Размещение plain-PHP кода в отдельных файлах и доступ к этим файлам через линки вида /myfolder/myscript.php
2. Понимание, что все скрипты имеют значительную часть общего (например, создание подключения к БД, чтение конфигурации, запуск сессии и проч.) и как следствие создание общей начальной точки «входа», некоторого скрипта, который принимает ВСЕ запросы, а потом выбирает — какой внутренний скрипт подключить. Обычно этот скрипт имеет имя index.php и лежит в корне, вследствие чего все запросы (они же URLы) выглядят так: /index.php?com=myaction&com2=mysubaction
3. Необходимость внедрения роутера и переход к человекопонятным линкам.

Замечу, что между пунктами 2 и 3 большинство программистов делают очевидную ошибку. Я не ошибусь, если назову это значением около 95% программистов. Даже большинство известных фреймворков содержат эту ошибку. И заключается она в следующем.

Вместо того, чтобы реализовывать принципиально новый способ обработки линков, ошибочно делается концепция «заплаток и редиректов» на базе.htaccess, которая заключается в том, чтобы с помощью mod_rewrite создавать множество правил редиректа. Эти строки сравнивают URL с каким-либо регулярным выражением и при совпадении расталкивают выуженные из URL значения по GET-переменным, в дальнейшем вызывая всё тот же index.php.

#Неправильный метод ЧПУ RewriteEngine On RewriteRule ^\/users\/(.+)$ index.php?module=users&id=$1 #....Ещё куча подобных правил...

У данной концепции множество недостатков. Один из них — трудность создания правил, большой процент человеческих ошибок при добавлении правил, которые сложно выявить, но они приводят к ошибке сервера 500.

Другой недостаток в том, что часто правится по сути конфига сервера, что само по себе нонсенс. И если в Apache конфиг можно «пропатчить» с помощью.htaccess, то в популярном nginx такой возможности нет, там всё находится в общем файле конфигурации в системной зоне.

И ещё один недостаток, вероятно, наиболее важный, что при таком подходе невозможно динамически конфигурировать роутер, то есть «на лету», алгоритмически менять и расширять правила выбора нужного скрипта.

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

Суть заключается в том, что начальный запрос всегда хранится в переменной $_SERVER[‘REQUEST_URI’], то есть его можно считать внутри index.php и разобрать как строку средствами PHP со всеми обработками ошибок, динамическими редиректами и проч и проч.

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

RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f #Если файл не существует RewriteCond %{REQUEST_FILENAME} !-d #И если папка не существует RewriteRule ^.*$ index.php

Причём это правило можно разместить как в.htaccess, так и в основном файле конфигурации Apache.

Для nginx соответствующее правило будет выглядеть вот так:

Location / { if (!-e $request_filename) { rewrite ^/(.*)$ /index.php last; } }

Всё просто.

Теперь рассмотрим кусок кода PHP в index.php, который анализирует ссылки и принимает решение — какой скрипт запускать.

/часть1/часть2/часть3

Первое, что приходит в голову — разбить её с помощью explode(‘/’, $uri) и сделать сложный роутер на основе switch/case, анализирующий каждый кусок запроса. Не делайте этого! Это сложно и в итоге приводит код в ужасный непонимабельный и неконфигурабельный вид!

Я предлагаю более лаконичный способ. Лучше не описывать словами, а сразу показать код.

"page404.php", // Страница 404 "/" => "mainpage.php", // Главная страница "/news" => "newspage.php", // Новости - страница без параметров "/stories(/+)?" => "storypage.php", // С числовым параметром // Больше правил); // Код роутера class uSitemap { public $title = ""; public $params = null; public $classname = ""; public $data = null; public $request_uri = ""; public $url_info = array(); public $found = false; function __construct() { $this->mapClassName(); } function mapClassName() { $this->classname = ""; $this->title = ""; $this->params = null; $map = &$GLOBALS["sitemap"]; $this->request_uri = parse_url($_SERVER["REQUEST_URI"], PHP_URL_PATH); $this->url_info = parse_url($this->request_uri); $uri = urldecode($this->url_info["path"]); $data = false; foreach ($map as $term => $dd) { $match = array(); $i = preg_match("@^".$term."$@Uu", $uri, $match); if ($i > 0) { // Get class name and main title part $m = explode(",", $dd); $data = array("classname" => isset($m)?strtolower(trim($m)):"", "title" => isset($m)?trim($m):"", "params" => $match,); break; } } if ($data === false) { // 404 if (isset($map["_404"])) { // Default 404 page $dd = $map["_404"]; $m = explode(",", $dd); $this->classname = strtolower(trim($m)); $this->title = trim($m); $this->params = array(); } $this->found = false; } else { // Found! $this->classname = $data["classname"]; $this->title = $data["title"]; $this->params = $data["params"]; $this->found = true; } return $this->classname; } } $sm = new uSitemap(); $routed_file = $sm->classname; // Получаем имя файла для подключения через require() require("app/".$routed_file); // Подключаем файл // P.S. Внутри подключённого файла Вы можете использовать параметры запроса, // которые хранятся в свойстве $sm->params

Несмотря на то, что код довольно длинный, он прост логически. Мне не хочется его объяснять, я считаю любой код на PHP самообъясняющим, если он правильно написан. Учитесь читать код.

Те, кто более-менее серьёзно изучал PHP знают, что существует один очень полезный глобальный массив в PHP , который называется $_SERVER . И вот хотелось бы в этой статье разобрать самые популярные ключи и их значения в этом массиве, так как их знание просто обязательно даже для начинающего PHP-программиста .

Прежде чем приступить к глобальному массиву $_SERVER в PHP , сразу сделаю небольшую подсказку. Есть замечательная функция, встроенная в PHP , которая называется phpinfo() . Давайте сразу приведу пример её использования:

phpinfo();
?>

В результате выполнения этого просто скрипта Вы увидите огромную таблицу с различными настройками интерпритатора PHP , в том числе, ближе к концу будет таблица значений глобального массива $_SERVER . Там будут перечислены все ключи и все соответствующие им значения. Чем это может Вам помочь? А тем, что если Вам потребуется то или иное значение, и Вы забудете, как называется ключ, то с помощью функции phpinfo() Вы можете всегда вспомнить его название. В общем, Вы выполните этот скрипт и сразу меня поймёте.

А теперь давайте перейдём к самым популярным ключам массива $_SERVER :

• HTTP_USER_AGENT - этот ключ позволяет узнать характеристику клиента. В большинстве случаев, это, безусловно, браузер, однако, не всегда. И опять же, если браузер, то какой, вот в этой переменной об этом можно и узнать.
• HTTP_REFERER - содержит абсолютный путь к тому файлу (PHP-скрипт , HTML-страница ), с которого перешли на данный скрипт. Грубо говоря, откуда пришёл клиент.
• SERVER_ADDR - IP-адрес сервера.
• REMOTE_ADDR - IP-адрес клиента.
• DOCUMENT_ROOT - физический путь к корневой директории сайта. Это опция задаётся через конфигурационный файл сервера Apache .
• SCRIPT_FILENAME - физический путь к вызванному скрипту.
• QUERY_STRING - весьма полезное значение, которое позволяет получить строку с запросом, а дальше можно заниматься парсингом этой строки.
• REQUEST_URI - ещё более полезное значение, которое содержит не только сам запрос, но и вместе с ним относительный путь к вызываемому скрипту от корня. Это очень часто используется для удаления дублирования с index.php , то есть когда у нас такой URL : "http://mysite.ru/index.php " и "http://mysite.ru/ " ведут на одну страницу, а URLы разные, следовательно, дублирование, что плохо скажется на поисковой оптимизации. И вот с помощью REQUEST_URI мы можем определить: с index.php или нет был вызван скрипт. И можем сделать редирект с index.php (если он присутствовал в REQUEST_URI ) на без index.php . В результате, при передаче такого запроса: "http://mysite.ru/index.php?id=5 ", у нас будет происходить редирект на URL : "http://mysite.ru/?id=5 ". То есть мы избавились от дублирования, удалив из URL этот index.php .
• SCRIPT_NAME - относительный путь к вызываемому скрипту.

Пожалуй, это все элементы глобального массива $_SERVER в PHP , которые используются регулярно. Их надо знать и уметь использовать, когда это необходимо.