该产品是开源产品，目的也是仅仅保护开源的数据库系统MYSQL和PostgreSQL免遭SQL injection攻击。系统工作在Proxy模式。可以运行于多个Linux发行套件以及FreeBSD之上。对于PostgreSQL而言GreenSQL也是仅有的保护方案。对于SQL Injection不懂的可以Google一下，现在非常流行，我们隔三差五会听到，某某公司泄露了多少多少的客户信息，其中就有SQL Injection的功劳。而且最近刚刚出了一个书，专门写SQL Injection。我托同事从美国买了一本回来，啃了两天，就这么一个东西絮絮叨叨写了4，500页，真是晕菜。不过我还是佩服老美的钻研精神，写的很细致。

　　GreenSQL迄今还是活跃的，最新的版本1.2是09年12月刚release的版本。看了几个版本的release notes，feature没有什么变化，基本都是可用性的修改，redesign，bug fix等等。

　　下图为网络部署图。

　　该产品可以运行于下述模式：

　　1.Simulation Mode (database IDS)

　　是Silent模式，类似于IDS系统，仅仅对于可疑事件进行Log。

　　2.Blocking Suspicious Commands (database IPS)

　　类似于IPS系统，GreenSQL将利用其“启发式”引擎检测以及阻塞非法的查询。其阻塞的Action同IPS看起来很不同，不是中断连接，而是仅仅返回空的结果集，这样用户无法察觉其存在，行为也更加graceful。

　　3.Learning mode

　　在该模式下，GreenSQL学习查询信息，并自动加入到白名单（笔者注：这个过程应该是离线的，否则没有意义了）。在learn了足够多的东西后，可以将系统配置为下面的模式4.

　　4.Active protection from unknown queries (db firewall)

　　利用从模式3学到的白名单作为基础，采用“启发式”（这个词听得我耳朵都磨出茧子了，大家都说自己的引擎是启发式的）引擎，进行下一步的DB IPS的工作。

　　其引擎基本实现如下：

　　1.模式匹配

　　GreenSQL uses a pattern matching engine to find commands that are considered “illegal”. In essence, this is a signature-based subsystem. For example, the following commands are considered “illegal”: database administrative commands; commands that try to change a db structure; and commands used to access system files.

　　2.根据几个的因素，计算Risk

　　GreenSQL calculates each query’s risk. Essentially, this is an anomaly detection subsystem. After the risk is calculated, GreenSQL can block the query or just create a warning message (this depends on the application mode). There are a number of heuristics GreenSQL uses when calculating risk. For example, query risk is increased by:

　　* Access to sensitive tables (users, accounts, credit information)
* Comments inside SQL commands
* An empty password string
* An ‘or’ token inside a query
* An SQL expression that always returns true (SQL tautology)

　　In order to find anomalies, GreenSQL uses its own SQL language lexer to find SQL tokens.

　　最后看看管理Web界面，先不说功能如何，我的感受是心中充满阳光，项目的发起人审美观念非常好：

　　现在SQL Injection的防范已经是WAF的基本配置了，为什么会有这个东东专门防范SQL Injection。笔者认为原因如下：（本想画一张图给大家看看，但是太晚了，我又是急性子，发了再睡觉）：

　　1.Web Server位于HTTP层

　　2.后面的App server位于App层

　　3.后面的DB Server位于SQL层

　　1的层次最低，2的层次最高，3的层次勉强可以说比1高一点点，比3第一点点。因此要想彻底根除SQL Injection要在3保证保证应用层程序员的code没有问题，才能完全保证SQL Injection的消失，但这不可能。在1防范可能不很精确，在3能可以从某个程度说是一个很好的补充，当然也无法完全解决问题，毕竟还低那么一点点。是不是有点唐僧啊。

　　总之累了该回家了，一家之言，敬请拍砖。