Создание своего стиля сhrome для модулей. Добавление акцента Добавление просто слешей

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

Что такое PHP-include

Проведем маленький ликбез по этой уязвимости. PHP-include — уязвимость которая позволяет «приинклудить» произвольный файл, например такой код:

$module=$_REQUEST["module"]; include("modules/".$module);

И так как в файле «/etc/pаsswd» обычно нет php тегов (), то он выведется в браузер, как вывелся бы html код вынесенный за php теги в обычном php скрипте. Конечно чтение файлов всего лишь одна из возможных реализаций этой атаки. Основная же все таки это инклудинг нужных файлов с нужным php кодом.

Вернемся к примеру. Усложним его:

$module=$_REQUEST["module"]; include("modules/".$module."/module.class.php");

Как видите теперь в конце к нашей переменной добавляется строка, которая нам мешает приинклудить любой файл. Так вот, многие функции php не являются бинарно безопасными, т.е такие функции считают NULL-байт за конец строки. Обращаемся к скрипту так:

script.php?module=../../../../../../../../../../../etc/pаsswd%00

И если дирректива magic_quotes отключенна, то мы снова увидим содержимое /etc/pаsswd

Есть ли уязвимость?

Вернемся к нашему коду:

$module=addslashes($_REQUEST["module"]); include("modules/".$module."/module.class.php");

Как видно, наша переменная принудительно проходит через «addslashes» и если мы попытаемся использовать NULL-байт то он будет преобразован в «\0» и инклуда не выйдет.

Но прогресс не стоит на месте! Оказывается некие ребята из USH нашли в PHP интересную фичу PHP filesystem attack vectors (англ.). Если в кратце пересказать суть статьи, то php обрабатывает пути с использованием нескольких особенностей:

• Усечение пути — php обрезает строку пути до заданной длины MAXPATHLEN (В Windows до 270 символов, в NIX — обычно 4096, в BSD — обычно 1024)
• Нормализация пути — php обрабатывает путь специальным образом, удаляя лишние символы «/» и «/.» и их различные комбинации
• Приведение к каноническому виду — убираются лишние переходы, например «dir1/dir2/../dir3» приводится к «dir1/dir3/» при этом существование дирректории «dir2» не проверяется, и прочие похожие преобразования (т.е продолжение нормализации)

Теперь по порядку что происходит с переданным путем:

1. Если путь передан относительный, то к нему вначале подставляются значения из диррективы include_path
2. Далее путь обрезается до определенной длины в зависимости от платформы
3. Проводится нормализация пути
4. Путь приводится к каноническому виду

Теперь попробуем воспользоваться этим. Попробуем приинклудить некий файл «test.php» который находится в дирректории «modules/». Для этого добавляем в конец симолы «/.» таким образом чтобы общая длина, вместе с именем файла, значением из include_path была заведомо больше 4096 символов.
script.php?module=test.php/././.[...]/././.

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

И один из этих вариантов сработает точно.

Анализируем

Смотрим по порядку какие преобразования произойдут с путем
modules/test.php//././.[...]/./././module.class.php
4200 символов

Первое что происходит со строкой, это к ней добавляется значение из include_path:
/home/site/public_html/modules/test.php//././.[...]/./././module.class.php
4223 символа

Затем строка ускается до MAXPATHLEN (допустим 4096):
/home/site/public_html/modules/test.php//././.[...]/./.
4096 символов

Здесь видно зачем нужно было добавлять еще один слеш (иначе бы строка обрезалась до слеша). Теперь производится нормализация этой строки, сначала убераются лишние слеши:
/home/site/public_html/modules/test.php/././.[...]/./.
4095 символов

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

То есть вот так мы приинклудим наш файл «test.php» успешно.
script.php?module=test.php//././.[...]/././.

