Security Lab



Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти  
Форум » Взлом и защита » Web приложения
Страницы: 1
RSS
Web пользователь и SQL сервер
 
#1
Это нравится:0Да/0Нет
30.07.2003 13:09:50
Есть 2 задачи:

1. Назначение минимальных прав на базу. Нужно определить все возможные операторы, которые использует Web сайт на базе, и ограничить доступ к базе только этими операторами. Часть запросов выполняется в ASP, а часть сохраненными процедрурами. Хотелось бы полностью обезопасить себя от проблем с SQL иньекцией.

2. Разрешать выполнение только определенных SQL запросов (или хотябы регистрировать запросы, которые я не разрешал). Я знаю что такая фича есть у ORALCE - например SELECT * from TABLE выполнять можно, а SELECT * from TABLE where ID=xxx уже нельзя. Соответственно вопрос - можно ли это сделать стандартными средствами SQL сервера и есть ли сторонние продукты. Это нужно для того, если SQL иньекция уже прошла, я мог бы сразу определить что выполняется SQL запрос, который я не разрешал.
Хочешь быть мудрым? Не желай всего, что видишь; не верь всему, что слышишь; не говори всего, что знаешь; не делай всего, что умеешь, а только то, что полезно.
 
 
 
#2
Это нравится:0Да/0Нет
30.07.2003 13:20:11
Цитата
Pig killer пишет:
Есть 2 задачи:
Вот так сразу, с места и в карьер... хорошо...

Цитата
Pig killer пишет:
1. Назначение минимальных прав на базу. Нужно определить все возможные операторы, которые использует Web сайт на базе, и ограничить доступ к базе только этими операторами. Часть запросов выполняется в ASP, а часть сохраненными процедрурами. Хотелось бы полностью обезопасить себя от проблем с SQL иньекцией.
Нужно исключить любое появление прямого transact-SQL кода в ASP. Всю работу треба выполнять через stored procedures / stored functions. 90% всяческих проблем с SQL Injection решаются именно так.
Второе -- строгий контроль типов передаваемых параметров, где первым этапом пойдут, например, regexp-ы, а вторым -- сам интерпертатор ASP-скрипта при вызове ADO-шных функций вида ADODB.Command.Paramaters("@param").Value;

Цитата
Pig killer пишет:
2. Разрешать выполнение только определенных SQL запросов (или хотябы регистрировать запросы, которые я не разрешал). Я знаю что такая фича есть у ORALCE - например SELECT * from TABLE выполнять можно, а SELECT * from TABLE where ID=xxx уже нельзя. Соответственно вопрос - можно ли это сделать стандартными средствами SQL сервера и есть ли сторонние продукты. Это нужно для того, если SQL иньекция уже прошла, я мог бы сразу определить что выполняется SQL запрос, который я не разрешал.
Это делается разграничением доступа на таблицы, например можно запретить юзеру, производящему логин в "ADODB.Connection" SELECT,UPDATE,etc-команды, а вся работа, как я и сказал, будет в sql stored procedure, где это имя пользователя уже не требуется для выполнения SQL-запроса.
Насколько мне известно, у MSSQL минимальная частичка, на которую можно поставить permissions -- это transact-SQL-команда, на отдельные части её прав установить нельзя.

Внутрях SQL-процедур не рекомендуется использовать EXEC
 
 
 
#3
Это нравится:0Да/0Нет
30.07.2003 13:26:42
Цитата
[TSS пишет:
] Нужно исключить любое появление прямого transact-SQL кода в ASP. Всю работу треба выполнять через stored procedures / stored functions. 90% всяческих проблем с SQL Injection решаются именно так.
Второе -- строгий контроль типов передаваемых параметров, где первым этапом пойдут, например, regexp-ы, а вторым -- сам интерпертатор ASP-скрипта при вызове ADO-шных функций вида ADODB.Command.Paramaters("@param").Value;
Задача ставиться не так. У меня есть чужой код который я не писал, и который я не хочу менять. Поэтому стоит задача - назначить минимально возможные права на базу.
Цитата
[TSS пишет:
]
Это делается разграничением доступа на таблицы, например можно запретить юзеру, производящему логин в "ADODB.Connection" SELECT,UPDATE,etc-команды, а вся работа, как я и сказал, будет в sql stored procedure, где это имя пользователя уже не требуется для выполнения SQL-запроса.
Насколько мне известно, у MSSQL минимальная частичка, на которую можно поставить permissions -- это transact-SQL-команда, на отдельные части её прав установить нельзя.

Внутрях SQL-процедур не рекомендуется использовать EXEC
Опять же задаче не защитится от SQL иньекции, а определить момент когда она прошла и быстро на него среагировать.
Хочешь быть мудрым? Не желай всего, что видишь; не верь всему, что слышишь; не говори всего, что знаешь; не делай всего, что умеешь, а только то, что полезно.
 
 
 
#4
Это нравится:0Да/0Нет
30.07.2003 13:29:55
Мне не нужно защитится от SQL иньекции, мне нужно определить что она прошла и как можно изначально уменьшить ее последствия не правя ASP кода.

Пермишены можно методом проб устанавливать в ручную, но это долго и не эффективно.
Хочешь быть мудрым? Не желай всего, что видишь; не верь всему, что слышишь; не говори всего, что знаешь; не делай всего, что умеешь, а только то, что полезно.
 
 
 
