一直以来,各大论坛和邮箱都允许使用外链图片。一方面解决了上传和保存带来的资源消耗,更重要的是方便用户转载图片。
然而,简单的背后是否暗藏着什么风险呢?大多或许认为,不就是插入了一张外部图片而已,又不是什么脚本或插件,能有多大的安全隐患。
曾经也有过外链图片泄漏cookie那样的重大隐患,不过那都是很久以前的事了。在如今浏览器日新月异的年代里,这样的bug已经很难遇到了。不过利用正常的游戏规则,我们仍能玩出一些安全上的小花招。
No.1 —— HTTP401
(严重程度:低)
大家都见过,打开路由器的时候会弹出个登录框。
如果了解HTTP协议的话,这是服务器返回401,要求用户名密码认证。
不过,如果是一个图片的请求,返回401又会怎样呢?很简单,我们就用路由器的URL测试下:
<img src="http://192.168.1.1/">
居然依旧跳出了一个对话框!
如果将一个HTTP401的图片插入到论坛里,是不是也会如此呢?我们用ASP写个简单的脚本,并且能自定义提示文字:
<%
Response.Status = "401"
Response.AddHeader "WWW-Authenticate", "Basic realm=IP IC IQ卡,统统告诉我密码!"
%>
然后将URL插入到论坛或空间(如果拒绝.asp结尾的url图片,那就在后面加上个?.png)。
先在QQ空间里测试下:
不出所料,弹出了对话框。不过在ie外的浏览器下,汉字成了乱码,即使设置了ASP以及HTTP的编码也不管用。
我们只好换成英文字符,再百度贴吧里用各种浏览器测试下:
ie678:
ie9:
firefox:
safari:
除了Opera和Chrome没有弹出来,其他的浏览器都出现。不过部分浏览器截断了空格后的字符。
当然,你也可以扩展这个功能,记录用户输入了什么内容。尤其是带上些官方式的文字提示,很容易用来捕捉到一些账号信息。曾经用这招在论坛抓到不少可用的账号密码,不过如今安全意识普遍提高,加上一些安全软件的拦截,这招实用性大打折扣了。
因为是强制弹出的,往往给人一惊,所以在论坛,贴吧或空间里,倒是可以娱乐娱乐。
No.2 ———— GZip压缩zha弹
( 严重程序:中)
在之前的一篇文章里,谈到使用两次deflate压缩,将数百兆的图片文件压缩到几百字节。
http://www.cnblogs.com/index-html/archive/2012/06/22/2558469.html
原理很简单,大量重复数据有很高的压缩率。之前不清楚的deflate算法的最大压缩率有多少,一直不敢确定是不是最优的。后来大致了解了下算 法,由于受到lz77算法的最大匹配长度限制,deflate的最大压缩率确实只有1:1000多点。虽然和rar相比相差甚远,不过1000倍也意味 着,1M的数据可以翻到1G了。
所以我们可以利用一个超高的压缩的HTTP报文,做几件事:
1.消耗内存
2.消耗CPU
3.消耗缓存
对于现在的硬件配置,内存已经足够支撑浏览器,多核的CPU也没法完全耗尽,唯独硬盘是个瓶颈。
我们用C程序创建个1G的内存数组,将图片数据放在其首,后面用’\0’填充。然后使用zlib进行压缩,得到1M左右的结果,保存为x.jpg.gz
接着用ASP读取压缩文件,并给返回的头部加上Content-Encoding 字段。
简单的测试下:
Dim stream
Set stream = Server.CreateObject("ADODB.Stream")
With stream
.Type = 1
.Open
.LoadFromFile _
Server.MapPath(Request.QueryString("File") & ".gz")
End With
Dim agent
agent = Request.Servervariables("HTTP_USER_AGENT")
With Response
If Instr(agent, "Firefox") > 0 Or Instr(agent, "AppleWebKit") > 0 Then
.AddHeader "Content-Encoding", "deflate"
Else
.AddHeader "Content-Encoding", "gzip"
End If
.AddHeader "Content-Length", stream.Size
.BinaryWrite stream.Read
End With
由于部分浏览器的Content-Encoding 只支持deflate .所以特意做了判断,以免失效。
先用ie测试。打开GZip.ASP?file=x.jpg (测试地址:http://www.etherdream.com/Test/bomb.html ),正常显示出图片,紧接着硬盘灯狂闪。。。关闭网页之后,打开浏览器缓存文件夹。果然,1G大小缓存已产生!
接着用火狐测试。不过没等图片出来,浏览器已经卡死了。等了数分钟仍然没有响应,只得结束任务。
用Chrome测试。内存暴涨,最终图片倒是正常显示出来了,不过页面经常崩溃。
Opera一切正常,也没产生特别大的缓存文件。当然,不同版本的浏览器大不相同,可以自己测试。
不过,几个最常用的浏览器有效果就行了。
我们可以将图片插入到邮件里,或论坛贴图,如果不幸被火狐用户点中,那将当场炸死;webkit内核的浏览器则严重拖慢了系统速度;最杯具当属 ie用户了,不知不觉被吞走了1G的硬盘空间,如果插入多个的话则更多倍,只要url参数不同!如果配合HTTP重定向,定向到带有随机参数的url,那 么每次访问页面又会加载并缓存一次!
No.3 ———— 收邮件时暴露IP
(严重程序:高)
这一招其实没有任何技术含量,也不是什么BUG,连缺陷也算不上。仅仅是一种小技巧而已。
既然网页里的图片可以外链,那就意味着可以访问任何服务器,包括我们自己的。在服务器上稍作记录,就可以轻易获得访问者的ip。
这对于论坛来说没多大意义。因为论坛里面访客众多,很难知道哪个ip是谁的。但电子邮件 就不一样了,很少会有其他人来用你的邮箱。
当我们向某个人发送一封邮件,里面有个不起眼的图片,外链到我们的cgi程序上。当他打开邮件时,cgi程序接收到了他的请求,自然也就探测到了ip。为了防止图不裂开,返回一个微小的图片,以防发现破绽。
对于QQ邮件这类有推送提示的邮箱,对方很快就会打开邮件,尤其是写一个比较真实的邮件标题。
利用这点,我们可以写个邮件群发的脚本,向多个QQ发送探测邮件。我们把每个email对应图片的url里带上唯一参数,以区分不同的邮箱。
不出一时半日,当接收者陆续打开邮件,他们的ip也随之暴露。即使用代理上网,也能通过HTTP的HTTP_X_FORWARDED_FOR 字段获得真实ip地址。
通过ip地理定位,很快就可以知道他们最近在哪里。如果有相同的ip,说不定他们正在一个内网里呢:)
防范措施
因为图片保存在外部,所以完全不在自己的可控范围里。即使用户外链的是合法的图片,也只能意味的是当前,而不是以后,因为用户可以更新外链的内容,甚至可以针对不同的ip返回不同的内容。因此要完全防住,只能在客户端上分析图片的内容,后台最多起到辅助作用。
在目前版本的百度贴吧里,因为图片会显示在贴吧的主页面上,所以对外链的安全性已极大的增强。当用户使用外链的形式插入图片时,后台服务器会不 定期的检查图片的合法性,如果存在异常则会删除此图片。如果同样的站点出现多次异常情况,则会进入黑名单。虽然仍有部分疏漏,但相比没有要好的多。对于空 间相册,或者可信站点的图片,则不会反复的扫描检测。
类似的,像微博这类传播性极强的应用,则完全不能使用外链。即使需要,也是由代理服务器读取,再返回给用户,因此就从根本上排除了安全隐患。
原文:http://www.cnblogs.com/index-html/archive/2012/08/15/extern_img.html
Related Posts
【漫画详解】用iframe障眼法,骗取用户点击 做过Web开发的朋友曾经都有过这么个念头:在自己的页面里内嵌一个其他网站的网页,然后可以用脚本去获取他们页面里的信息,甚至可以。。。 显然,有这么好的事也肯定轮不到你来尝了:)一个叫沙箱模型的东西被发明出来,就是防止有这种想法的人搞破坏。。。所以现在的我们只能远观,不可亵玩也。 不过,这些规定只是针对脚本而已。假如让用户自己乖乖的去点,那当然是没问题的。但有多少人会去点呢!! 所以,我们需要施一些特殊的障眼法,让用户在不经意间,就点了我们想让他点的东西:) 就拿上面那个来说吧,如果直接把这个大页面赤果果的硬塞进网页,无论你怎么提示他点,或者说多少好话,大家见了就烦,就是不点:) 所以说,我们必须得修饰修饰,不然人家见了就吓跑了。首先也是最关键的就是这身材问题,突然冒出个这么肥硕的一个页面,看的人眼花缭乱,不知道 发送什么情况啦。我们要好好修剪一下,把没用的部分统统去掉,只留下我们想要的“精华”。这个简单,只要把框架先放到一个层里面,然后把层的尺寸固定好,…
移动前端工作的那些事---前端制作篇之框架篇 为了更好的提升用户体验,移动端逐渐出了许多的移动端的框架,比如Sencha Touch、JQTouch、Jquery-moblie、jqMobi等等。这些框架都有优缺点,不同的框架应用在不同的项目中。现简单阐述一下各框架的优缺点: 一、Sencha Touch框架是一个重量级的框架、它上手较难,代码复杂,并且需要较强的程序基础才能学习,最开始的时候因为一个项目,想使用Sencha Touch框架,后来工期实在太紧张,根本没时间学习它并使用。所以最后转投其他框架。这个框架兼容性很高,运行起来的速度一般,需要长时间的学习且需要水平较高的程序基础才行。所以不太适合前端制作人员的使用。我会在以后的机会单开一篇关于它的使用demo。 二、JQTouch是一个轻量级框架、纯jquery写法,上手比较容易,代码容易理解,加载速度也很快,缺点是配合的移动端效果插件较少,需要很多外部的插件相结合,另外,个别插件还需要解决与框架之间的兼容问题。它的最大的一个弊端就是可利用和变通的布局较少。 三、Jquery-moblie也是一个轻量级框架、纯jquery写法,上手容易,代码容易理解,但由于其绑定的前端效果插件过多,且代码结构有些臃 肿,造成加载速度很慢。尤其是在android系统上测试,速度很慢。用户体验效果不太好,它比较适合开发IPAD或是IOS系统的高端机型。 四、jqMobi也是一个轻量级框架、它的语言基于jquery语言。并对其进行了简化,更有利于在移动设备上进行应用,并且速度很流畅。上手也比较容…