А значит уязвимость есть и не теоритическая. В итоге мой клиент проспорил, а я выйграл спор и 10 рублей на которые мы поспорили. Конечно, помимо 10 рублей я выйграл еще и доверие и уважение в глазах клиента, что тоже не мало важно.

Заметки

Здесь я рассмотрю пару интересных особенностей эксплуатации этой уязвимости.

Выход из дирректории

Рассмотрим такой код:

) ;

Опустим тот момент, что можно вопсользоваться RFI и приинклудить файл с удаленного сервера. Допустим на сервере «allow_url_include=OFF».

Рассмотрим ситуацию когда нам надо приинклудить файл из дирректории ниже:
script.php?module=../test.php/././.[...]/././.

Такое обращение выдаст ошибку, типа файл не найден. И для того чтобы это обойти нам надо обратится вот так:
script.php?module=blabla/../../test.php/././.[...]/././.

Я не зря описывал про канонизацию путей. Благодаря ей дирректория «blabla» не обязательно должна существовать.

Добавление просто слешей

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

Все дело в алгоритмах, то есть, слеш с точкой «/.» убирается полностью. А вот с просто слешами дело обстоит немного сложнее, при нормализации каждые два слеша заменяются на один до тех пор пока не останется один(!) слеш, пример:

/home/site/public_html/modules/test.php//////////////////
57 символов
↓
/home/site/public_html/modules/test.php/////////
48 символов
↓
/home/site/public_html/modules/test.php/////
44 символов
↓
/home/site/public_html/modules/test.php///
42 символов
↓
/home/site/public_html/modules/test.php//
41 символов
↓
/home/site/public_html/modules/test.php/
40 символов

Небольшое отступление:

Причем если обратить внимание на многие, популярные хак ресурсы, то можно заметить эту ошибку. Я так понимаю эта ошибка началась со статьи некоего Raz0r где он предложил вектор:
index.php?act=../../../../../etc/pаsswd/////[…]/////

