https://www.opennet.me/openforum/vsluhforumID3/43514.html В статье "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 представляет собой прокси сервер, непосредственно анализирующий транзитные запросы, выявляющий аномалии и блокирующий опасные операции. <br><br><br>Для каждого запроса GreenSQL вычисляет степень риска, при превышении определенного порога запрос блокируется. В качестве фактов повышающих коэффициент риска, может быть обращение к служебным таблицам, использование комментариев внутри запроса, операции сравнения констант ("1=1"), наличие выражений заведомо возвращающих TRUE, обнуление полей с паролем, появление "OR" внутри запроса и т.д. <br><br><br>Программа позволяет (http://www.greensql.net/about) опреде...<br><br>URL: http://www.gre https://www.opennet.me/openforum/vsluhforumID3/43514.html#32 Sun, 21 Mar 2010 16:00:39 GMT Скажите как сделать веб интерфейс, я загрузил все сделал и поставил, как сделать чтобы открывалась через браузер, может кто нибудь написать ?<br> https://www.opennet.me/openforum/vsluhforumID3/43514.html#31 Fri, 29 Aug 2008 11:34:42 GMT Согласен. Прокси работает _вне_ движка, потому имеет контроль не более того, что способно сделать само приложение. А сложные правила текстовой фильтрации только будут приводить к появлению ошибок и уязвимостей - администратор системы считает, что он сделал дополнительную защиту для коррекции ошибок разработчика, а разработчик считает, что все равно админ заблокирует опасные запросы и можно особо не беспокоиться о безопасности. Защищать надо в двух местах - где лежит бизнес-логика и данные, то есть на уровне приложения и на уровне движка, но не между ними (на уровне протокола передачи требуется лишь предотвратить несанкционированный доступ и искажение информации).<br> https://www.opennet.me/openforum/vsluhforumID3/43514.html#30 Fri, 29 Aug 2008 10:54:24 GMT интересный ответ, спасибо!<br>а насчет ГринЭскуэль... я считаю, необходимы расширенные правила для доступа к данным, встроенные прямо в MySQL: чтобы автоматически срубать длинный запрос, запрещать полную выборку по всей таблице и тд.<br>никаким прокси странными правилами фильтрации по тексту запроса этого не достичь.<br> https://www.opennet.me/openforum/vsluhforumID3/43514.html#29 Fri, 29 Aug 2008 10:33:49 GMT Да, насчет отсутствия привязки к СУБД - вы готовы гарантировать корректную работу _для нескольких_ СУБД? Если будет заявлена возможность работы с несколькими СУБД, заказчик вправе использовать любую из них, но все проблемы должен решать разработчик ПО (будь то перегрузка при тысячах одновременных пользователей, sql-инъекция, сбой СУБД или любых других). Кстати, 99% тестового покрытия исходного кода я не видел более ни у одной СУБД. А уж найти встраиваемую СУБД, способную работать с десятками и сотнями гигабайт данных, имеющую поддержку sql, многопоточные биндинги практически ко всем языкам и отличный планировщик... Так что альтернатив просто не знаю. Постгрес ранее был выбран за надежность и себя оправдал (много лет эксплуатации на самом разном железе, пока физические диски и ФС целы, все данные в сохранности), но на больших объемах данных и высокой нагрузке в автономном режиме не годится, это совершенно другой класс задач. А других открытых СУБД сопоставимого качества не встречал (имеются в виду, с поддержко https://www.opennet.me/openforum/vsluhforumID3/43514.html#28 Fri, 29 Aug 2008 10:04:12 GMT Дело не в распределении обязанностей, а в отсутствии доступа к серверу. Необслуживаемый сервер стоит в интранете и доступ возможен только из офиса заказчика. Так что получить доступ к такому серверу это отдельная история (заказчик может находиться за тысячи километров от нас...). Дебиан+аолсервер+тикль+эскулайт с автономной работой справляются, доступ требуется только чтобы установить новую версию системы.<br> https://www.opennet.me/openforum/vsluhforumID3/43514.html#27 Fri, 29 Aug 2008 08:54:29 GMT &gt;А как насчет ситуации, когда вы _лично_ несете финансовую ответственность за проект? <br>&gt;Раньше работал с постгресом, но адаптировать его код намного сложнее, притом <br>&gt;производительность постгреса существенно хуже.<br><br>то, что с постгресом могут быть траблы производительности по сравнению с аналогичными структурами, хранящимися в, нампример мускуле - я в курсе.<br><br>&gt; Для необслуживаемого сервера эскулайт оказывается к тому <br>&gt;же намного надежнее (клиент-серверные СУБД без присмотра под нагрузкой начинают вести <br>&gt;себя непредсказуемо, все же им приходится регулярно параметры настройки подкручивать, зомбиков <br>&gt;пришибать и проч.)<br><br>ну как-то надо разделить обязанности с кем-то. вы - программист и руководитель, а кто-то - администратор БД. и чтобы ваш коллега денно и нощно решал не ваши проблемы. а вы - денно и нощно работали над оптимизацией своей части проекта.<br>я все-таки политически против привязки к конкретной БД.<br> https://www.opennet.me/openforum/vsluhforumID3/43514.html#26 Fri, 29 Aug 2008 08:32:47 GMT А как насчет ситуации, когда вы _лично_ несете финансовую ответственность за проект? Раньше работал с постгресом, но адаптировать его код намного сложнее, притом производительность постгреса существенно хуже. Для необслуживаемого сервера эскулайт оказывается к тому же намного надежнее (клиент-серверные СУБД без присмотра под нагрузкой начинают вести себя непредсказуемо, все же им приходится регулярно параметры настройки подкручивать, зомбиков пришибать и проч.) Начинал делать большие проекты на эскулайт с того, что один из проектов на постгресе с базой 20 гиг с чем-то перенес на эскулайт - скорость работы хорошо оптимизированного проекта на эскулайт оказалась выше скорости работы хорошо оптимизированного проекта на постгресе в 60 раз, нетрудно догадаться, что на продакшене давно уже работает именно эскулайт версия (архитектура проектов отличается, т.к. в постгресе использовалась единственная база, а в эскулайте набор из десятка баз, но модуль dblink для связки нескольких баз в постгресе для продакшена не годи https://www.opennet.me/openforum/vsluhforumID3/43514.html#25 Fri, 29 Aug 2008 05:37:00 GMT &gt;А зачем эскулайту заниматься разграничением доступа? Это дело приложения, а не встраиваемой <br>&gt;библиотеки.<br><br>я бы поспорил, ну да ладно.<br><br>&gt;На чем же и писать крупные проекты, как не на тикле :-) <br>&gt;Дело вкуса, сами понимаете, и кто-то пишет на лиспе, или на <br>&gt;схеме. <br><br>язык - это дело вкуса ведущего разработчика, конечно. но привязывать свой "крупный проект" к SQLITE - это как-то... ну в общем, я бы не стал.<br> https://www.opennet.me/openforum/vsluhforumID3/43514.html#24 Fri, 29 Aug 2008 04:49:21 GMT Аргументы авторайзера такие:<br> ** (1) The authorization type (ex: SQLITE_CREATE_TABLE, SQLITE_INSERT, ...)<br> ** (2) First descriptive name (depends on authorization type)<br> ** (3) Second descriptive name<br> ** (4) Name of the database (ex: "main", "temp")<br> ** (5) Name of trigger that is doing the access<br><br>А вот пример передаваемых аргументов:<br>SQLITE_READ sqlite_master rootpage main {}<br>SQLITE_INSERT sqlite_master {} main {}<br>SQLITE_CREATE_TABLE test {} main {}<br>SQLITE_UPDATE sqlite_master type main {}<br>SQLITE_UPDATE sqlite_master name main {}<br><br>А зачем эскулайту заниматься разграничением доступа? Это дело приложения, а не встраиваемой библиотеки. Эскулайт предоставляет механизм для _контроля_ доступа, а как разграничивать доступ (и разграничивать ли вообще) - решает разработчик. Зато механизмы контроля очень гибкие - кроме вышеописанного, есть контроль изменения данных, коммита/отката транзакции и т.д. В десктопных приложения названные возможности обычно не требуются, а вот для многопользова