网站脚本攻防对立的防御浅析.docVIP

网站脚本攻防对立的防御浅析 廖坚先 摘 要 面对网站被攻击的问题，本文对网站脚本的安全作了浅析。文章从黑客对网站脚本这一层面的攻击进行分析并引出脚本的安全防御。 关键词：脚本攻击，脚本防御，网站安全 一、引言 随着技术的进步，安全意识的提高，网站被非法入侵破坏的数量相比以前大有减少，但是现今网站的安全问题仍不容乐观。据国家互联网应急中心的2010上半年网络安全报告显示：2010年上半年中国大陆地区被篡改的网站数量14907个，平均起来就是每天大约54个网站被篡改。这些只是被篡改的，那没有篡改网站而别有用心的呢？还有个问题就是有一大批网站是使用开源的整站程序，那么只要一发现漏洞就有一大批网站存在被攻击的危险。 为什么会出现这种情况呢？第一，互联网上仍存在着很多老的网站系统，它们往往在开发初期就没有考虑安全功能，所以架构上就存在安全问题，补了表面上看得见的，那看不到的呢？总有一天会被黑客挖掘出来。第二，安全意识虽然得到了普及，但是不强，很抽象，因为开发者不了解黑客的攻击手法，就不够了解危害的大小，没有一个危机感。而导致这个问题出现的原因是只普及了正面性的理论化的大道理，而没有普及实际性细节化问题的提出和解决的文章或者书籍。第三，成批的纯拿来主义者，拿来了开源的整站程序就用而不进行安全审核。 二、对网站脚本程序的受攻击及防御的分析 攻防是对立的，有攻才有防。所以想更好的防御要换位思考从黑客的角度来看攻击然后形成防御思维。那黑客的思维是怎样的呢？首先，黑客是有目的的而实现目的都是需要更高的权限，那怎样获得更高的权限呢？进后台或者上传木马，怎样可以进得了后台或者传木马呢？SQL注入，上传漏洞··· 下面笔者将对现今存在较普遍的黑客攻击思维进行分析并提出如何防御这种攻击。 （一）注入攻击 笔者对注入攻击进行了再分类，注入攻击可再分为SQL注入攻击、可执行代码注入攻击，非可执行代码注入攻击这三类。 1．SQL注入攻击 SQL注入攻击就是构造SQL语句通过过滤不严的参数提交到SQL请求中来达到黑客想要的目的。 面对这种攻击，我们一般的较为普遍的做法是统一的对用户数据的提交进行过滤，如当时在网上普遍流传的asp通用防注入系统。但是在早期的版本当中作者忽略了对cookie的过滤，导致可以通过cookie提交的方式来达到sql注入。所以用户数据的提交不仅仅是GET，POST方式还有COOKIE。 客户端进行服务请求是提交HTTP请求数据包的，而HTTP请求数据包里面不仅仅包含前面提交的三种类型数据，还包含了协议包的通用信息头，假如你的程序需要用到这些数据同时要带入SQL语句那就存在危险了，因此只对GET，POST和COOKIE的数据进行过滤的话也还是不够的。数据包是可以伪造之后再使用nc工具提交的。如某BBS整站系统的setup.asp文件中一段代码如下：协议包的通用信息头中的“HTTP_REFERER”直接带进了SQL请求，黑客可以构造多个SQL语句来达到他们想要达到的目的。有人会认为如果SQL SERVER配置的较安全不支持多句执行的话就没戏了。但是假如刚好在某处就有一个鸡肋的漏洞可以利用到这个漏洞注入到数据库的内容呢？毕竟注入进去的内容是没有经过过滤的。所以这里要提出的是即使很小的安全隐患也应该保持足够的谨慎。 笔者认为面对这种攻击最小的防御方法是统一对带入SQL语句的“GET”,“POST”，“COOKIE”三种方式提交的数据转义单引号。在ASP当中使用replace替换一个单引号为两个进行转义。在提交的参数类型为整数型的要判断是否为整数型，是的话再转换为整数型数据，对协议包的通用信息头的参数也如此。在PHP中，先判断PHP是否配置打开了magic_quotes_gpc，不是的话就用addslashes函数对所有的GET、POST和COOKIE数据进行转义。 在PHP中做到这一点还不够，因为还可能存在宽字节注入漏洞。当MYSQL配置文件或者在脚本上设置了连接MYSQL数据库使用宽字节的字符编码时，即使单引号会被转义但当用户在构造注入语句的单引号之前加上一个特殊字符，这个字符的字节第一位为1也就是用十六进制表示时是80后（注：大于或等于80）的一个字符，这时候程序会把这个字节跟下一个字节也就是“\”组成一个宽字节字符，这样就解放了单引号导致了注入漏洞。如黑客可以这样突破特殊字符转义注入test.php?name=test%80’ or 1=1%23(注：%23为#的编码，注释掉后面的SQL语句)。这时应该设置连接数据库使用的字符集binary（注：使用语句mysql_query(set character_set_client=binary); ）。 2．可执行代码注入攻击和非可执行代码注入攻击 这两种攻击跟SQL注入攻击类似只是这