special опрос

Хакер, номер #075, стр. 072

СПЕЦ: Проблемы с SQL Injection получили широкую огласку благодаря уязвимости сайтов, так как web — массовый продукт. Но где еще можно встретить SQL Injection?

Валерия Комиссарова:

Главное в SQL Injection не то, что эта уязвимость активно эксплуатируется в web-приложениях, а то, что она может быть использована абсолютно во всех приложениях, написанных на любых языках программирования, в которых использованы SQL-запросы (ведь практически в каждый из них можно внедрить опасные SQL-инъекции).

ЗАРАЗА:

SQL Injection — это достаточно общий класс уязвимостей, которые можно встретить везде, где доступ к какому-либо содержимому базы данных ограничен на уровне интерфейса (клиентского приложения). И еще шире — везде, где данные пользователя используются для обращения к базе данных. Примеры не web-приложений, имеющих подобные уязвимости, можно найти тут: www.security.nnov.ru/search/news.asp?keyword=sql+injection&start=21.12.2003&end=21.12.2006&x=0&y=0.

Михаил Фленов:

Везде, где используются sql-запросы и параметры передаются пользователем через какой-то интерфейс управления. Пользователь может также внедрить свой sql-запрос, чтобы получить недоступные данные. Однажды я работал с программой, которая собирала данные с телефонной станции предприятия и сохраняла информацию в базу. Пароли пользователей тоже были в базе и отличались по ролям. Моя роль была примитивна: я мог видеть только данные, но не мог управлять станцией. Sql-инъекция помогла вытащить все пароли и повысить свои привилегии. Конечно, в программах на языках С++ и Delphi не всегда удается использовать инъекцию, но и такое тоже возможно, при определенной ушастости программиста.

Антон Карпов:

Очевидно, везде, где требуется ввод данных от пользователя, а базы данных используются в качестве backend'а для хранения информации. Это может быть не только онлайн-магазин или веб-форум (хотя понятно, что www является наиболее широкой областью применения SQL Injection). Это может быть любое приложение, которое хранит информацию в базе данных и предоставляет интерфейс для доступа к ней.

Крис Касперски:

Наверное, везде, где стоит SQL, обрабатывающий не отфильтрованные пользовательские запросы. Многие программы, работающие с базами данных, используют SQL. Клиентское приложение взаимодействует с пользователем и генерирует sql-запросы, посылая их серверу. В правильно спроектированной системе разграничение доступа к данным осуществляется на сервере. Клиента это вообще не касается, - он вправе слать любые запросы. Но далеко не все разработчики это понимают (или реализуют должным образом). В результате часть (или все) проверки на наличие у пользователя прав выполнять данную sql-операцию осуществляются на клиентской стороне, внутри программы. Обычный пользователь, действительно, не может обойти защиту, так как наталкивается на интерфейс, но хакер легко направит запрос к sql-серверу по Сети и тот послушно выполнит его со всеми вытекающими отсюда последствиями (а иногда никакой Сети вообще нет, «sql-сервер» представляет собой локальную программу). Тем не менее, web-интерфейс является одним из самых популярных способов взаимодействия с базами данных (особенно удаленными), и актуальность атак типа SQL Injection в обозримом будущем снижаться не будет.

Александр Антипов:

Везде, где данные, полученные от пользователя, записываются в БД. Часто это прикладные системы или системы регистрации событий (например IDS-системы). Один из вариантов эксплуатации IDS-систем — создать событие, которое при записи в базу данных реализует нападение sql-инъекции.

СПЕЦ: Какие способы борьбы с SQL Injection наиболее эффективны?

Валерия Комиссарова:

Существует несколько методов борьбы с sql-инъекциями:

1 ИСПОЛЬЗОВАНИЕ РАЗЛИЧНЫХ ФУНКЦИЙ (КАК ВСТРОЕННЫХ СИСТЕМНЫХ/ЯЗЫКА ПРОГРАММИРОВАНИЯ, ТАК И СОЗДАННЫХ ПРОГРАММИСТОМ) ДЛЯ ЭКРАНИРОВАНИЯ РАЗЛИЧНЫХ «НЕДОБРОКАЧЕСТВЕННЫХ» СИМВОЛОВ В ЗАПРОСЕ.

