黑客三兄弟
来自：码农翻身（微信号：coderising）
建立Beauty.com的黑客三兄弟最近可谓是春风得意，他们的这个网站精准地利用了人类的本性，窃取了不少登录用户的cookie。
（注：参见前文《浏览器的安全反击战》）
利用别人的cookie，他们可以冒充真实的用户，在颁发cookie的那个网站中为所欲为，个人隐私在他们面前根本不存在。
运气好的话连别人的用户名和密码都能得到，那就一通百通，因为大家都嫌麻烦，总是使用同一套用户名和密码来登录各种不同系统。
可是好景不长，这一天黑客老三慌慌张张地找到了老大：“大哥，大事不好！ ”
“老三，你这慌慌张张的毛病什么时候能改改？ 这点儿你可得学学你二哥。” 老大训斥道。
“不是，大哥，这次真是大事不妙，浏览器家族最近颁布了一个什么同源策略，我们原来偷Cookie的招数都不管用了！ 今天我连一个Cookie，用户名密码都没有偷到。”
“什么叫偷，说了多少次了，那就借，知道不？！”
（注：同源策略参见前文《浏览器的安全反击战》）
“我早就料到了，这么重大的安全漏洞肯定肯定会补上的，他们不会这么轻易地让我们来跨域来访问别人的Cookie，修改别人的DOM，调用别人的服务的。” 老成持重的黑客老二说道。
“那怎么办？ 没有Cookie，难道我们三兄弟以后就饿肚子了吗？” 老三很紧张。
“别担心，我们哥仨勾兑勾兑，他们肯定有漏洞的，” 老大安慰到，“老二，你先说说你的看法。”
“其实吧，我们想去借一个Cookie来用，关键是要让我们Beauty.com的JavaScript在目标浏览器上运行，然后访问爱存不存银行(icbc.com.cn)的cookie，可是现在他们用了同源策略，我们网站的JavaScript不允许访问别人网站的东西，那这条路就行不通了。”
“我想到一个招数，” 老三兴奋地说，“我们可以想办法修改下icbc.com.cn服务器端的JavaScript， 把偷Cookie的代码加上去！”
“你想得美，那岂不得到icbc.com.cn的服务器去修改了！还得黑掉别人的服务器，这就难了，即使你修改了，人家程序员再次发布新版本，那不就把我们的修改给覆盖掉了？” 老大再次训斥。
“那我们就想办法去黑掉程序员的SVN，Github，直接把上面的代码给改了.....” 老三的声音越来越小。
“唉，算了吧，我们盗亦有道，只做Web端黑客。” 老大重申三人组织的性质。
这时候老二想了一个办法：“其实老三说的也有道理，我们只要想办法把JavaScript代码注入到目标页面中，就能绕过同源策略了，这让我想到了HTML中的<input>，这个标签会在浏览器中产生一个输入框，让用户输入数据，我们可以把JavaScript代码当做数据输入进去， 等到数据提交到服务器端，会保存下来，下次展示页面的时候不就可以执行了吗？！”
老三说：“二哥我听不太明白，你能不能举个例子？”
老二说道：“好吧，有这么一个网站，可以让你对某个文章输入评论：”
“然后，你在评论区输入了这样的代码，注意，我们注入了一段'JavaScript'”
“等到再次有人访问这个页面的时候，会发生什么呢？” 老二启发老三。
“奥，我明白了，那就可以把那个人的cookie显示出来了！”老三一点都不笨。
兴奋之余，老三挠挠头：“ 但是这只是在人家的浏览器中显示，怎么才能发到我们的服务器呢？ 用JavaScript来发？ 那也不行， 因为同源策略严格限制JavaScript的跨域访问呐！”
老大也说：“是啊，这个人看到自己的cookie被alert出来，估计会吓一跳吧。”
老二说：“嗯，确实不能这么办，让我想想。”
一炷香时间过去，老二说：“有了！ 那个同源策略并不限制<img>这样的标签从别的网站（跨域）去下载图片，我们在注入JavaScript代码的时候，同时创建一个用户不可见的<img>，通过这个<img>发cookie发给我们。”
老三还是不明白， 要求再详细解释一下，老二就上了代码：
老二说：“看到了吧，只要这段代码被执行，用户的cookie就会发到我们服务器上(http://beauty.com/log)，我们就等着收取cookie吧！”
老三感慨道：“二哥你真厉害，天马行空，竟然想到了使用<img>的src属性来发送数据！”
老大说：“我们干脆把这段代码封装成一个js文件，嗯，就叫做beauty.js吧， 这样以后我们用起来会很方便！”
老三看到又可以‘借到’cookie了，兴奋得直搓手： “大哥二哥，我这就去把JS写出来，找个网站试一试。”
老大说道：“我们把这种方法叫做Cross Site Scripting ，简称CSS，二弟意下如何？”
老二说：“大哥， CSS已经名花有主了，意思是层叠样式表，我们还是叫做XSS吧！”
（注：按照XSS的分类方法， 上面介绍的叫做存储性XSS， 危害最大。 还有反射型XSS,基于DOM的XSS，本文不再展开。）
大家都表示同意。
老三很快写出了beauty.js， 也折腾出了http://beauty.com/log 专门用于记录‘借’来的cookie。
他找了一家网站做实验，注入了beauty.js， 没过多久，cookie就源源不断地发过来了。大家都非常高兴，马上扩大范围，在多个知名网站上都做了手脚。
一周以后，负责监控的老三发现，cookie越来越少，老三赶紧调查，发现很多网站的Cookie都加上了HttpOnly这样的属性：
Set-Cookie：JSESSIONID=xxxxxx;Path=/;Domain=book.com;HttpOnly
这个cookie一旦加上HttpOnly，浏览器家族就禁止JavaScript读取了！ 自然也就无法发回到beauty.com。
老三赶紧向组织汇报。
老大说道：“看来浏览器家族又升级了啊！”
老二说：“其实吧， 既然我们可以往指定的页面注入JavaScript代码，那这个JavaScript可以做的事情就多了去了，不一定只是借Cookie。例如我们可以用这个JS代码画一个假的登录框，覆盖到真的登录框之上，让用户信以为真，这样就可以偷到真实的用户名和密码了。 或者通过JavaScript构造GET,POST请求，可以模拟用户在该网站做点手脚，删点什么东西，从一个账号往另外一个账户转账，都是可以的嘛！”
“妙极， 老二，真有你的，老三，你去找点网站，按二哥说的试试。”
又过了几天，老三哭丧着脸说道：“大哥二哥，这些彻底玩完，现在人类出手了，来了几个必杀技。”
“什么必杀技？”
“一方面他们有人会对输入进行过滤，发现不符合他们要求的输入例如<,>等就会过滤掉，我们的<script>可能会变成'script' 被存到数据库里。”
“另一方面有人还会对输出进行编码/转义操作，例如会把'<'变成 '<'，把 '>' 变成‘>’ ，然后再输出，这样一来我们的<script>就会变成<script> ， 浏览器收到以后，就会认为是数据，把<script>作为字符串给显示出来，而不是执行后面的代码！”
老二说：“三弟别失望， 干我们这行的，就是矛和盾之间的较量，虽然在原理上大家已经知道了怎么防范XSS，但是在实践中总会有漏洞，我们只要耐心寻找就行了。 此外，我们还要想想别的办法，看看能不能开辟其他路子。”
“什么路子？” 老三问道。
“你们应该知道，一个用户的会话cookie在浏览器没有关闭的时候，是不会被删除的，对吧？”
“是的，我和老三都知道，我们不是一直试图去拿到这个cookie吗，只是越来越难了。”
“我们换下思路，不再去偷这个cookie了，相反，我们在我们的Beauty.com中构造一个领奖页面，里边包含一个连接，让用户去点击，例如：”
恭喜你获得了iPhone X一台,快来 <a href="www.icbc.com.cn/transfer?toBankId=黑客三兄弟的账户&money=金额">领取吧！</a>
“当然，” 老二补充道，“我们得事先知道icbc.com.cn的转账操作的url和参数名称。如果这个用户恰好登录了icbc.com， 那他的cookie还在， 当他禁不住诱惑，点了这个链接后，一个转账操作就神不知鬼不觉的发生了。”
（注：为了方便展示，本文举了一个非常简单的案例，银行实际的转账操作要远远比文章描述安全得多。）
“那要是用户就是不点击呢？”
“你忘了我们XSS中使用过的img了吗， 也可以应用到这里来啊，创建一个看不见的图片：”
<img src="www.icbc.com.cn/transfer?toAccountID=黑客三兄弟的账户&money=金额">
“只要他打开了这个页面，不用点击任何东西，就会发生转账操作。” 老二再次祭出了img大法。
“怪不得现在有很多邮箱默认不显示邮件中的图片呢！”老三说，那要是人家icbc.com.cn的转账操作需要form表单，是POST操作呢？”
“那也不怕啊，我们可以把这个表单创建起来，放到一个不可见的iframe中，用户只要一访问，就用JavaScript自动提交。” 老大对这种办法驾轻就熟。
“总之，只要这个用户在访问icbc.com.cn的时候， 访问了我们的网站，就极有可能中招，我们这种方式，只是利用了一下合法的Cookie，在服务器看来，我们发出的请求，那就是一次合法的请求啊，哈哈！” 老二很得意。
“老二，你这叫跨站请求伪造啊，Cross Site Request Forgery（CSRF），这个缩写应该不会重复了吧！” 老大做了总结。
用了CSRF， 三兄弟果然获利颇丰，但是人类也很快也意识到了这一点，应对手段马上就来了，步骤特别简单：
1. 用户在icbc.com.cn转账，显示转账的form，除了常用的字段之外，额外添加一个token ：
这个token是icbc.com服务器端生成的，是一个随机的数字。
2. 用户的转账数据发送的服务器端， icbc.com就会检查从浏览器发过来的数据中有没有token,并且这个token的值是不是和服务器端保存的相等，如果相等，就继续执行转账操作，如果不相等，那这次POST请求肯定是伪造的。
老三愁眉苦脸地对大家说：“这个token是服务器端生成的，我们无法伪造的，CSRF的手段也不行了。”
老大安慰道：“钱哪有那么容易就好挣的？ 我们还是想想办法，多利用XSS漏洞吧，如果可以注入JavaScript， 就可以读取Token,为所欲为了。 ”
老二说：“大哥，Web端的油水越来越少，我们也得与时俱进，扩展下业务啊，黑客三兄弟向服务器端进军吧！”
“二弟所言极是，下周我们再讨论吧。”
（完）
●本文编号525，以后想阅读这篇文章直接输入525即可
●输入m获取文章目录
Python编程
更多推荐《18个技术类微信公众号》
涵盖：程序人生、算法与数据结构、黑客技术与网络安全、大数据技术、前端开发、Java、Python、Web开发、安卓开发、iOS开发、C/C++、.NET、Linux、数据库、运维等。