★我要吧★

 找回密码
 注册[Register]
搜索
qq空间相册密码查看为什么登陆后需要激活无法注册?

URL静态化背后的隐患分析

[复制链接]
发表于 2010-12-15 21:49:57 | 显示全部楼层 |阅读模式
本帖最后由 孤单的思念 于 2010-12-15 21:52 编辑

无论是人还是搜索引擎都偏爱url静态化,其背后带来的好处是很多的,许多站长都喜欢通过一些技术手段,实现整站的静态化,以投搜索引擎的偏好,唯有我们——安全测试人员,比较讨厌。所以遇到一个目标网站时,很多人都会通过google排除掉静态化的网页,针对动态页面下手。
但是静态化并不等于安全,首先我们需要知道网站是如何实现静态化的。说白了,实现网站静态化的手段主要有两种,一种是直接生成静态页面,另一种就是通过Apache的rewrite mod进行url重写,当然每种方法可能会有n多种的实现方式,两者之间也可以相互交叉。对于直接生成静态页面,主要在新闻频道采取这种方式,因为新闻永远是那样子,不需要更换或者更换的很少,这样的话直接在硬盘或者内存中放置这个数据页面,当有客户端访问时可以直接将数据传递给用户,而避免了服务端解释执行、数据库大量检索等资源操作,加快了响应速度;对于urlRewrite,这种方式的应用面就比较广了,基本上在任何的场合都适用,尤其是在无法直接生成静态页面(页面内容时刻在变,如统计页面)时,urlRewrite为这一情况提供了优秀的解决方案。由此我们看到,对于后者,其实内容依旧是动态的,只不过在客户端表现为静态页面,当客户端GET/POST到服务器时,服务器首先会对url进行解释,然后重定向到真正的页面上去,而这个过程都是在服务端操作的,客户端没有任何的异常。
看到这里,我们应该有所想象。既然是动态页面,那便要传参,我们来看一下各网站可能会采取的传递方式。
    1.http://target.com/cat-product/123456.html
通过想象推测,这个链接的可能重写方式是
    http://target.com/index.php?cat=product&;;id=123456
    2.http://target.com/cat-product/123456.html?action=post
这种方式就更加明显了,基本上可以比较的确定是通过重写的,因为传递了个显式参数的
当然上面这些都是yy,你可以看一下wordpress是如何实现的(我的虚拟主机不支持重写,所以没有静态化)
由上面可以看出如果判断出某个网站是通过重写进行静态化的,那么该网站任然处于可能存在注入的安全威胁中。
例如上面的例子,我们可以通过这样的方式进行检测
    1.http://target.com/cat-product/123456 and 1=1.html
但是这种方式并不利于注入工具的使用,我们可以按照他本来的面目进行检测
    2.http://target.com/index.php?cat=product&;;id=123456 and 1=1
虽然第二种方式比第一种方便,但是请注意,这里的id是我们猜测到的,如果是productid而不是id呢,可能我们无法猜测到,这样的话第二种方法就失败了。但是第一种不会,因为服务端在解释url时会自动将我们的构造参数参数赋给参数名
注意,同样是下面两个链接,但是通过重写后受到注入攻击的可能性却不一样
    1.http://target.com/cat-product/123456.html
    2.http://target.com/index.php?cat=product&;;id=123456
大家可能会有疑惑,这需要从url规则的书写方式说起。我们来看一下对于第一种方式的书写规则
    ###### .htaccess #######
    RewriteEngine On
    RewriteRule ^cat-(.*)/(.*)\.html$ index.php?cat=product&id=123456 [NC,L,QSA]
    ......
    ####### End Rule #######
对于这种方式的重写,那么两者遭受到注入攻击的可能性是一样的,但是程序员通常考虑到重写的精准性(因为多个不同的页面,如果仅仅进行简单的匹配的话,可能会重复),很可能会这样写
    ###### .htaccess #######
    RewriteEngine On
    RewriteRule ^cat-(.*)/(\d+)\.html$ index.php?cat=product&id=123456 [NC,L,QSA]
    ......
    ####### End Rule #######
这个和上面第一个的差别就是:第二个括号中的匹配不同,第二个进行了数字型数据的匹配,如果我们提交123456 and 1=1这样的参数的话就失败了(前提是你无法猜解出这个参数名,如果猜解出了,那便是另一种景象了)。由此我们看到,程序员无意的进行了匹配,却增加了程序的安全性。不过对于第一个参数,注入还是可能存在的,只不过是字符型,在php中可能会比较棘手
其实这篇文章早就想写,但是苦于没有经过实际的验证,所以过了几个月还是没写,恰好昨日遇到了一个网站,验证成功了,所以才写出来同某些不知道的人探讨。本文也只是提出一个现象,并无什么技术而言,其受众对象也主要是程序员,算是作为一种反面资料吧
urlrewrite是个好东西(不仅仅针对搜索),尤其是apache的,在增加网站安全性上有很多重要的作用。比如在url重写过程中中直接过滤某些恶意字符,可以很好的放置reflect形式的XSS攻击,这样就省去了程序上的代码量
具体其它更多的细节可以参考apache的技术文档(当然不只是apache才有这种功能)

相关帖子

发表于 2010-12-16 09:57:28 | 显示全部楼层
不太懂这个哦
回复 支持 反对

使用道具 举报

发表于 2010-12-31 02:30:45 | 显示全部楼层
支持LZ发帖,受益非浅啊~~~
回复 支持 反对

使用道具 举报

发表于 2010-12-31 13:41:31 | 显示全部楼层
我硬是没看懂,向楼主学习了。
回复 支持 反对

使用道具 举报

发表于 2011-5-21 23:09:31 | 显示全部楼层
我没有看懂是什么意思
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 注册[Register]

本版积分规则

QQ|手机版|小黑屋|☆我要吧☆ ( 豫ICP备13016831号-1 )

GMT+8, 2024-11-24 12:35 , Processed in 0.059317 second(s), 20 queries .

Powered by abc369 X3.4

© 2001-2023 abc369.

快速回复 返回顶部 返回列表