对于第二句话，至少现在不能说它说错的，我们留待后面解决。
二、获取的数据值得信赖吗？
其实这样子说范围显得有点大，一下子涉及到很多方面，一个例子一个例子地举来看好了。
首先是关于选择过滤数据的问题。一直以来，我们认为凡是用户输入的东西，都要经过适当的处理。没错，但真正的是否都做到呢？随便找个抓包的工具，比如Ethereal，看看在你用IE提交表单或者是打开连接的时候，都提交了什么。或者，简单一些，打开NetAnt编辑一个任务，在协议标签中，看看那个“自定义提交者”和“用户代理”的选项。
我想你已经明白了，对方可以自己定制的东西不仅仅是GET或POST过来的数据！如果所有的用户都规规矩矩地用浏览器，确实不用防备这么严，如果对方不这么老实，在取服务端变量或Cookie的时候可要小心了，没有任何人能够保证你获得的数据是合法的。对于Cookie而言，很多程序都出过问题，所以以前强调得比较多，至于另外的，关注的人可能比较少一点，但你是否看过或者写过这样的代码：
sql="ShowHOT_COM_inst_online_char 2,"&statuserid&","&membername&","&memberclass&","&Request.ServerVariables("REMOTE_HOST")&","&boardid&","&Request.ServerVariables("HTTP_USER_AGENT")&","&replace(stats,"","")&","&Request.ServerVariables("HTTP_X_FORWARDED_FOR")&","&UserGroupID&","&actCome&","&userhidden&","&userid&""
Request.ServerVariables("HTTP_USER_AGENT")就是你在NetAnt中看到的用户代理选项，也就是说你可以伪造，同样可以伪造的还有Request.ServerVariables("HTTP_REFERER")，也就是你在NetAnt中看到的提交者选项等等。在做一些项目的时候，很有可能要将这一类的变量添加入数据库，这时候要千万小心，这个地方的忽略，引起的后果和其他类型变量未过滤导致的后果是一样的。
在Google上搜索Referer和Request.ServerVariables两个关键字，还可以看到很多有问题的写法，或者去看看五月份左右的关于动网论坛入侵的文章，也许你的理解会更加深刻一点。
然后是一个隐藏得稍微深一点的问题，不是用户的直接输入要不要过滤？
这就回到了我们前面留下的那个问题，单引号换成两个单引号的潜在威胁。在第二次构造SQL语句的时候，倘若数据是从数据库里面直接去取出来用的，多数情况下人们会认为前面已经处理过的东西看起来似乎并没有必要再处理，或者干脆就是没有意识到应该处理。这是极其错误的！从两个方面来看，首先你入库的时候对提交数据中的单引号处理，仅仅是保证了单次SQL语句构造的正确性，并没有一劳永逸地解决问题；再说了，后面取出数据用的时候，对数据安全性检查的依赖并没有得到保证，因为这种依赖关系没有传递下来，而且依赖关系本身还不是可传的。
就replace(request("someinput"), "", "")而言，它的不安定性在于这种过滤方式只是一种妥协，换句话说只是在有限的范围内掩盖了可能出现的问题，而没有永久性的处理掉。它还有一个讨厌的地方在于给人一种错觉，似乎是处理过的数据已经安全了，容易让后继的代码编写者产生虚幻的安全感。对这两个弱点，不是*换一个写法就能解决的，因为如果你把单引号干脆去掉，又会引来另外一个问题，输入数据中确实有需要而且正确的单引号怎么办？从一开始我就说，单引号本身是无罪的，过滤它只是一种解决手段而已，所以我们还是就这样写吧，不过要在后继的部分加强一下检查。
这一类的问题，如果依然用动网论坛做例子，我建议看一下六月八号的漏洞文章。
还有就是过滤器的位置，这个掺杂了逻辑问题在内的复杂问题。
上一篇：JHACKJ原创win2003硬盘权限设置
下一篇：Linux十大高级安全管理技巧 |
相关文章