Метод активной защиты от SQL-инъекций в веб-приложениях (тезисы)

Введение


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

Современный рынок развития веб-приложений, скорость и качество их разработки показывает полное отсутствие единых стандартов построения безопасных веб-приложений, что неизбежно приводит к ошибкам в разработке программного обеспечения и влечет к появлению серьезных уязвимостей. По результатам исследования веб-приложений за 2008 г. международной экспертной организации Web Application Security Consortium были получены следующие данные. Наиболее распространенными уязвимостями в веб-приложениях признано межсайтовое выполнение сценариев и внедрение операндов SQL, а также различные виды утечки информации и расщепление HTTP-запроса. При использовании автоматических средств поиска уязвимостей в программных средствах была получена вероятность обнаружения критичной ошибки 49% в динамическом веб-приложении. При всестороннем экспертном анализе методом белого ящика полученная вероятность составляет 96%, что в среднем позволяет идентифицировать до 91 уязвимости высокой степени риска на одно веб-приложение, автоматизированное сканирование позволяет идентифицировать — только три уязвимости с высокой степенью риска. В статистику вошли данные по 12186 веб-приложений, в которых было обнаружено 97554 уязвимости различной степени критичности.

Метод анализа веб-приложений


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

В предлагаемый метод предотвращения SQL-инъекций входит стадия анализа, сбора информации о защищаемом веб-приложении и механизм активной защиты приложения в режиме реального времени. Во время анализа веб-приложения исследуются исходные коды программного обеспечения, из которых выделяются все используемые SQL запросы к базе данных. Запросы классифицируются по трем категориям SELECT, INSERT, UPDATE и запоминаются программным средством защиты. Следующим этапом программное средство защиты обращается к базе данных с целью получения информации об используемых типах данных в полях таблиц. В результате всех действий программное средство защиты получает исходную информацию о всех используемых в веб-приложении SQL-запросах и типе данных, которые могут передаваться в этих запросах.

image

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

Если поступающий в базу данных запрос находится в профиле защиты программного средства, то тогда следующим действием программное средство проверяет передаваемые внешние данные в SQL-запросе на соответствие с типом данных таблицы, с которыми эти данные соотносятся. Если анализируемый запрос проходит все проверки, то он допускается до выполнения.

image

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

Заключение


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

На данном этапе разрабатывается программный модуль для подтверждения этого метода и анализа его эффективности использования в high-load веб-приложениях.
–5
10 февраля 2010, 16:36
11
solomatin 15,0

комментарии (29)

0
igamity #
Что-то мне кажется сомнительным использование такой системы в хайлоаде. Да и вообще в собственном приложение. ИМХО, такое решение может подойти хостерам для комплексной защиты БД, типа спам-фильтра на почте. В собственном приложение, если уж задумались о предотвращение инъекций, надежнее и быстрее входящий данные проверять на соответствие типам, что собственно эта система и делает.
0
moooV #
Лагать будет жесть…
–1
solomatin #
вы правы, система нужна там где нету возможности самому кодить и проверять свой кодинг )) напримре хостерам.
спасибо за комментарий!
0
webportal #
Ну я так думаю можно сделать класс обёртку для валидации запросов…
Как на такое смотрите???
0
lany #
Вообще что-то разумное в этом есть. Расширяем класс доступа к СУБД в двух режимах: обучение и работа. Изменения в коде минимальны, если вообще потребуются. В режиме обучения класс запоминает щаблоны всех запросов и, возможно, стек в момент вызова. Затем прогоняем тесты и всесторонне тестируем систему вручную, не пытаясь её взломать. Затем подменяем класс на рабочий и выпускаем в продакшн. Рабочий класс уже сравнивает запросы с тем, что может прийти от приложения (или даже из конкретного метода, если стек запоминали) и в случае необходимости бьёт в колокола. В целом мне это кажется рациональнее, чем писать анализатор кода.

Кстати, для минимальной защиты можно обойтись без этапа обучения. Скажем, прослойка проверяет все запросты на количество утверждений (не больше одного) и на наличие SQL-комментария. Довольно редко программисты используют несколько утверждений, разделённых точкой с запятой в одном вызове query(). Также нечасто используются и SQL-комментарии. В инъекциях наоборот эти штуки очень полезны. По крайней мере, Бобби Тейблз уже не сработает.
0
webportal #
Согласен! Но лучше расширить класс доступа к БД в 3 режима: рабочий класс, тестовый валидный, и тестовый с вариантами атаки… И в рабочем классе проверять валидность запроса…