И обратите внимание даже журнал ][акер повторил эту ошибку в своей статье . При этом даже в оригинальной статье USH было четко написанно что использовать просто слеши не желательно, и необходимо чтобы в конце перед нормализацией остался символ точки. А просто слеши (даже без точки на конце) работают только в PHP c Suhosin.

То есть использовать слеш с точкой «/.» — более универсальный метод, так как, в отличие от слешей «/», он работает для всех версий php.

Заключение

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

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

Пример #1 Простейшая форма HTML

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

Пример #2 Выводим данные формы

Здравствуйте, .
Вам лет.

Пример вывода данной программы:

Здравствуйте, Сергей. Вам 30 лет.

Если не принимать во внимание куски кода с htmlspecialchars() и (int) , принцип работы данного кода должен быть прост и понятен. htmlspecialchars() обеспечивает правильную кодировку "особых" HTML-символов так, чтобы вредоносный HTML или Javascript не был вставлен на вашу страницу. Поле age, о котором нам известно, что оно должно быть число, мы можем просто преобразовать в integer , что автоматически избавит нас от нежелательных символов. PHP также может сделать это автоматически с помощью расширения filter . Переменные $_POST["name"] и $_POST["age"] автоматически установлены для вас средствами PHP. Ранее мы использовали суперглобальную переменную $_SERVER , здесь же мы точно так же используем суперглобальную переменную $_POST , которая содержит все POST-данные. Заметим, что метод отправки (method) нашей формы - POST. Если бы мы использовали метод GET , то информация нашей формы была бы в суперглобальной переменной $_GET . Кроме этого, можно использовать переменную $_REQUEST , если источник данных не имеет значения. Эта переменная содержит смесь данных GET, POST, COOKIE.

15 years ago

According to the HTTP specification, you should use the POST method when you"re using the form to change the state of something on the server end. For example, if a page has a form to allow users to add their own comments, like this page here, the form should use POST. If you click "Reload" or "Refresh" on a page that you reached through a POST, it"s almost always an error -- you shouldn"t be posting the same comment twice -- which is why these pages aren"t bookmarked or cached.

You should use the GET method when your form is, well, getting something off the server and not actually changing anything. For example, the form for a search engine should use GET, since searching a Web site should not be changing anything that the client might care about, and bookmarking or caching the results of a search-engine query is just as useful as bookmarking or caching a static HTML page.

2 years ago

Worth clarifying:

POST is not more secure than GET.

The reasons for choosing GET vs POST involve various factors such as intent of the request (are you "submitting" information?), the size of the request (there are limits to how long a URL can be, and GET parameters are sent in the URL), and how easily you want the Action to be shareable -- Example, Google Searches are GET because it makes it easy to copy and share the search query with someone else simply by sharing the URL.

Security is only a consideration here due to the fact that a GET is easier to share than a POST. Example: you don"t want a password to be sent by GET, because the user might share the resulting URL and inadvertently expose their password.

However, a GET and a POST are equally easy to intercept by a well-placed malicious person if you don"t deploy TLS/SSL to protect the network connection itself.

All Forms sent over HTTP (usually port 80) are insecure, and today (2017), there aren"t many good reasons for a public website to not be using HTTPS (which is basically HTTP + Transport Layer Security).

As a bonus, if you use TLS you minimise the risk of your users getting code (ADs) injected into your traffic that wasn"t put there by you.

Элемент em представляет собой отрывок текста с подчеркнутым акцентом. Вы можете использовать его, чтобы обратить внимание читателя на смысл предложения или абзаца. Я расскажу вам, что это обозначает, после , в которой описан элемент em .

Таблица 8-6: Элемент em

Рисунок 8-3: Использование элемента em

В этом примере я поставил акцент на Я (I) в начале предложения. Если подумать об элементе em , то при произнесении предложения вслух мы рассматриваем вопрос о том, что это предложение является ответом на вопрос. Например, представьте, что я спросил: «Кто любит яблоки и апельсины?» Ваш ответ будет: «Я люблю яблоки и апельсины.» (Когда вы произносите это вслух и ставите акцент на Я, вы даете понять, что вы человек, который любит эти фрукты).

Но если бы я спросил: «Вы любите яблоки и что еще?» Вы могли бы ответить: «Я люблю яблоки и апельсины (oranges)». В этом случае, акцент будет сделан на последнее слово, подчеркивая, что апельсины являются другим фруктом, который вам нравится. Этот вариант в HTML выглядел бы следующим образом:

I like apples and oranges .

Определение иностранных слов и технических терминов

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

Таблица 8-7: Элемент i

Рисунок 8-5: Использование элемента s

Определение важного текста

Элемент strong обозначает отрывок текста, который имеет важное значение. В описан этот элемент.

Таблица 8-9: Элемент strong

Рисунок 8-7: Использование элемента u

Добавление мелкого шрифта

Элемент small обозначает мелкий шрифт и часто используется для оговорок и уточнений. В представлен элемент small .

Таблица 8-11: Элемент small

Рисунок 8-8: Использование элемента small

Добавление верхнего и нижнего индекса

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

Таблица 8-12: Элементы sub и sup

Рисунок 8-9: Использование элементов sub и sup

Мы поверхностно коснулись темы методов вывода контента в теле шаблона. Давайте теперь подробно разберем что это и с чем его едят. Итак, объявления метода jdoc присутствуют в каждом шаблоне Joomla и выводят в тело шаблона (то бишь на страницу сайта) ту или иную информацию. В целом объявление метода выглядит следующим образом

Данная строчка выводит на сайте информацию из компонентов, например статьи из com_content. Тип элементов вывода указывается в атрибуте.

1. type - типы элементов вывода.

• component - как писал выше, выводит основное содержание страницы. Может вызываться только один раз в шаблоне.
• head - объявляется так же один раз после открывающего тэга . Служит для вывода стилей, скриптов,