一直以来，各大论坛和邮箱都允许使用外链图片。一方面解决了上传和保存带来的资源消耗，更重要的是方便用户转载图片。

　　然而，简单的背后是否暗藏着什么风险呢？大多或许认为，不就是插入了一张外部图片而已，又不是什么脚本或插件，能有多大的安全隐患。

　　曾经也有过外链图片泄漏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 WithDim agent
agent = Request.Servervariables("HTTP_USER_AGENT")With ResponseIf 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