#5
Это нравится:0Да/0Нет
30.07.2003 13:33:47
Цитата
Pig killer пишет:

Задача ставиться не так. У меня есть чужой код который я не писал, и который я не хочу менять. Поэтому стоит задача - назначить минимально возможные права на базу.
Тогда мой ответ. Если в тексте ASP есть код, хотя бы теоретически подверженный SQL Injection, то без изменения кода ASP защитится от инъекции не получится никак. Как минимум, нужно определить самые слабые участки кода и "затрагиваемые" этим кодом таблицы базы защитить по-максимуму.

Цитата
Pig killer пишет:

Опять же задаче не защитится от SQL иньекции, а определить момент когда она прошла и быстро на него среагировать.
А как определить момент инъекции ?
Если не было каких-либо протестов со стороны системы безопасности сервера, то как понять, что выполненные код был "плохим" ? Если же были "протесты" -- значит инъекция не прошла, а SQL-ник вроде ведет лог подобных ошибок.
Можно, конечно, часами разглядывать лог tracer-а (SQL Profiler)...
 
 
 
#6
Это нравится:0Да/0Нет
30.07.2003 13:36:07
Цитата
Pig killer пишет:
Мне не нужно защитится от SQL иньекции, мне нужно определить что она прошла и как можно изначально уменьшить ее последствия не правя ASP кода.
ИМХО ты не найдешь автоматической системы, которая бы тебе хотя бы на 80% сказала, что выполненые на стороне SQL-сервера код есть SQL Injection, а не нормальные команды.

Кста, выход мне видится такой: можно поюзать fake-базу, а в основную все переносить триггерами.
 
 
 
#7
Это нравится:0Да/0Нет
30.07.2003 13:36:18
Можно изначально прописать разрешенные SQL запросы, и если прошел SQL запрос, который не был определен заранее, то предупредить об этом администратора. Такую фичу можно сделать в ORACLE (скоро будет статья по этому поводу)
Хочешь быть мудрым? Не желай всего, что видишь; не верь всему, что слышишь; не говори всего, что знаешь; не делай всего, что умеешь, а только то, что полезно.
 
 
 
#8
Это нравится:0Да/0Нет
30.07.2003 13:37:28
Цитата
[TSS пишет:
]ИМХО ты не найдешь автоматической системы, которая бы тебе хотя бы на 80% сказала, что выполненые на стороне SQL-сервера код есть SQL Injection, а не нормальные команды.

Для ORALCE такая система есть. Я думаю что есть и для SQL сервера. Может в виде отдельного продукта.
Хочешь быть мудрым? Не желай всего, что видишь; не верь всему, что слышишь; не говори всего, что знаешь; не делай всего, что умеешь, а только то, что полезно.
 
 
 
#9
Это нравится:0Да/0Нет
30.07.2003 13:59:52
Можно поизвращатся:
Используя SQL server Profiler писать все SELECT запросы в базу а потом считывать базу клиентом и искать нужные строки, но ресурсоемко это:(
 
 
 
#10
Это нравится:0Да/0Нет
30.07.2003 14:51:02
Насколько я помню, можно для ODBC коннекшена поставить галочку чтобы он все свои действия писал в лог. Назначить в качестве лога пайп к самодельному парсеру запросов и настроить свои собственные правила определения была ли SQLInjection или нет.

;---------
;NK
 
 
 
#11
Это нравится:0Да/0Нет
30.07.2003 15:42:07
2 __NK
на худой конец это снифером делать можно, но итресуют, как я понял, именно средства MSSQL без написания собственных программ
 
 
 
#12
Это нравится:0Да/0Нет
30.07.2003 23:03:02
Цитата
__NK пишет:
Насколько я помню, можно для ODBC коннекшена поставить галочку чтобы он все свои действия писал в лог. Назначить в качестве лога пайп к самодельному парсеру запросов и настроить свои собственные правила определения была ли SQLInjection или нет.

;---------
;NK
Можно, только во первых чем анализировать эти логи, а во вторых, я ODBC не использую...
Хочешь быть мудрым? Не желай всего, что видишь; не верь всему, что слышишь; не говори всего, что знаешь; не делай всего, что умеешь, а только то, что полезно.
 
 
 
#13
Это нравится:0Да/0Нет
30.07.2003 23:04:04
Цитата
TeckLord пишет:
2 __NK
на худой конец это снифером делать можно, но итресуют, как я понял, именно средства MSSQL без написания собственных программ

Тоже можно, только мне нужно универсальное решение - настроил и забыл. А со сниффером геморой еще тот...
Хочешь быть мудрым? Не желай всего, что видишь; не верь всему, что слышишь; не говори всего, что знаешь; не делай всего, что умеешь, а только то, что полезно.
 
 
 
#14
Это нравится:0Да/0Нет
31.07.2003 01:17:06
Может поможет специально написаный для этой цели ISAPI фильтр? Можно будет обрабатывать запросы на предмет инъекции и реагировать соответствующим образом. Баггзи вот упоминал уже такую вещь.
 
 
 
#15
Это нравится:0Да/0Нет
01.08.2003 04:42:22
такая вещь на ксакеп ру стоит :) ключевые слова коверкает, иничего сложнее ' or ''=' не заюзаешь
 
 
 
Страницы: 1
Читают тему