Или другой вариант…
Использовать хранимые процедуры или функции…
–1
solomatin #
вы правы, система нужна там где нету возможности самому кодить и проверять свой кодинг )) напримре хостерам.
спасибо за комментарий!
0
hrukon #
Думаю такое средство будет весьма востребованным!
Можно поинтересоваться вкратце о технических деталях модуля? Используемые для разработки инструмент(ы)/веб-сервер/язык(и)/сервер(а) баз данных?
–1
braindamaged #
Какой-то суперкомпилятор SQL получается :)
Правильно ли я понимаю, что средство проводит только статический анализ по исходному коду? Распространяется ли защита на динамически собираемые запросы?
0
solomatin #
Нет, пока только по исходному коду. Работа пока еще на стадии формирования основных моментов.
0
igamity #
По исходному коду чего? Что собственно анализируется: полные запросы, которые встречаются в коде сайта или запросы, которые дошли до БД?
0
solomatin #
смотрим на запросы, которые встречаются в коде и сравниваем с тем, что дошло до БД.
+1
webportal #
А если запросы формируются как в Zend Frameworck??? Или как в CRMках??
–1
solomatin #
там это и не нужно
0
webportal #
Ну как не нужно вы видели как строятся запросы в зенде???
Например вот такую конструкцию поймёт ваша система??
$select = $db->select()
->from(array('p' => 'products'),
array('product_id', 'product_name'))
->join(array('l' => 'line_items'),
'p.product_id = l.product_id');

Или такой например????
$select = $db->select()
->from(array('p' => 'products'),
array('product_id'))
->join(array('l' => 'line_items'),
'p.product_id = l.product_id',
array('line_items_per_product' => 'COUNT(*)'))
->group('p.product_id')
->order(array('line_items_per_product DESC',
'product_id'));

Или вы предполагаете прокладку между интерпретатором кода и базой данных???

Если да то вы должны понимать какие это лаги…
Проще юнит тестирование проводить на возможность SQL иньекции
+1
igamity #
Если в коде будет что-то типа «insert into ». $table. " (`p1`, `p2`) values ('". $p1. "', '". $p1. "')" или еще чего похлеще, он будет обработан?
–1
solomatin #
На данном этапе разрабатывается программный модуль для подтверждения этого метода


Да, будет. :)
+1
igamity #
Понятно, это я заключение не внимательно прочитал ;) Спасибо!
0
webportal #
А допустим будет у вас модули для всех цмс… А на вариант самопала что придумаете??? Или для каждого варианта анализатор писать будете???
0
braindamaged #
Ясно, спасибо. Еще такой момент — это в рамках разработки Web-IDE и веб-платформы (т.е. привязано в основном к php)?

P.S. Приятно удивлен тем, что результаты ваших R&D позволяют реализовать инструменты, способные проводить такого рода анализ. Это круто :)
–1
shai_xylyd #
Супер, спасибо, это реально круто. Если я правильно понял это позволит повысить надежность уже существующих приложений, а следовательно сократит расходы.
+6
dieinzige #
Нет
Получится еще одна никому не нужна хе../вещь

0
solomatin #
такая изначальная задумка :)
0
kostyl #
думаю проще проверять входные данные, потому что надо будет потом еще защищать ту базу, где у вас будут храниться возможные комбинации динамических запросов )))
+5
develop7 #
чего только не делают люди, чтобы не использовать prepared statements.
+5
ksurent #
Чего только люди не придумают, чтобы не использовать встроенные в любую более-менее популярную библиотеку функции валидации данных (плейсхолдеры, DBI->quote, mysql_real_escape_string)…
+1
develop7 #
Квотинг это не то. Лень всё равно победит. А вот использование prepared statements (не факт, кстати, что это == плейсхолдерам) решает проблему в корне, потому что данные «подставляются в запрос» сервером БД.
+2
ksurent #
Да сам-то я в 99% использую как раз prepared statements (в перле, кстати, это == плейсхолдерам; в других языках не знаю). Но иногда все-таки приходится и DBI->quote юзать.
В любом случае, я бы никогда даже не подумал о такой навесной защите, вместо того, чтобы писать нормальный код.
+4
TimTowdy #
Сплошная вода.

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