(4)在服务端正式处理之前对提交数据的合法性进行检查等。
方案(1)的做法需要RDBMS的支持，目前只有Oracle采用该技术;
方案(2)是一种不 完全的解决措施，举例来说明他的弱点，当客户端的输入为“…ccmdmcmdd…”时,在对敏感字符串“cmd”替换删除以后，剩下的字符正好是“…cmd…”;
方案(3)的实质是在服务端处理完毕之后进行补救，攻击已经发生，只是阻止攻击者知道攻击的结果;
方案(4)被多数的研究 者认为是最根本的解决手段，在确认客户端的输入合法之前，服务端拒绝进行关键性的处理操作。
方案(4)与(2)的区别在于，方案(4)一旦检测到敏感字符/字符串，针对数据库的操作即行中止，而方案(2)是对有问题的客户端输入做出补救，不中止程序后续操作。方案(2)虽然在一定程度上有效，但有“治标不治本”的嫌疑，新的攻击方式正在被不断发现，只要允许服务端程序使用这些提交信息，就总有受到攻击的可能。
因此，本文中针对SQL注入攻击的检测/防御/备案模型即基于提交信息的合法性检 查，在客户端和服务端进行两级检查，只要任一级检查没有通过，提交的信息就不会进入query语句，不会构成攻击。在客户端和服务端进行合法性检查的函数基本相同。客户端检查的主要 作用是减少网络流量，降低服务器负荷，将一般误操作、低等级攻击与高等级攻击行为区分开来。技术上，客户端的检查是有可能被有经验的攻击者绕开的，在这种情形下，提交的数据被直接发往服务端，通过在服务器端设定二级检查就显得十分必要。由于正常提交到服务端的数据已经在客户端检查过，因此，服务端检查到的提交异常基本可以认定为恶意攻击行为所致，中止提交信息的处理，进行攻击备案，并对客户端给出出错/警告提示。对应模型简图如(图1)所示。
2.2检 测
对提交信息的检查，主要包括数据类型检查、数据长度检查和敏感字符过滤。前两项可利用函数直接办到，敏感字符过滤则需要应用开发方做相应开发。经过总结，对语句时必须用到的，因此可以针对这些敏感字符，设定过滤函数，在把这些上传的参数结合到查询语句之前对他们进行过滤。下面的2个函数即过滤模块的主要代码:
分页: [1] [2] [3]
- 上一篇:Photoshop制作白边水晶按钮
- 下一篇:ps学习经验