2 ИСПОЛЬЗОВАНИЕ МЕТОДА ПЕРЕБОРА, КОТОРЫЙ ПОЗВОЛЯЕТ КРОМЕ СИМВОЛОВ УДАЛЯТЬ И РАЗНЫЕ УПРАВЛЯЮЩИЕ СЛОВА И ПОСЛЕДОВАТЕЛЬНОСТИ.

3 ИСПОЛЬЗОВАНИЕ СПЕЦИАЛЬНЫХ ФУНКЦИОНАЛЬНЫХ «ОБЕРТОК», БЕРУЩИХ НА СЕБЯ ВСЮ «ГРЯЗНУЮ» РАБОТУ.

4 ИСПОЛЬЗОВАНИЕ ТИПИЗИРОВАННЫХ ПАРАМЕТРОВ.

ЗАРАЗА:

Основные методы борьбы примерно следующие:

1 ИЗБЕГАТЬ ИСПОЛЬЗОВАНИЯ SQL-ЗАПРОСОВ, ИСПОЛЬЗОВАТЬ ВМЕСТО НИХ ХРАНИМЫЕ ПРОЦЕДУРЫ И ПРЕДСТАВЛЕНИЯ.

2 КОНТРОЛИРОВАТЬ ЛЮБОЙ ЗАПРОС ПОЛЬЗОВАТЕЛЯ НА УРОВНЕ ПРОЦЕДУР ПОЛУЧЕНИЯ ДАННЫХ (НАПРИМЕР, ПРОЦЕДУРА ПОЛУЧЕНИЯ ПЕРЕМЕННОЙ ИЗ QUERY_STRING).

3 СОЗДАВАТЬ РОЛИ В БАЗЕ ДАННЫХ, НАДЕЛЕННЫЕ МИНИМАЛЬНЫМ НАБОРОМ ПОЛНОМОЧИЙ, ЧТОБЫ ДАЖЕ ИМЕЯ ПОЛНЫЙ ДОСТУП К БАЗЕ ДАННЫХ, ПОЛЬЗОВАТЕЛЬ НЕ МОГ ПРОИЗВЕСТИ «ВРЕДНЫХ» ДЕЙСТВИЙ.

4 МОЖНО НАЗВАТЬ ЕЩЕ И СРЕДСТВА ФИЛЬТРАЦИИ ЗАПРОСОВ, ФАЙРВОЛЫ НА УРОВНЕ ПРИЛОЖЕНИЙ (БАЗ ДАННЫХ), НО ВСЕ ЭТО - «НЕПРАВИЛЬНЫЕ» СРЕДСТВА.

Михаил Фленов:

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

Крис Касперски:

Разграничение доступа к данным на уровне SQL-сервера. Но проблема здесь в том, что с точки зрения SQL-сервера, обрабатывающего запросы web-сервера, под которым «вращается» сайт, написанный на PHP или Perl'е, все запросы равнозначны, поскольку авторизация пользователей (даже если она и предусмотрена), как правило, осуществляется на PHP. Просто в SQL-базе хранятся пользователи с паролями, проверяемыми PHP-скриптом, а для SQL есть только один пользователь — сам PHP-скрипт. Причем PHP — не самый безопасный язык программирования (как, впрочем, и Perl). Он допускает интерполяцию строк и вообще любит разводить самодеятельность. На Си написать безопасный сайт намного проще, но тут уже возникают проблемы иного рода: переносимость, переполнение буферов (фундаментальная проблема Си) и т.п. Так что остается нанимать грамотных программистов, имеющих реальный опыт, и давать им реальные сроки для выполнения заказа, поскольку подавляющее большинство ошибок совершается из-за невнимательности, излишней суетливости и нервозности, вызванной нависающим дедлайном.

Александр Антипов:

Защита! Как на уровне кода, так и на уровне сервера. К сожалению, способов эксплуатации sql-инъекции огромное множество и часто ошибаются даже опытные программисты. Поэтому всегда необходимо использовать дополнительные средства защиты на сервере — минимизация привилегий, Web-IDS-системы (типа mod_security или secureIIS).

СПЕЦ: XSS — реальная угроза или слабое место пофигистов?

Валерия Комиссарова:

