Защита базы mysql

[Slastik]

Защита базы mysql

Добрый день.

Есть проект на связке php+mysql
В БД проекта находятся очень важные данные. Владельцы очень боятся что данные могут получить сторонние люди.
Соответственно вопрос, существует ли какие то программные средства или подходы к повышению защиты БД.

Понятно что в первую очередь нужно позаботиться о безопасном коде, но так как для проекта была использована open source система это может быть проблематично.
Так вот, возможно ли как-то помешать злоумышленникам слить данные из бд, даже при наличии каких-то уязвимостей вроде sql injection?
Владельцы говорят надо зашифровать БД. Но насколько я понимаю хакер все равно сможет вставить код аналогичный с запросами самого сайта и таким образом получить данные. Возможно я что-то упускаю.

Спасибо.

 

[fixxxer]

ну если код неизвестного происхождения, то mod_security в помощь, не панацея но большинство лбопытных леммингов остановит

шифровать - это бредовая затея, выводить же ты не шифрованные данные будешь

 

[VladimirZH]

А структуру БД возможно изменять? В данной ситуации один из выходов - усложнить структуру чтобы при взломе базы невозможно было установить связи между данными. Это по крайней мере предоставит хакерам несколько дней большого головняка.

 

[berkut]

Это по крайней мере предоставит хакерам несколько дней большого головняка.

и несколько недель головняка топикстартеру)

 

[vovanium]

В похожей ситуации личную инфу о клиентах (ФИО паспортные данные и т.п.) шифровал с помощью mcrypt/AES, хотя это защита больше не от хакеров, а от утечки базы, типа сократили админа, а он с собой базу на память унёс на новую работу. Плюс конечно закрытые исходники и привязка к домену/ip в самом софте.
Естественно если кто-то сильно захочет то достать данные сможет, но для этого нужно будет больше усилий, чем просто восстановить базу из бэкапа и посмотреть все данные в любом mysql-клиенте.
Что касается SQL-инъекций, то для этого достаточно юзать mysql_escape_string.

 

[Фанат]

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

 

[Alexandre]

хотя это защита больше не от хакеров, а от утечки базы, типа сократили админа, а он с собой базу на память унёс на новую работу

админ дурак - не сможет расшифровать? код-то открытый и ключи находятся минут за пять простым grep -r mcrypt *

Плюс конечно закрытые исходники и привязка к домену/ip в самом софте

ну если только закрыть ионкубом или енкодером
а так - кусок кода привязки находится еще минут за 20ть

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

у меня в одном проекте был такой алгоритм:
владелец БД для доступа к своему сегменту загружает свой приватный ключ
но это только частный случай...он для многих случаев не подходит

 

[fixxxer]

даже с енкодером найдется, сдампить байткод недолго

google: Vulnerability Discovery in Closed Source / Bytecode Encrypted PHP Applications Stefan Esser

 

[Alexandre]

даже с енкодером найдется, сдампить байткод недолг

согласен, но просто предется побольше попотеть

 

[vovanium]

Alexandre

админ дурак - не сможет расшифровать?

Во-первых, ты читать умеешь? Я написал:

если кто-то сильно захочет то достать данные сможет, но для этого нужно будет больше усилий

Где я писал о 100% защите?
Во-вторых, по-твоему админы корпоративных серваков поголовно на отлично разбираются в php, и в том числе в дезенде скриптов, дампе байткодов и т.п.?

В общем-то по-твоей логике замки на входные двери ставить не нужно, ведь их все равно за несколько минут откроет профи по этому делу.

 

[fixxxer]

vovanium
а теперь перечитай сообщение ТС

 

[vovanium]

fixxxer
А теперь перечитай моё сообщение Я писал что ситуация немного иная. Да и ТС указывал на то с sql инъекции один из вариантов, просто о моем варианте он не задумывался еще. Да и вообще он слабо представляет что такое инъекции.

Но насколько я понимаю хакер все равно сможет вставить код аналогичный с запросами самого сайта и таким образом получить данные.

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

 

[Slastik]

Автор оригинала: vovanium
fixxxer
А теперь перечитай моё сообщение Я писал что ситуация немного иная. Да и ТС указывал на то с sql инъекции один из вариантов, просто о моем варианте он не задумывался еще. Да и вообще он слабо представляет что такое инъекции.
Т.е. достаточно проверить все поступающие в запросы параметры. Ведь инъекции возможны, не из-за каких-то дырок в самом php или mysql, а из-за того что софт пишут всякие ламеры, которые не знают что все данные пришедшие из веба нужно проверять.

Каким образом я могу проверить все поступающие параметры в запросы, если запросы формируются и выполняются в очень большом количестве файлов, счет идет сотни-тысячи
?

 

[Фанат]

откуда столько файлов?

 

[vovanium]

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

 

[Slastik]

Автор оригинала: Slastik
Каким образом я могу проверить все поступающие параметры в запросы, если запросы формируются и выполняются в очень большом количестве файлов, счет идет сотни-тысячи
?

Большая система, и очень много модулей. порядка 100-150

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

Практически в каждом, система кривая, запросы не собраны в одном месте. Это весьма твердолобый метод, запросы могут строиться по разному, модули писали самые разные люди, там полная каша, да и в любом случае можно что-то упустить. Кроме того возможны и другие уязвимости помимо sql инъекций, их подобным образом не вычислишь.

Хотелось бы иметь какой то механизм дающий повышенную безопасность при предположении что уязвимости таки могут быть.

Интересно почему разработчики open source систем не следуют такому простому, "гениальному" совету и выпускают sql-injection уязвимые системы...

 

[zerkms]

Интересно почему разработчики open source систем не следуют такому простому, "гениальному" совету и выпускают sql-injection уязвимые системы...

как связана открытость кода систем и адекватность разработчиков?

 

[Alexandre]

Интересно почему разработчики open source систем не следуют такому простому, "гениальному" совету и выпускают sql-injection уязвимые системы...

интересно, почему разработчики коммерческих систем выбирают кривые опен-соурсные разработки?

 

[vovanium]

Хотелось бы иметь какой то механизм дающий повышенную безопасность при предположении что уязвимости таки могут быть

Ну так многим бы хотелось иметь одну таблетку от всех болезней
В твоем случае замый безопасный, это не подключать сервак к инету, тогда точно никаких инъекций не будет

Интересно почему разработчики open source систем не следуют такому простому, "гениальному" совету и выпускают sql-injection уязвимые системы

Потому что в большинстве своем такие проекты пишут новички, которые хотят потренироваться в написании софта.

 

[Alexandre]

Практически в каждом, система кривая, запросы не собраны в одном месте. Это весьма твердолобый метод, запросы могут строиться по разному, модули писали самые разные люди, там полная каша, да и в любом случае можно что-то упустить. Кроме того возможны и другие уязвимости помимо sql инъекций, их подобным образом не вычислишь.

1) - запросы и не должны быть собраны в одном месте
во всем должна быть логика и система
2) что тебе мешает найти каждый запрос и проверить - есть ли в этом месте защита на инъекции
3) третье правило Ламера - вали все на предшедствующих разработчиков
4) вычислить уязвимости можно практически все известные, необходимо только немного усилий и времени, ну и знаний