Во-первых, атакующий может осуществить модификацию строки запросам таким образом, чтобы вызвать SQL-injection или PHP-including. Почти для всех CMS возможность реализации PHP-including полностью исключается. Однако реализация SQL-injection возможна во многих случаях.
Во-вторых, в каждой CMS имеется модуль, позволяющий оставить какую-либо информацию на сайте. Здесь возможно обойти проверки введённой информации и опубликовать на сайте специальный код, тем самым реализовав XSS атаку.
Также существуют уязвимости, связанные с разграничением прав администраторов различного уровня доступа.
//подключаемся к MySQL
mysql_connect($dbhost, $dbuname, $dbpass) or die(mysql_error());
mysql_select_db($dbname) or die(mysql_error());
$cid=$_GET["cid"];
$result=mysql_query("SELECT article_id, article_title FROM articles where category_id=$cid"); // <- уязвимый запрос
while( $out = mysql_fetch_array( $result)):
echo "Статья: ".$out['article_id']." ".$out['article_title']."<br>";
endwhile;
//выводим результат в виде списка
В переводе с языка MySQL запрос звучит так: "выбрать ид_статей, заголовки_статей из таблицы_статей где ид_категории равно $cid". На первый взгляд все верно, по ссылке типа http://serv.com/read.php?cid=3 скрипт работает нормально и выводит пользователю список статей, принадлежащих категории 3.
Но какие возможности это даёт злоумышленнику? Он может сделает запрос http://serv.com/read.php?cid=3' (именно с кавычкой) и получит что-то вроде: Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /usr/local/apache/htdocs/read.php on line 14.
Посмотрим, что запросил PHP у MySQL. Переменная $cid равна 1', тогда запрос принимает неверный с точки зрения MySQL вид: SELECT article_id, article_title FROM articles where category_id=1'. При синтаксической ошибке в запросе MySQL отвечает строкой "ERROR 1064: You have an error in your SQL syntax...". PHP не может распознать этот ответ и сообщает об ошибке, на основе которой хакер может судить о присутствии уязвимости типа SQL Injection. Очевидно, что злоумышленник получит возможность задавать переменной $cid любые значения ($cid=$_GET[cid]) и, следовательно, модифицировать запрос к MySQL. Например, если $cid будет равна "1 OR 1" (без кавычек в начале и в конце), то MySQL выдаст все записи, независимо от category_id, так как запрос будет иметь вид (..) where category_id=1 OR 1. То есть либо category_id = 1 (подойдут лишь записи с category_id, равными 1), либо 1 (подойдут все записи, так как число больше нуля - всегда истина).
Только что описанные действия как раз и называются SQL Injection - иньекция SQL-кода в запрос скрипта к MySQL. С помощью SQL Injection злоумышленник может получить доступ к тем данным, к которым имеет доступ уязвимый скрипт: пароли к закрытой части сайта, информация о кредитных картах, пароль к администраторскому разделу и т.д.. Атакующий может получит возможность выполнять команды на сервере.
Классический пример уязвимости типа SQL Injection - следующий запрос: SELECT * FROM admins WHERE login='$login' AND password=MD5('$password').
Допустим, он будет проверять подлинность введенных реквизитов для входа в администраторскую часть форума. Переменные $login и $password являются логином и паролем соответственно, и пользователь вводит их в HTML-форму. PHP посылает рассматриваемый запрос и проверяет: если количество возвращенных от MySQL записей больше нуля, то администратор с такими реквизитами существует, а пользователь авторизуется, если иначе (таких записей нет и логин/пароль неверные) - пользователя направят на fsb.ru.
Как взломщик использует SQL Injection в этом случае? Злоумышленнику требуется, чтобы MySQL вернул PHP-скрипту хотя бы одну запись. Значит, необходимо модифицировать запрос так, чтобы выбирались все записи таблицы независимо от правильности введенных реквизитов. Используем принцип "OR 1". Кроме того, в MySQL, как и в любом языке, существуют комментарии. Комментарии обозначаются либо --комментарий (комментарий в конце строки), либо /*комментарий*/ (комментарий где угодно). Причем если второй тип комментария стоит в конце строки, закрывающий знак '*/' необязателен. Итак, взломщик введет в качестве логина строку anyword' OR 1/*, а в качестве пароля - anyword2. Тогда запрос принимает такой вид: SELECT * FROM admins WHERE login='anyword' OR 1/* AND password=MD5('anyword2'). В результате MySQL вернет все записи из таблицы admins даже независимо от того, существует админ с логином anyword или нет, и скрипт пропустит хакера в админку. Такая уязвимость была обнаружена, например, в Advanced Guestbook. Она позволяла войти в администраторскую часть не зная пароля и внутри нее читать файлы. Но SQL Injection этого типа обычно не позволяют злоумышленнику получить данные из таблицы.
Уязвимость, типа XSS, возникает в тех ситуациях, когда данные введенные пользователем выводятся без надлежащей фильтрации в тексте сгенерированного html документа.
К примеру, может быть ситуация, когда данные, отправленные одним пользователем без фильтрации выводятся другим пользователям. Типичной системой такого рода являются чаты, форумы, различные системы управления.
Вторым вариантом уязвимости, является ситуация, когда часть HTTP GET запроса выводится на этой же html странице тому же пользователю без надлежащей фильтрации. Как правило – это ситуации, когда без надлежащей фильтрации выводится идентификатор сессии или другие GET параметры. Теперь рассмотрим некоторые ситуации, когда уязвимость отсутствует в явном виде.
Представим себе систему, например, форум, в котором в сообщения каким либо образом можно вставлять изображения со сторонних сайтов. Так, например, на многих форумах, вставить изображение можно используя конструкцию . Очевидно, что в таком случае, браузер каждого человека, посетившего страницу с таким сообщением, будет запрашивать данное изображение с указанного сайта, если конечно, это разрешено в настройках.
Теперь рассмотрим возможность того, что вместо изображение находиться некоторый скрипт , который делает следующее
1. cохраняет информацию о запросе
2. выводит заголовок: Content-type: image/jpeg (для JPEG изображения)
3. выводит содержание изображения.
Учитывая, что в большинстве случаев в качестве поля HTTP-REFERER, HTTP запроса при запросе картинок, браузер отсылает URL документа, на котором вставлена картинка, то при помощи скрипта можно собрать следующие данные.
1. IP адрес (включая заголовки X-FORWARDED_FOR и тп.)
2. Каждую страницу, посещенную каждым пользователем (при условии, что на ней имеется ссылка на данное изображение)
3. Поле User-Agent пользователя.
Наверное, результативнее всего для сбора статистики в большинстве форумов, такой URL изображения, следует задать в качестве URL аватара. Можно бы было предположить, что для того, чтобы исключить такую возможность, на сервере можно разрешить размещение только изображений, имеющих соответствующее расширение файла - .jpg или только .gif. Однако пользователь может настроить HTTP сервер таки образом, чтобы файлы .jpg к примеру, тоже считались и обрабатывались как PHP скрипты. Более того, PHP может быть сконфигурирован таким образом, что никакая информация об интерпретаторе PHP не посылалась в заголовке HTTP ответа. Таким образом, подобный сбор статистики может быть реализован абсолютно прозрачно для сервера и клиентов.
Никакими методами невозможно узнать, имеет место подобный сбор статистики или нет.
Конечно, всю эту информация можно собрат и из логов HTTP сервера, на котором находится такое “изображение”, но ведение логов в скрипте более удобно.
Предположим, что в некоторой системе (форуме), разрешено включать каким либо образом в сообщения картинки со сторонних серверов. Каждый раз, когда каждый пользователь открывает html страницу с таким сообщением, его браузер делает запрос на сервер, который может контролироваться хакером, с целью получения тела изображения. Теперь представим себе ситуацию, что на такой запрос, сервер ответил требованием авторизации. В такой ситуации, браузер запросит у каждого открывающего эту страницу пароль. Более того, надпись в окошке ввода пароля может быть произвольной и задается хакером. Например, там может быть написано о сбое авторизации, и прочие фразы, создание которых относится уже к социальной инженерии. Если пользователь введет в этом окошке свои имя и пароль, то эти данные будут отправлены на сервер, контролируемый хакером. Скрипт, генерирующий этот заголовок и принимающий данные может при повторном запросе (отслеживается по ip), вернуть содержимое изображение, без ответа о неудачной авторизации. Таким образом, после того, как пользователь введет имя и пароль, страница откроется в обычном виде. После отправки сообщения, сервер может запрашивать с удаленного сервера все изображения, имеющиеся в документе, и оставлять их в сообщении, только если они действительно будут являться правильными изображениями, и возвращаться с кодом 200. Однако, нападающий сможет легко отличить запрос сервера (по ip адресу, времени запроса и тп.), и возвратить серверу правильное содержание изображения.
Аналогично, можно полностью скрыть, что на стороне сервера работает скрипт.
На этапе добавление сообщения, серверу невозможно узнать, добавлено нормальное изображение, или нет. Это нападение может быть использовано как для попытки кражи реквизитов доступа к системе пользователя, так и для элементарного затруднения работы с системой легитимных пользователей.
Если пользователь имеет возможность добавить в текст сообщения изображение со стороннего сайта, которое будет доступно всем, открывающим эту html страницу, то становится возможным реализовать DDOS атаку. Допустим, в третьем сайте, имеется уязвимость – некоторый документ при некоторых параметрах потребляет слишком много системных ресурсов. В первую очередь имеется в виду имею ввиду SQL инъекцию, с возможностью внедрения benchmark() функции, таким образом, что один запрос сильно нагрузит уязвимый сервер. Об уязвимости типа SQL инъекция и в том числе об использовании функции benchmark в SQL запросе для проведения DOS атаки, рассказано в этой статье http://www.securitylab.ru/45438.html
Размещая в рассматриваемом форуме (предполагаем, что он имеет большую посещаемость), большое количество сообщений, содержащих изображения с URL на самом деле эксплуатирующие уязвимость в третьем сайте. Этот метод атаки, на первый взгляд кажется не эффективным по нескольким причинам. Не во всех случаях удастся поставить такой URL в качестве ссылки на изображение по той причине, что различные фильтры не сервере могут заблокировать сложный URL.
Мало вероятно, что за малый промежуток времени удастся разместить большое количество таких сообщений.
Если злоумышленник оставляет большое количество сообщений на часто посещаемых форумах, с ссылкой на изображение, находящееся на контролируемом им сервере. Лучше всего для таких целей подходит ссылка на аватар. После того, как накоплена значительная база таких сообщений, скрипт, ранее, возвращающий содержимое изображения, станет возвращать заголовок HTTP ответа 301 – moved, с указанным в Location заголовке URL, эксплуатирующим уязвимость в третьем сайте. Конечно, с этого момента, изображение открываться не будет. Но, каждый посетитель, открывающий любую страницу с таким изображением будет участвовать в DDOS атаке на такой скрипт.
В зависимости от накопленной базы таких сообщений, и мощности третьего сервера, результат может быть как значительное торможение сервера так и полной выход из строя сервера на период атаки или до исправления уязвимости.
Теперь рассмотрим другую ситуацию. К примеру, в некоторой системе (форуме), некоторыми методами в каждом сообщении можно оставить ссылку ( <a href=…>…</a> ), на произвольный URL.
Так, например, может использоваться следующие конструкции [URL=…]…[/URL]. Значение URL находится в двойных кавычках, все опасные символы, такие, как кавычки, знаки больше меньше, фильтруются, перед вставкой значения в качестве URL. Например, для вывода собственно URL ссылки и текста ссылки используется функция наподобие функции PHP htmlspecialchars(). Таким образом, выбраться за пределы атрибута href, невозможно. И невозможно изменить реакции на события OnMouseClick или OnMouseOver. Другими словами, казалось бы, уязвимость отсутствует. Однако следующий код показывает обратное:
[URL=javascript:alert(document.dookie)]click me[/URL]
Этот код конвертируется в:
<a href=”javascript:alert(document.cookie)”>click me</a>
Далее, при клике на эту ссылку, как ни странно, выполниться внедренный JavaScript код. Более того, выполниться он в контексте “неуязвимого” сайта, что влечет за собой все неприятности уязвимости XSS.
В частности, это может использоваться для кражи cookies целевого пользователя.
Для того, чтобы обойти, возможно присутствующие на сервере механизмы фильтрации, хакер может использовать некоторое приемы. Например, пробелы в JavaScript коде, могут замениться на последовательности /**/. А от использования кавычек спасет функция string.fromCharCode(), которая принимает коды символов и возвращает строку. Для исключения этой уязвимости достаточно фильтровать слово script в URL ссылки.
Вернемся к ситуации, с возможностью внедрения изображений в сообщения.
Допустим, для выполнения некоторых действий администратором системы или модератором, происходит переход по некоторой ссылке. Так, например, допустим, для удаления сообщения, администратору необходимо кликнуть на ссылку типа http://site/forum/delete-post.php?id=12345, где 12345 – это идентификатор сообщения. Теперь представим себе ситуацию, что хакер оставит на форуме сообщение с изображением, имеющим именно такой URL. Результатом будет то, что как только администратор прочитает это сообщение, его брfузер сделает запрос к данному URL, и, в том числе, передаст все аутентификационные данные (COOKIE) на сервер. Предполагается, что администратор в момент прочтения такого сообщения (например, отправленные ему приватным посыльным), аутентифицирован на форуме. В результате, целевое сообщение будет удалено, незаметно для администратора. Допустим, в результате какой либо фильтрации, в сообщениях на форуме невозможно вставлять изображения с таким URL. Тогда злоумышленнику поможет приём с Location.
Нападающему достаточно будет вставить в сообщение изображение, находящееся на контролируемом сайте. Контролируемый нападающим сервер при запросе данного изображения должен ответить заголовком 301 (или 302) moved, с Location полем, со значением целевым URL = http://site/forum/delete-post.php?id=12345.
В результате, при запросе этого изображения, браузер администратора обратиться по данному URL прозрачно для администратора будет выполнено некоторое действие. Как и ранее, нападающий может полностью скрыть факт выполнения скриптов на сервере, и, кроме того, любые фильтры возможно присутствующие в системе (форуме), могут быть пройдены указанным способом. Более того, просматривая URL изображения (в свойствах изображения в браузере), администратора не заметит ничего удивительного. URL может действительно выгладить как URL обычного изображения.
И, кроме того, если в системе предусмотрены методы контроля, и, для выполнения действий администратором, необходимо, чтобы HTTP REFERER, переданный браузером принадлежал форуму, то и эта проверка обходится автоматически. Дело в том, что при запросе изображения, расположенного на сайте, серверу на котором расположено изображение передается HTTP_REFERER равный URL-у страницы с изображением. А при переходе по Location, с заголовком 301 (302) Moved, HTTP-REFERER сохраняется. Внимание. К подобному типу атаки уязвимы ВСЕ системы (форумы, чаты), разрешающие вставку в сообщения изображений со сторонних сайтов, в случае, если для выполнения некоторых действий администратором (модератором), хватит простого HTTP GET запроса.
Теперь рассмотрим более сложную ситуацию. Для выполнения некоторых действий администратором необходимо отправить HTTP POST запрос. Примером может служить отправка сообщения от имени администратора, либо другие действия вплоть до перевода определенных пользователей между группами и наделения их привилегиями администратора.
Хакер может разместить ссылку ([URL=xxx]yyy[/URL]) на некоторое изображение или URL, с целью заманить администратора по указанному URL. Например, URL может быть похож на адрес картинки (*.jpg), чтобы не вызвать дополнительных подозрений у администратора. При переходе по этому URL, администратору может выводиться форма со скрытыми полями, содержащая все необходимые данные, и отправляться методами JavaScript автоматически после загрузки. Для поведения скрытой атаки, форма может находится в iframe объекте, который в свою очередь находится в невидимом слое. В то время, как в видимой части страницы действительно может располагаться какое либо изображение. Описанные возможности являются очень опасными по нескольким причинам.
1) существует огромное количество продуктов, уязвимых к такого рода атакам
2) атака очень легко осуществима
3) атака может быть проведена незаметно для администратора
4) атака может быть проведена с минимальными взаимодействиями с администратором (модератором) системы.
Для защиты от подобного рода атак рекомендуется каждый раз, для всех данных, отправленных на форуме, добавлять к ним идентификатор сессии или его хеш, с последующей проверкой на сервере. Если ссылки и содержание форм будут иметь непредсказуемый вид, то это сделает проведение таких атак весьма маловероятным.
Анализ проведен компанией ALT Web
Источник altweb-cms.ru/
