В статье "Protecting your MySQL database from SQL injection attacks with GreenSQL (http://www.linux.com/feature/145341)" рассмотрен процесс установки GreenSQL (http://www.greensql.net/), позволяющего защитить MySQL от атак, направленных на подстановку SQL запросов. В отличии от mod_security (http://www.modsecurity.org/), реализующего подобную защиту на уровне проверки запросов к http-серверу, GreenSQL представляет собой прокси сервер, непосредственно анализирующий транзитные запросы, выявляющий аномалии и блокирующий опасные операции.
Для каждого запроса GreenSQL вычисляет степень риска, при превышении определенного порога запрос блокируется. В качестве фактов повышающих коэффициент риска, может быть обращение к служебным таблицам, использование комментариев внутри запроса, операции сравнения констант ("1=1"), наличие выражений заведомо возвращающих TRUE, обнуление полей с паролем, появление "OR" внутри запроса и т.д.
Программа позволяет (http://www.greensql.net/about) опреде...URL: http://www.greensql.net/
Новость: http://www.opennet.me/opennews/art.shtml?num=17558
Интересное решение, а для postgresql есть подобное?
автор пишет, что
PostgreSQL version is in my TODO list.
It will be released sooner or later.
отлично. Дождёмся наступления этого "sooner" или "later".
1=1 зря.
во изврааатт... следующим этапом будет Bayesian прикручен наверно))
и юзеры будут апрувить хорошие и плохие запросы)bzzrrrr@fatbastard.ath.cx
>> 1=1 зря.SQL-бэкдор хочешь оставить в родной конторе на случай ухода? )))
>>> 1=1 зря.
>
>SQL-бэкдор хочешь оставить в родной конторе на случай ухода? )))А можно для общего развития разъяснить суть этой уязвимости?
Я пока не достиг достаточного уровня просветления в таких вещах, как sql-injection, но насколько я понимаю, если есть конструкция вида "условие1 and параметр1 = x", где х вводится пользователем, то можно вместо "x" вставить " x or 1=1", а конструкция "условие1 and параметр1 = x or 1=1" всегда равна true... Я конечно понимаю, что много таким образом не вытащишь, да и проверок можно навставлять. А вот необходимость для реальных запросов конструкции 1=1 мне как раз кажется сомнительной...
>Я пока не достиг достаточного уровня просветления в таких вещах, как sql-injection,
>но насколько я понимаю, если есть конструкция вида "условие1 and параметр1
>= x", где х вводится пользователем, то можно вместо "x" вставить
>" x or 1=1", а конструкция "условие1 and параметр1 = x
>or 1=1" всегда равна true... Я конечно понимаю, что много таким
>образом не вытащишь, да и проверок можно навставлять. А вот необходимость
>для реальных запросов конструкции 1=1 мне как раз кажется сомнительной...w = "select .. from ... where ";
for ( i = 0; i < 10; i++) {
if ( i != 0) w .= " AND ";
w .= " field${i}=$i";
}а теперь представьте, что в некоем макроязыке нет циклов
Я так понимаю, у вас есть массив, в котором есть сколько-то значений, и надо скриптом сделать запрос, который вытащит строки с этими значениями? Не могу пока ничего сказть, как сделать это без цикла...
Хотя, наверное, GreenSQL поддается тонкой настройке?
>>> 1=1 зря.
>
>SQL-бэкдор хочешь оставить в родной конторе на случай ухода? )))иногда без конструкций, подобной 1=1 никак.
макроязык-надстройка над mySQL-интерфейсом некой программы с очень ограниченными возможностями по конструированию запросов...
а как по поводу:
'Вася'='Вася'
или
'Вася' like '%я%'
?true вернуть может не только 1=1
Это - константные выражения. Теоретически можно зарубить их всех.
а вот "id IS NOT NULL" выглядит более невинно.
да. константные.
а теперь добавим сюда хранимые функции,...... , функции дат...на этом фоне 1=1 - детский лепет.
о чём и сказал.
Имхо достаточно использовать параметризованные запросы (чтоб не допустить инъекции) и защиту от несанкционированного доступа типа такой:proc authorizer {args} {
set dbname [lindex $args 3]
set code [lindex $args 0]
set action [lindex $args 1]if { $dbname eq {merch} && [lin {SQLITE_DELETE SQLITE_INSERT SQLITE_READ SQLITE_SELECT SQLITE_UPDATE} $code] == 1 } {
return SQLITE_OK
}
if { $dbname eq {audit} && [lin {SQLITE_INSERT SQLITE_READ SQLITE_SELECT} $code] == 1 } {
return SQLITE_OK
}
return SQLITE_DENY
}P.S. Код рабочий, взят из проекта на эскулайт.
>Имхо достаточно использовать параметризованные запросы (чтоб не допустить инъекции) и защиту от
>несанкционированного доступа типа такой:
>proc authorizer {args} {
> set dbname [lindex $args 3]
> set code [lindex $args 0]
> set action [lindex $args 1]что такое action ? или не важно?
>[оверквотинг удален]
> return SQLITE_OK
> }
> if { $dbname eq {audit} && [lin {SQLITE_INSERT
>SQLITE_READ SQLITE_SELECT} $code] == 1 } {
> return SQLITE_OK
> }
> return SQLITE_DENY
>}
>
>P.S. Код рабочий, взят из проекта на эскулайт.погодите, забавно. а что, SQLITE сама не умеет пермишены на отдельные операции/таблицы/строки делать?
респект за тисиэль! :)
Аргументы авторайзера такие:
** (1) The authorization type (ex: SQLITE_CREATE_TABLE, SQLITE_INSERT, ...)
** (2) First descriptive name (depends on authorization type)
** (3) Second descriptive name
** (4) Name of the database (ex: "main", "temp")
** (5) Name of trigger that is doing the accessА вот пример передаваемых аргументов:
SQLITE_READ sqlite_master rootpage main {}
SQLITE_INSERT sqlite_master {} main {}
SQLITE_CREATE_TABLE test {} main {}
SQLITE_UPDATE sqlite_master type main {}
SQLITE_UPDATE sqlite_master name main {}А зачем эскулайту заниматься разграничением доступа? Это дело приложения, а не встраиваемой библиотеки. Эскулайт предоставляет механизм для _контроля_ доступа, а как разграничивать доступ (и разграничивать ли вообще) - решает разработчик. Зато механизмы контроля очень гибкие - кроме вышеописанного, есть контроль изменения данных, коммита/отката транзакции и т.д. В десктопных приложения названные возможности обычно не требуются, а вот для многопользовательских серверов они очень удобны и гибки.
На чем же и писать крупные проекты, как не на тикле :-) Дело вкуса, сами понимаете, и кто-то пишет на лиспе, или на схеме.
>А зачем эскулайту заниматься разграничением доступа? Это дело приложения, а не встраиваемой
>библиотеки.я бы поспорил, ну да ладно.
>На чем же и писать крупные проекты, как не на тикле :-)
>Дело вкуса, сами понимаете, и кто-то пишет на лиспе, или на
>схеме.язык - это дело вкуса ведущего разработчика, конечно. но привязывать свой "крупный проект" к SQLITE - это как-то... ну в общем, я бы не стал.
А как насчет ситуации, когда вы _лично_ несете финансовую ответственность за проект? Раньше работал с постгресом, но адаптировать его код намного сложнее, притом производительность постгреса существенно хуже. Для необслуживаемого сервера эскулайт оказывается к тому же намного надежнее (клиент-серверные СУБД без присмотра под нагрузкой начинают вести себя непредсказуемо, все же им приходится регулярно параметры настройки подкручивать, зомбиков пришибать и проч.) Начинал делать большие проекты на эскулайт с того, что один из проектов на постгресе с базой 20 гиг с чем-то перенес на эскулайт - скорость работы хорошо оптимизированного проекта на эскулайт оказалась выше скорости работы хорошо оптимизированного проекта на постгресе в 60 раз, нетрудно догадаться, что на продакшене давно уже работает именно эскулайт версия (архитектура проектов отличается, т.к. в постгресе использовалась единственная база, а в эскулайте набор из десятка баз, но модуль dblink для связки нескольких баз в постгресе для продакшена не годится, а в эскулайт объединение баз выполняется встроенной командой attach, которая работает очень эффективно). Планировщик запроса в эскулайт работает замечательно, за исключением некоторых исключительных случаев, а при нахождении багов можно рассчитывать на их устранение в течении нескольких часов или дней.Эскулайт часто используется в критичных приложениях, скажем, система авторизации 10-й или 11-й солярки на эскулайт сделана и много других примеров. Тиклевский биндинг к эскулайт, кстати, защищает от sql-инъекций (все запросы автоматически подготавливает как prepared).
Код эскулайт в паблик домене - можно делать с ним все что угодно. Часть своих модулей к эскулайт я выкладываю, но моя версия эскулайт для отдельного проекта может содержать и те модули, которые публиковать не планирую, и лицензия эскулайт это позволяет без каких-либо ограничений.
>А как насчет ситуации, когда вы _лично_ несете финансовую ответственность за проект?
>Раньше работал с постгресом, но адаптировать его код намного сложнее, притом
>производительность постгреса существенно хуже.то, что с постгресом могут быть траблы производительности по сравнению с аналогичными структурами, хранящимися в, нампример мускуле - я в курсе.
> Для необслуживаемого сервера эскулайт оказывается к тому
>же намного надежнее (клиент-серверные СУБД без присмотра под нагрузкой начинают вести
>себя непредсказуемо, все же им приходится регулярно параметры настройки подкручивать, зомбиков
>пришибать и проч.)ну как-то надо разделить обязанности с кем-то. вы - программист и руководитель, а кто-то - администратор БД. и чтобы ваш коллега денно и нощно решал не ваши проблемы. а вы - денно и нощно работали над оптимизацией своей части проекта.
я все-таки политически против привязки к конкретной БД.
Дело не в распределении обязанностей, а в отсутствии доступа к серверу. Необслуживаемый сервер стоит в интранете и доступ возможен только из офиса заказчика. Так что получить доступ к такому серверу это отдельная история (заказчик может находиться за тысячи километров от нас...). Дебиан+аолсервер+тикль+эскулайт с автономной работой справляются, доступ требуется только чтобы установить новую версию системы.
Да, насчет отсутствия привязки к СУБД - вы готовы гарантировать корректную работу _для нескольких_ СУБД? Если будет заявлена возможность работы с несколькими СУБД, заказчик вправе использовать любую из них, но все проблемы должен решать разработчик ПО (будь то перегрузка при тысячах одновременных пользователей, sql-инъекция, сбой СУБД или любых других). Кстати, 99% тестового покрытия исходного кода я не видел более ни у одной СУБД. А уж найти встраиваемую СУБД, способную работать с десятками и сотнями гигабайт данных, имеющую поддержку sql, многопоточные биндинги практически ко всем языкам и отличный планировщик... Так что альтернатив просто не знаю. Постгрес ранее был выбран за надежность и себя оправдал (много лет эксплуатации на самом разном железе, пока физические диски и ФС целы, все данные в сохранности), но на больших объемах данных и высокой нагрузке в автономном режиме не годится, это совершенно другой класс задач. А других открытых СУБД сопоставимого качества не встречал (имеются в виду, с поддержкой sql, а так есть токиокабинет и некоторые другие, наподобии берклидб, но последняя требует некоторого администрирования на этапе установки), даже если рассматривать все классы СУБД, в т.ч. общего назначения и встраиваемые.
интересный ответ, спасибо!
а насчет ГринЭскуэль... я считаю, необходимы расширенные правила для доступа к данным, встроенные прямо в MySQL: чтобы автоматически срубать длинный запрос, запрещать полную выборку по всей таблице и тд.
никаким прокси странными правилами фильтрации по тексту запроса этого не достичь.
Согласен. Прокси работает _вне_ движка, потому имеет контроль не более того, что способно сделать само приложение. А сложные правила текстовой фильтрации только будут приводить к появлению ошибок и уязвимостей - администратор системы считает, что он сделал дополнительную защиту для коррекции ошибок разработчика, а разработчик считает, что все равно админ заблокирует опасные запросы и можно особо не беспокоиться о безопасности. Защищать надо в двух местах - где лежит бизнес-логика и данные, то есть на уровне приложения и на уровне движка, но не между ними (на уровне протокола передачи требуется лишь предотвратить несанкционированный доступ и искажение информации).
Скажите как сделать веб интерфейс, я загрузил все сделал и поставил, как сделать чтобы открывалась через браузер, может кто нибудь написать ?