Главная › Телефон › Сессии в PHP. Создание простой системы регистрации пользователей на PHP и MySQL Боровские index php user

Сессии в PHP. Создание простой системы регистрации пользователей на PHP и MySQL Боровские index php user

Сег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!

Script языка на Apache сервере.

index.php - самый распространенный стартовый файл для начала работы скриптового языка программирования PHP на WEB сервере, в основном Apache .

Для новичка стоит только знать, что большинство сайтов (sites) свою работу начинают именно с этого файла (file). Размещается файл в корне основного хранилища файлов сайта. Также может располагаться внутри директорий (directory ). Тогда Apache сервер будет искать и грузить в первую очередь index.php в запрашиваемой директории, если не прописано что-либо иное в файле настроек сервера htaccess

Как заставить Apache первым загружать index.php (options)

Как правильно делать:

# чтобы работа начиналась только с index.php DirectoryIndex index.php

Многие делают еще так:

# начинать запуск скриптов с проверки указанной последовательности DirectoryIndex index.php index.html index.shtml

Тут стоит немного объяснить алгоритм действий:

Пытаемся загрузить index.php .

Если index.php directory ), то пытаемся загрузить index.html .

Если index.html не обнаружен в корневом директории (directory ), то пытаемся загрузить index.s html

Есть много других опций (options) для управления загрузками, но это надо читать более расширенную спецификацию htaccess .

Используют такой метод, как правило , в том случае, если хотят защитить index.php от сканирования на предмет различных уязвимостей, например:

Index.php?mode=page&url="%20AND1="1

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

Как скрыть index.php через htaccess

На WEB сервере Apache должен быть включен модуль mod_rewrite . На сегодняшний день данный модуль включен практически у каждого , но в любом случае в этом нужно убедиться, иначе не получиться работать. Данный метод в основном используют SEO оптимизаторы.

Код для скрытия index.php

# включаем модуль mod_rewrite RewriteEngine on # все что после index.php отправлялось на главную командную строку RewriteCond %{THE_REQUEST} ^{3,9}\ /index\.php\ HTTP/ # убираем index.php из командной строки, чтобы оставалась только полезная информация RewriteRule ^index\.php$ http://сайт/

Как все запросы отправлять через index.php (redirect)

Тут тоже в общем-то ничего сложного

# Включаем работу mod_rewrite RewriteEngine on # если запрос не является файлом, то он будет отправляться на index.php # это делается, если ваш файл index.php обрабатывает не все, # что требуется, так как часто требуется разделить проект на более мелкие модули RewriteCond %{REQUEST_FILENAME} !-f # если запрос не является директорией, то он будет отправляться на index.php # это делается, чтобы директории типа /images/ не переадресовывались на index.php RewriteCond %{REQUEST_FILENAME} !-d # все остальное отправлять на index.php и там отрабатывать RewriteRule (.*) index.php [L]

Как скачать index.php

При соблюдении WEB мастером правил безопасности скачать index.php нельзя по определению.

Можно скачать index.php только в случаях, если:

Неправильно прописаны настройки в (.htaccess) . Здесь виноват только сам WEB мастер.
Имеется доступ к серверу через FTP протокол . Самый распространенный способ. Жертва заманивается на заранее сделанный сайт так как надо под различными предлогами (Вы выиграли миллион, ваш аккаунт заблокирован в социальных сетях и так далее). Как только вы попадаете на необходимый сайт, у вас копируют cookies. После этого пытаются их использовать для входа уже на ваш сайт. Избежать этого легко, достаточно не пользоваться WEB интерфейсами для управления своим сайтом и не устанавливать на свой компьютер каких-либо программ от неизвестных вам авторов с неизвестных источников, например: всякие ускорители интернета или сомнительные toolbar для с сомнительной эффективностью, но очень сильной настойчивостью его установить.
На сервере установлен дополнительный скрипт (back door ). Через такой скрипт можно получить любой файл с сервера, при этом чтобы он не был выполнен обработчиком PHP. Такие файлы можно загрузить на сервер через распространенные и известные уязвимости систем управления контентом (CMS). Например: WordPress, Joomla, DLE, Drupal, Codeigniter и так далее. Далее, под видом аватара загружается специально сформированный .gif файл, который в последствии можно вызвать, зная его расположение на сервере жертвы. Если CMS неправильно обрабатывает такие файлы, то через него можно получить необходимые доступы к сайту. Либо на CMS, типа WordPress, Joomla и другие устанавливается широко разрекламированный како-либо plugin (например: php search index ), который вроде бы и выполняет свою функцию, но при этом сливает данные о сайте своим разработчикам, тем самым позволяя им использовать сайт так, как им захочется.

