好书一起读(147)：XSS，CSRF，SQL注入

Posted 2021-04-25 安静的书桌

零、前言

战争有着天大的魅力，进攻让人热血沸腾。

维埃里神威盖世，因扎吉嗅觉无双，李世石挖棋骗狗，安德森弃后杀王，马薇薇温柔刺客，林正疆怒目金刚，平安城围敌雪恨，祭旗坡画策渡江，月魔王分兵虎踞，法拉利破阵鹰扬……伟大的攻击手生而具备敏锐的眼睛和凶暴的力量，别人眼里的全身披挂，在他们眼里破绽百出，虽有七层巨盾，犹如裸奔中原，当猎物对危险还茫然无知，猎人已经算计好了七八种致胜的方法，只等时机恰到，一击必杀。

既然敌人如此可怕，潜在的受害者就不能掉以轻心，曹操阵前邀请，韩遂欣然相会，弱小的一方总是对敌人怀有侥幸的好意，他们也为之付出了太大的代价。只有挨打，一次，两次，打得疼了，疼得怕了，如临深渊，如履薄冰，随时随地都在想着自己会怎么死，防御能力就自然涨了三分。对方前锋是要向左还是向右，要突还是要传，还是要闪开空挡直接射门，被打成筛子若干次，才会对敌人一切可能的进攻变化有所准备，从而寻找到正确的应法。

要知生，先知死，要防御，就要知道在敌人眼里你可能有哪些漏洞。你要知道敌人可能攻你的偏师也可能攻你的本阵，可能打你的侧背也可能中心突破，可能切后排法师也可能团控跳大直接秒肉装核心，还可能飞补给线打掉你送装备的信使。网站安全也是一样，从浏览器到服务器，至少两个操作系统加上其间不知多少环节的网络线路，这样庞大的战场，任何一个点都可能被敌人定为主攻目标，那就要先看地图，了解战场。计算机组成原理，操作系统，计算机网络，这些学科是怎样分工合作的；客户端，服务端，中间的网络，它们的运行机理分别是什么；聪明的坏人可能怎样利用这些规则，来达到他们邪恶的意图。

如果被坏人实现了意图，从他的角度就算成功，为不让他成功，就要修补自己的漏洞。漏洞在浏览器，服务器，中间网络等不同位置可能出现的原因有哪些，虽然黑客智慧无穷，计算机世界复杂无边，漏洞几乎不可能完全消灭，但至少知道些惯常的套路总有助于少受损失并发散思维。当防御体系一砖一瓦渐趋坚固，你的系统就在黑客眼中无懈可击，锐利的眼光扫到可能突破的弱点，发现处处都已壁垒森严，严丝合缝，固若金汤。这是每个编程者的梦想，也是几乎不可能实现的最高目标，对此只能一点点学，一步步走，一篇篇资料看下去。这是一条艰难的道路，但我们都必须出发。

这篇说说最常见的三种Web攻击，参考书籍《白帽子讲Web安全》和《Web前端黑客技术揭秘》。

一、XSS

有时候我们看到别人的QQ空间日志发表了奇怪的内容，会想「中毒了吧」，其实准确说是XSS攻击。

XSS，跨站脚本攻击，本质是「对用户当前浏览的页面植入恶意脚本」。具体说，就是黑客为页面添加网站开发者意图之外的逻辑，其实现方式是在网站开发者提供的用于显示用户数据的地方加入脚本。

分为三种：反射型，持久型，DOM型。

反射型：

如果url中的一部分会直接显示到页面上，黑客可以构造一个恶意url，使其中含有xss代码，再把这个url引诱无辜用户点开，无辜用户点开之后，xss代码显示到页面上，被浏览器理解为脚本执行，达到黑客的目的。

持久型：

如果黑客可以将脚本代码通过发布内容（如发博文、写留言等）的方式发布到服务器上，成为某个url正常的页面的一部分，其他用户访问这个看似正常的url，则其页面已经包含了xss代码，被浏览器理解为脚本执行，达到黑客的目的。

DOM型：

是反射型的一种，但恶意url中的xss代码不直接成为DOM的一部分，而是在其他用户访问页面时，由页面的原有脚本将其插入到DOM中，插入之后，浏览器即执行脚本中的xss代码，达到黑客的目的。

因为恶意脚本的逻辑可能很长，所以xss代码可能是简短的插入script节点的语句，载入来自第三方域的含有具体恶意代码的脚本，所以称为跨站脚本攻击。

具体的恶意代码，常见的行为是读取cookie，构造例如一个img标签，将其src属性指向恶意第三方网站，将cookie的内容作为参数附在src的url上，这样黑客就能在其网站上获得你的cookie信息，这就是所谓的cookie劫持。

恶意代码另一种常见的行为是执行GET或POST等操作。GET操作同上，指定img的src方法，中招者的浏览器即会发起一个get请求，其性质可能是删除某个中招者有权限删除的文章之类。POST操作可能是由恶意脚本构建一个表单并直接提交，也可能是构建一个ajax请求提交。

开头所说的中招的QQ空间用户，是典型的XSS蠕虫场景，其特点是该页面有发内容能力，又有交互行为。这样一个用户张三访问其他用户李四的日志（或站内信、留言等）时，因为该日志已经含有恶意脚本在里面（持久型XSS），脚本在张三的浏览器执行，构造一个表单并提交，为张三也发表了一篇同样内容的日志，这样病毒式传播开来。