На мой взгляд, проблема XSS достаточно серьезна и распространена, чтобы не принимать ее во внимание. И масштабы этой «эпидемии» заставляют говорить об XSS как о значительной угрозе, а не как об очередной PR-придумке.

ЗАРАЗА:

Одна из моих первых статей, посвященных проблемам безопасности, называлась «Еще раз о взломах HTML-чатов» (www.security.nnov.ru/articles/3APA3Ahtml.asp). Была написана, если не ошибаюсь, в 1998 году и содержала реальные примеры межсайтового скриптинга. Термина такого в то время еще не существовало, и вообще, эта проблема достаточно долго не считалась проблемой безопасности. Я помню продолжительный диалог с Aleph One (основатель и первый модератор Bugtraq) на эту тему, но убедить его в реальности угрозы мне тогда так и не удалось. Только в 2001 году ошибки CSS/XSS начали восприниматься как проблемы безопасности, и появился сам термин «crossite scripting».

Михаил Фленов:

Сверхугрозой я бы эту атаку не назвал. Да и SQL Injection тоже нельзя отнести к сверхугрозе. Все это невнимательность или ламерство программистов. Если первое, то это не страшно, потому что программист, допустивший ошибку, быстро исправит ее сам. А вот ламер, который не хочет учиться, пострадает намного сильнее. Глядя на количество дырявых сайтов в интернете, понимаешь, что количество программистов сокращается, а ламеров — растет.

Антон Карпов:

Любая проблема безопасности возникает из-за человеческого фактора. Безопасность системы во многом определяется ее качеством. Если говорить о программных средствах, то это качество кода. Программист недосмотрел, недодумал, совершил пару известных ошибок — это может быть как пофигизм, так и низкая квалификация. Учитывая растущую популярность XSS-атак, я бы не назвал это слабым местом пофигистов, во всяком случае, тогда бы нам пришлось признать, что пофигистов в мире очень и очень много :).

Крис Касперски:

XSS/Cross-site scripting появился, когда Netscape добавила в браузер поддержку JavaScript. А это не вчера и не позавчера, а много лет назад было. И сейчас без скриптовых языков никуда. Стоит только отключить их поддержку, как значительная часть сайтов отображается неверно или вообще перестает работать. А модель (не)безопасности виртуальных машин давно стала притчей во языцех, и еще ни одному производителю не удалось избежать ошибок реализации. В лучшем случае, злоумышленник получает доступ к cookies'ам (хранящим массу конфиденциальной информации). В худшем же - полностью захватывает управление удаленной машиной. Это вполне серьезная угроза, с которой необходимо считаться.

Александр Антипов:

Это до сих пор актуальная, хоть и старая проблема. Способов эксплуатации XSS - огромное количество. Многие почему-то считают, что XSS — это кража куки и не более того. Но используя XSS-прокси, фишинг, XSS-червей, злоумышленники не преследуют подобной цели.

СПЕЦ: Какие способы борьбы с XSS наиболее эффективны?

Валерия Комиссарова:

Из-за большой родственности атак SQL Injection и XSS общие концепции методов борьбы с ними также очень похожи. Все та же фильтрация (встроенными средствами или созданными своими силами), использование «строгих» имен и так далее. И в дополнение... включай мозги :).

ЗАРАЗА:

К сожалению, единственный действенный способ борьбы — полностью отказаться от того, чтобы дать пользователю возможность использовать прямо или косвенно какие-либо тэги. Например, можно фильтровать любые HTML-тэги на уровне функций разбора запроса и служебных заголовков. Но даже такой способ не дает 100% гарантии защиты.

Михаил Фленов:

Нужно внимательно писать код и тестировать все по нескольку раз. Лет пять назад даже в нашей стране разные фирмы достаточно часто обращались к спецам по безопасности для тестирования своих систем. Мне самому приходилось иногда тестировать. А за последние два года у меня был только один подобный заказ. Однажды я нашел дыру на сайте и показал ее владельцу, после этого он попросил протестировать еще один его сайт. Сейчас чаще обращаются с просьбой взломать, но я взломами не занимаюсь. Я не думаю, что только ко мне стали меньше обращаться. Пять лет назад хакеры даже пытались открывать фирмы по тестированию безопасности. И в начале бизнес вроде пошел, но потом умер. Или хакеры выполняли свои обязанности плохо, или заказчики не увидели преимуществ.

