GreenSQL 1.2 — firewall для СУБД MySQL и PostgreSQL

image

Теги: СУБД, MySQL, PostgreSQL

Представлен новый релиз Open Source-средства обеспечения безопасности для систем управления базами данных (СУБД) — GreenSQL 1.2.

Представлен новый релиз Open Source-средства обеспечения безопасности для систем управления базами данных (СУБД) — GreenSQL 1.2.

GreenSQL выступает в качестве дополнительной прослойки между Web-приложениями и СУБД, собирая/анализируя/запрещая SQL-запросы, приходящие к серверу баз данных. GreenSQL оценивает SQL-команды на их потенциальную опасность и может выполнять различные действия в зависимости от результатов этого анализа. Программа поддерживает четыре режима работы: симуляция, блокирование подозрительных команд, обучение, активная защита для неизвестных запросов.

GreenSQL поддерживает две СУБД: MySQL и PostgreSQL, причем поддержка последней появилась в недавнем релизе 1.2. Кроме того, в релизе представлен новый графический интерфейс управления программой. GreenSQL распространяется под лицензией GNU GPLv2.


или введите имя

CAPTCHA
Страницы: 1  2  
76292
07-12-2009 10:35:48
Решето!!1
0 |
07-12-2009 11:09:18
Обоснуй, пожалуйста.
0 |
фетиш-мастер [Малиновые штаны]
07-12-2009 15:07:27
Обоснуй, пожалуйста.вместо того, чтобы бороться с sql-инъекциями на уровне построения запросов, этот фарш представляет собой всего лишь фильтр, отсеивающий "небезопасные" запросы что-то он, несомненно, отсеит, но в целом дыры - останутся: отсеит он sql, содержащий что-то вроде ' OR 1=1 #--.*$ или запросы, содержащие UNION-ы но join-инъекции фильтрануть не так-то легко по сути, этот инструмент отсеит только не особо сообразительных киддисов
0 |
Pers
07-12-2009 16:24:55
Если дело дойдёт до взлома Web-приложения, то грамотно настроенный GreenSQL осложнит выполнение деструктивных задач. Особенно если бизнес-логика вынесена в хранимые процедуры.
0 |
фетиш-мастер [Малиновые штаны]
08-12-2009 10:16:14
в общем-то эту мысль я и озвучил а насчет хранимых процедур - если они есть, то этот костыль GreenSQL не нужен достаточно просто использовать плейсхолдеры для построения запроса и никакие инъекции вам не страшны люди, пихающие пусть и обработанные данные в тело SQL-запроса - лохи и не достойны называца программерами
0 |
Дутый
08-12-2009 11:09:04
Лучше грамотно настроить MySQL или PgSQL, чем ставить какую-то левую прослойку что бы система тормозила еще больше. Не храните пароли в открытом виде в базах - даже если их кто и прочтет через иньекцию - то толку будет мало.
0 |
фетиш-мастер [Малиновые штаны]
08-12-2009 12:39:01
здесь речь немножко о другом sql-инъекциям нacpaть на настройки и способы хранения пароля
0 |
HL
07-12-2009 17:31:26
Бизнес-логика в хранимых процедурах - полный сакс с точки зрения управления исходным кодом, автоматизированного тестирования и целостности приложения (чтобы какой-нибудь баклан не запустил код версии X работать с базой версии Y). Конечно, есть некие плюсы в этом, особенно для маленьких проектов. Но для больших лучше избегать такого геморра. К тому же SQL-инъекции на 90% отсеиваются использованием ORM-фреймворков. Например, покажите мне, как сделать SQL-инъекциию на LINQ
0 |
Sw%00p aka Jerom
07-12-2009 19:08:29
а что WHERE id='.mysql_real_escape_string($id).' составляет труда ??? и всякие там фаерволы от инъекций это защита для дураков а если дураки пишут ПО то извините меня вопрос не ко мне вопрос: можно ли написать ПО без скул инъекци ??? ответ: ДА ДА ДА и ещё раз ДА надо просто намотать на ус что надо всегда фильтровать входящие (ну и параноя исходящие) данные
0 |
фетиш-мастер [Малиновые штаны]
08-12-2009 10:22:42
ну и параноя исходящие вывод тоже нужно фильтровать по той простой причине, что можно залететь на XSS в идеале, имхо, все слои - вредставления, контроллеры, фарш из объектной библиотеки и т.д. - должны фильтровать получаемые данные вне зависимости от того, откуда они приходят. а вьюхи еще и свой вывод.
0 |
07-12-2009 19:56:39
Казалось бы, причем тут хохлосрач?
0 |
08-12-2009 13:41:37
уфты, еще один waf:))
0 |
Страницы: 1  2