为了防御XSS攻击，需要采用以下方法：

1.为cookie设置HttpOnly以避免cookie劫持的危险。

2.为将进入html标签、HTML属性、脚本、事件、样式表、链接的用户输入，做相应的编码工作。

3.为用户通过富文本编辑器输入的内容，进行白名单的过滤。

4.针对DOM型XSS，一次编码不够，要编码第二次，针对从javascript到DOM的步骤。

小结：

XSS攻击的本质是：我要做些坏事，比如删你的文章，但我没权力，只有你（登录后的浏览器，重点是cookie）有权力。

那我就写好脚本，让你的浏览器一不小心跑了它，我的坏事就做成了。

怎样能让我的脚本被你的浏览器跑呢？只要这脚本是你浏览器中网页的一部分，你的浏览器自然就会带着登录状态跑它了。

第一种思路，让网络上某个url对应的网页确实是「含有我脚本的网页」，你访问这url就可以了，这就是持久型。

第二种思路，网络上某个网页其url参数直接进入内容，那我巧妙地构造一个url，你只要点开url，你看到的网页里就有我的脚本，这就是反射型。

第三种思路，网络上某个网页会将其url参数用javascript生成DOM节点，那我巧妙地构造一个url，你只要点开，那网页里就有我的脚本，这就是DOM型。

总而言之，网站开发者要留神那些把用户输入的东西显示到网页上的地方：那些地方是用来显示用户数据的，不是用来载入用户脚本的！

那问题就是，怎么确定用户输入的东西是脚本还是数据？

第一种思路，可以过滤，指定白名单，只放行特定的数据型标签，脚本标签不放行。

第二种思路，粗暴转码，不管你输入的是啥，一律数据化，你输入数据，它还是数据，你输入脚本，它也变成数据。

目的就是确定用户输入的内容显示到网页上之后，在形式上全是数据，不可能是脚本。

附：Java语言的防御XSS攻击的库：

ESAPI: https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

JSOUP: 

https://jsoup.org/cookbook/cleaning-html/whitelist-sanitizer

二、CSRF

我要做些坏事，但我没权力，只有你（登录后的浏览器，重点是cookie）有权力。

那我就想办法让你的浏览器办我的事，发送我希望的GET或POST请求。

这似乎跟XSS有交叉了，梳理一下，只要是让受害者用户因访问某个页面而无意中发了请求，来达到坏人的目的，就是CSRF攻击，如果该页面与请求目标页面同源（即存在于正常网站上），就是XSS与CSRF结合的攻击，不同源（即存在于恶意网站上）则是纯CSRF攻击。

XSS防御防的是不让坏人有机会把脚本放到我网站的页面上；CSRF防御防的是不让坏人构造假的请求增删我网站上的资源，这请求可能是来自于恶意脚本，也可能只是一个html标签的src属性发起的GET请求。

坏人想构造一个假的请求，需要知道几件事：请求的方法GET还是POST；请求的url，请求的参数名，参数的值。

方法和url以及参数名总没办法保密，能动脑子的点就是参数值。

什么样的参数值，真正的用户知道，造假请求的用户不知道呢？一是验证码，二是token。

这两者的原理其实一样：用户访问网页时，后台生成一个随机串存到session里，并把这串放到网页中给用户，用户提交表单时，检查表单中串与session中串是否一致。

唯一区别是这串在网页中的显示，验证码是生成图片让用户肉眼分辨，token是作为隐藏域直接成为表单的一部分。

所以重点表单常用验证码，而一般表单考虑到用户体验，采用token的方式。

三、SQL注入

我要做点坏事，但我没权力，只有你（服务器的后台代码）有权力。

那我就想办法让你的后台代码办我的事，执行我的SQL代码。

任何注入都是不慎给了坏人机会，让他在本来给他输入数据的地方输入脚本，然后他的脚本在特定的有权上下文上被执行了。XSS和CSRF的有权上下文是带无辜用户cookie的浏览器环境，而SQL注入的有权上下文是可以访问网站数据库的网站后台程序。

什么情况下会是本来给人输入数据的地方被坏人输入了脚本，那脚本还作为正常SQL的一部分被执行了呢？那就是拼装SQL字符串。

有的网站的后台程序将用户提交的数据（如查询条件）与SQL串的逻辑部分用字符串连接的方式拼装到一起，在正常的情况下，这能实现业务，但隐患就是，坏人可以在提交数据的地方，巧妙地编写一些代码，与你的SQL串逻辑部分拼装之后，结果仍然是形式上合法的SQL串，但其内容可能是毁灭性的，比如删除全表数据。

相对来说，SQL注入攻击的威胁更大，与之相比XSS和CSRF只算是癣疥之疾——太表皮，疼得不深入，而SQL注入则是腹心之疾。

但SQL注入防御起来极为简单：保证代码中不含有拼装SQL的代码就行了，一律采用参数化查询。

还是那句话，不给坏人这样的机会：把输入数据转为输入逻辑。

附：OWASP 2013年版的TOP 10 常见安全问题，点击阅读原文下载