Вот как-то так. Если у вас есть вопросы, задавайте их в комментариях, и в скором времени разъяснительный ответ появиться в этой статье.

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

Большинство таких атак происходят в результате использования "дыр" в серверных скриптах. Именно о прикрытии этих самых лазеек для хакеров и будет рассказано в данной статье.

Итак, как было сказано, хакер может получить доступ к сайту через серверные скрипты (конечно, есть множество других возможностей, например, украсть пароль - трояном, снифером или даже нагло, с компьютера пользователя, но это уже отдельная тема). Почему именно серверные? Да потому что с клиентскими - теми, что исполняются на машине посетителя сайта, он ничего не поделает. Они не имеют никаких прав доступа к серверу, разве что могут получать от него информацию да и только, но не в коем случае, клиентские скрипты не смогут самостоятельно изменить что-то на сервере.

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

Прежде всего, хочу сказать, что представленные тут примеры не гарантируют на 100% того, что вас никто не взломает, такое просто невозможно. Всегда, даже в самых распространенных и совершенных системах есть узкие места, пример тому сенсация полугодовой давности, когда на сайтах по всему миру в запросах на всеобще признанном языке SQL (Structured Query Language - структурированный язык запросов) была найдена грубейшая ошибка, получившая название SQL Injection. Но при этом вы увидите самые частые фатальные ошибки в защите и сможете на должном уровне защитить себя от атаки не только любителя, но и профессионального хакера.

Для начала вам нужно запомнить только одно - никогда не верить данным, полученным от посетителя - ведь они могут представлять собой вредоносный скрипт, который к стати, может быть как серверным, так и клиентским (будет работать на машинах посетителей). И этого вполне хватит, конечно, если в самих скриптах недопущены критические ошибки и нормально настроен сам сервер, но обо всем по порядку.

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

Для начала было бы неплохо ограничить длину имени и адреса e-mail. Это не только один из многочисленных методов частичной защиты, но и предохранение от шутников, которые думают что имя длиной в несколько сот символов очень забавно. Так что давайте в поле для ввода напишем, скажем, maxlength=25, например:

Таким способом никто не сможет ввести в данное поле более 25 символов. Однако это остановит только виртуальных вандалов-новичков ведь в адресной строке запросто можно написать что-то типа:

...guest.php?user_email=ha_ha_ha_slabaja_zashita_ha_ha_ha_tyt_bil_super_haker...

Что же, нанесем второй удар, написав в самом начале PHP скрипта примерно такое:

В противном же случае, перенаправляем его на страницу ввода логина и пароля: header ("location: index.php");

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

А потенциально опасными являются следующие моменты:

Несмотря на наличие проверки того что, данные отправлены из формы, можно спокойно сымитировать это и попытаться перебрать пароль через скрипт auth.php

Скрипт done.php можно обмануть так: done.php?login_user=login

Для устранения первой уязвимости желательно проделать все что было описано в предыдущей статье, а именно - жесткий приме переменной только из массива POST, проверка $HTTP_REFERER, проверка и урезка переменной. Также, раз нам нужно защититься от многочисленных атак, можно записывать IP посетителя и, скажем после 3 неудачных попыток блокировать его на 15 минут. Однако я бы посоветовал не применять блокировку IP - ее можно элементарно обойти, а многие пользователи прокси серверов могут страдать из-за нее. Гораздо разумнее применить задержку авторизации. Т.е. непосредственно перед проверкой корректности логина и пароля делаем задержку, скажем на 1 секунду. Пользователи ее скорее всего даже не заметят, а вот у хакеров скорость перебора упадет ниже 1 комбинации в секунду, что фактически полностью исключает возможность перебора пароля даже по специальному словарю. Осуществить задержку можно так:

sleep(1); //задержка на 1 секунду

Что же касается второй проблемы с защитой, там все еще легче. Несмотря на то что любой желающий может передать переменную $login_user, содержащую произвольный логин скрипту done.php, все же кое-что можно сделать. А именно удалить переменную (в PHP нет нужды объявлять переменные, поэтому и понятие удаления переменной можно сравнить скорее с очисткой переменной) с помощью функции unset(); после чего откроем сессию, в которой хранится значение переменной $login_user, взятое с сервера, т.е. истинное значение, на которое хакер никак не может повлиять. Сделать это можно так: