Защита базы mysql

Slastik

Новичок
Автор оригинала: Alexandre
1) - запросы и не должны быть собраны в одном месте
во всем должна быть логика и система
2) что тебе мешает найти каждый запрос и проверить - есть ли в этом месте защита на инъекции
3) третье правило Ламера - вали все на предшедствующих разработчиков
4) вычислить уязвимости можно практически все известные, необходимо только немного усилий и времени, ну и знаний
1. Речь о том что логики и системы там как раз мало, там даже mvc схемы нет.
3. Что за правила ламера?
2,4. И все же учитывая подход к разработке, уровень разработчиков, систему выбранную для сайта, найти все уязвимости в данном случае практически не реально, кроме того периодически появляются новые.
В целом задачу можно свести к защите всего одной таблицы с данными. Интересны подходы к шифрованию одной таблицы с данными, как это можно реализовать...
 

vovanium

Новичок
как это можно реализовать
Мне вот интересно ты что ожидаешь что кто-то тебе выложит класс типа SuperMegaAntiHackerDefence, который одним идклюдом в любом месте твоего дырявого скрипта, сразу сделает его мегазащищенным от любых взломов?
 

Slastik

Новичок
Автор оригинала: vovanium
Мне вот интересно ты что ожидаешь что кто-то тебе выложит класс типа SuperMegaAntiHackerDefence, который одним идклюдом в любом месте твоего дырявого скрипта, сразу сделает его мегазащищенным от любых взломов?
Нет. Я такого не писал.
 

vovanium

Новичок
Нет. Я такого не писал.
Что-то не похоже. Тебе уже много раз сказали, что чтобы не было инъекций, нужно проверять всё, что пришло от пользователя. Одной строкой тут не обойдешься, т.к. нужно знать какой контент ожидается.
Например, ты ожидаешь от юзера id и в запрос тупо без всяких проверок пишешь ...WHERE id = {$_GET['id']}, но ничто не мешает юзеру ввести к пример "12 OR 1=1", таким образом под условие уже попадают все записи. Вот поэтому нужно проверять каждую переменную на соответствие ожидаемому вводу...
Если у тебя конфиденциальные данные только в одной таблице, то и начни с проверки запросов к ней.
 

Slastik

Новичок
Автор оригинала: vovanium
Что-то не похоже. Тебе уже много раз сказали, что чтобы не было инъекций, нужно проверять всё, что пришло от пользователя. Одной строкой тут не обойдешься, т.к. нужно знать какой контент ожидается.
Например, ты ожидаешь от юзера id и в запрос тупо без всяких проверок пишешь ...WHERE id = {$_GET['id']}, но ничто не мешает юзеру ввести к пример "12 OR 1=1", таким образом под условие уже попадают все записи. Вот поэтому нужно проверять каждую переменную на соответствие ожидаемому вводу...
Если у тебя конфиденциальные данные только в одной таблице, то и начни с проверки запросов к ней.
Я неплохо знаю что такое sql инъекция. Про какую-то "одну строку" я не писал.

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

Защита строится из нескольких этапов
1. Написание надежного кода устойчивого к атакам.
2. ...

Никогда нельзя быть уверенным что на этапе 1 код действительно получится 100% надежный.
Вопрос состоит в том что можно сделать чтобы усложнить жизнь тем кто таки найдет уязвимость, любую, позволяющую вытащить секретные данные.

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

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


p.s. zerkms, Alexandre
Интересно почему разработчики open source систем не следуют такому простому, "гениальному" совету и выпускают sql-injection уязвимые системы...
Эта фраза была лишней с моей стороны, не имеющая отношения к основному вопросу, поэтому не стал продолжать обсуждение по этому вопросу.
 

vovanium

Новичок
код действительно получится 100% надежный
Начнем с того что 100% надежной защиты не бывает.
Для шифрования данных есть mcrypt, для дополнительной защиты ключа, закодирой скрипты zend'ом или чем-то аналогичным.
 

Slastik

Новичок
Автор оригинала: vovanium
Начнем с того что 100% надежной защиты не бывает.
Я так и написал что не бывает.

Нагуглил такую штуку http://www.greensql.net/about
Прокси между веб сервером и БД сервером. Фильтрует потенциально опасные sql запросы, кто-то пробовал?
 

Фанат

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

Другое дело, что спрашивать, пробовал ли сие поделие здесь кто-нибудь - это оскорбление.
 

zerkms

TDD infected
Команда форума
*****
кстати слышал наоборот, довольно лестные отзывы о т.н. application firewall.
к классу которых greensql относится. не знаю насколько он качественен, но вообще подобные вещи делают своё дело.

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

Фанат

oncle terrible
Команда форума
Я не знаю, что такое application firewall, но знаю, что при наличии минимально прямых рук конкретно эта поделка просто не нужна
 

zerkms

TDD infected
Команда форума
угу, думаю абсолютно аналогично.
но некоторые знакомые гуры пророчат им неплохое будущее :)
 

prolis

Новичок
ну отлупит он(она) ' or 1=1', а вот ' or id>0' - уже замучается, и в правилах этого не окажется
 

weregod

unserializer
> or 1=1
сам мускуль оптимизирует, application firewall как бэ не для оптимизации нужен, я так понимаю
 

gray07

Новичок
Ключевой момент в защите это защита нескольких столбцов в одной таблице.
Угроза - утечка данных, либо через хакерские действие либо через админов.
Если к этим столбцам будет обращатся ваш код, а не гора чужого, можно использовать разделение прав в mysql - чужой код коннектится под одним логином, ваш - под другим. В mysql можно выставлять права вплоть до полей, и через чужие sql инъекции злоумышленник не доберется до данных. От админа естественно так не защитишься.
 
Сверху