Тестировать нужно и сайты, и программы. И лучше, если это будут независимые люди. Сколько хакеров смогло бы направить свои усилия в мирное русло! Около года назад мне предлагали тестировать безопасность в Agnitum и, хотя я отказался, общение с ребятами показало, что не зря Outpost Firewall — один из лучших, потому что подход правильный. Я с удовольствием доверю безопасность своего компьютера сетевому экрану, который тестируется, быстро развивается и отслеживает тенденции в мире безопасности. Если бы все программисты так работали, то количество взломов сократилось бы в разы.

Крис Касперски:

Отключить поддержку Java и Ко в браузере, а если это невозможно, использовать наиболее аккуратно написанные бразуеры (например, Оперу). IE дыряв, как ведро без дна. В Горящем Лисе в последнее время наблюдается непрекращающийся рост уязвимостей, превративших его в дуршлаг. Так что никто не может чувствовать себя в безопасности, разве что пользователи рыся (бразузер Lynx, не путать с Linux).

Александр Антипов:

То же, что и с sql-инъекцией — защита на уровне кода и на уровне сервера. Отличия лишь в частностях. Во-первых, защититься от XSS значительно сложнее из-за разнообразия методов атак, а во-вторых, некоторые типы XSS (например, DOM XSS) вообще не задействуют серверную часть, и фильтрация на уровне сервера в этих случаях не поможет.

СПЕЦ: Можно ли защитить динамический сайт от SQL Injection и XSS (есть скрипты, работающие с БД) на 100%?

Валерия Комиссарова:

Очевидно, что защититься на 100% ни от чего нельзя. И не стоит искать победителей в бою хакеров-программистов. Но использование различных методов борьбы с этими напастями (методов, между прочим, уже давно выявленных и формализованных) позволит обезопасить сайт если не на 100, то на 90%. И это уже неплохо, ведь профессиональных взломщиков среди современного хак-контингента совсем не много.

ЗАРАЗА:

Как было сказано выше...

Михаил Фленов:

Защититься можно, но для этого нужно постоянно думать о безопасности — во время проектирования, реализации и внедрения. Обо всем этом нужно думать постоянно, а не когда взломали.

Антон Карпов:

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

Крис Касперски:

100% гарантию не дает даже Госстрах. Хотя идея застраховать сайт в страховой компании не такая уж и бредовая, какой кажется на первый взгляд. По крайней мере, в случае атаки компания компенсирует нанесенный ущерб. А если серьезно, то все решает сложность. Несколько сотен строк можно проверить и вдоль, и поперек. Но трудоемкость проверки кода растет быстрее его объема и, начиная с некоторого уровня, становится практически невыполнимой задачей, требующей гигантских ресурсов. Следовательно, лучшая защита — это простота исполнения.

Александр Антипов:

Можно, но очень сложно. Как пример, несколько месяцев назад в блоге на Securitylab (www.securitylab.ru/blog/tecklord/) были опубликованы примеры XSS на крупнейших сайтах, и многие из дыр до сих пор не закрыты... А рецепт тот же — качественное исследование кода и превентивная защита на уровне сервера.

Валерия Комиссарова

Имеет статус Microsoft Student Partner и сертификаты специалиста Microsoft и разработчика решений на C# под .NET

ЗАРАЗА

Руководитель службы поддержки пользователей довольно крупного ISP. Хобби — разработка программного обеспечения, в частности, проект 3proxy (www.security.nnov.ru/soft/3proxy/)

Михаил Фленов

Создатель сайта www.vr-online.ru, автор 11 книг на русском и 4 на английском языке

Антон Карпов

Специалист в области информационной безопасности. Круг профессиональных интересов: сетевые атаки, безопасность UNIX-систем, безопасность беспроводных сетей

Крис Касперски

Компьютеры грызет еще с тех времен, когда Правец-8Д считался крутой машиной, а дисковод с монитором были верхом мечтаний. Освоил кучу языков и операционных систем, из которых реально использует W2K, а любит FreeBSD 4.5

Александр Антипов

Руководитель проекта, автор/соавтор/редактор многочисленных статей ведущего отечественного портала по информационной безопасности SecurityLab.ru