EnterpriseDB的SQL注入攻击保护功能一

enterprisedb是基于postgresql的企业级数据库（即PPAS）。

 

PPAS（Postgres Plus Advanced Server） 提供了SQL注入攻击保护，按下面讲
 a 概述
 b 配置
 c 通常维护操作
 d 备份/恢复sql注入保护数据库
 

SQL注入攻击是黑客对数据库进行攻击的常用手段之一。随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。SQL注入是从正常的WWW端口访问，而且表面看起来跟一般的Web页面访问没什么区别，所以目前市面的防火墙都不会对SQL注入发出警报，如果管理员没查看IIS日志的习惯，可能被入侵很长时间都不会发觉。但是，SQL注入的手法相当灵活，在注入的时候会碰到很多意外的情况，需要构造巧妙的SQL语句，从而成功获取想要的数据。

PPAS提供SQL注入攻击保护。SQL注入攻击保护一般是应用开发人员的责任，数据库管理员则无能为力。PPAS通过检查传入的SQL提供SQL注入攻击保护。
SQL保护提供给数据库管理员反馈潜在的危险查询和阻塞这些查询。

1
概述
这届介绍各种不同种类的SQL注入攻击和SQL注入攻击保护是怎么防止攻击的。

1.1
SQL注入攻击类型
有多种不同技术的SQL注入攻击，每种技术都有某种signature。SQL注入攻击检查查询中是否有下列signature：
a Unauthorized Relations/未授权的关系
PPAS允许管理员对关系的访问进行控制，但很多管理员不做这些乏味的工作。
SQL注入攻击保护（SQL/Protect）提供了一个学习模型对用户访问的关系进修跟踪。
这也许管理员确认应用程序的负载，并且，SQL/Protect也学习哪些用户会访问哪些关系。
当SQL/Protect被切到被动或主动模式时，会对传入的查询检查要学习的关系。

b Utility Commands/工具命令
在SQL注入攻击中经常会用到一些常用命令，像典型的DDL语句。例如创建用户定义函数以访问系统其他资源。
SQL/Protect能够阻塞这些在应用程序中通常不使用的SQL命令的运行。

c SQL Tautology/ 同意的SQL
在SQL注入攻击中使用最频繁的技术是在WHERE子句中增加部分内容，例如WHERE password = 'x' OR 'x'='x'，
攻击者通常以这种方式寻找安全薄弱环节，SQL/Protect能够阻塞这类查询。

具体的攻击方法可以参见我转载的《SQL注入攻击》
1.1.1
受保护的角色
监控SQL注入攻击涉及到分析受保护的角色的session里的SQL语句。
受保护的角色是PPAS数据库管理员选择的要监控的数据库角色。（PPAS里，用户和组统称为角色）
每个受保护的角色可定制要监控的SQL注入攻击类型（1.1节中讨论的），从而提供不同程度的保护，并显着地降低了DBA维护用户的工作量。

注意：
    超级用户不能作为受保护的角色。如果受保护的角色后来成了超级用户，该角色的某些行为
    将被显示：
    a 当这个受保护的superuser的每一个sql命令被SQL/Protect抛一个警告信息。
    b 受保护的superuser执行每一个命令，都会在统计信息视图edb_sql_protect_stats中
      的superusers列都会加1.
    c 当SQL/Protect是active模式时，所有受保护superuser用户执行的命令被禁止运行。

1.1.2
攻击统计：
受保护用户的每一个命令被SQL/Protect当作攻击而记录。这些条件能通过试图访问以
识别攻击的开始。
如果受保护用户连接了多个数据库，这个用户的攻击统计信息分别存放在连接的数据库里。
注意：