[TOC]

XSS 攻击

XSS全称是跨站脚本攻击(Cross Site Scripting),为了和重叠样式表CSS区分,换了另一个缩写XSS。
XSS攻击的核心是将可执行的前端脚本代码(一般为JavaScript)植入到网页中,通常指的是通过利用网页开发时留下的漏洞,注入恶意指令代码到网页,使用户加载并执行攻击者恶意制造的网页程序。
这些恶意网页程序通常是JavaScript,但也存在Java、 VBScript、ActiveX、 Flash 或者甚至是普通的HTML代码。一旦攻击成功后,攻击者可能得到一些用户或管理员权限(权限上不封顶)

那我们来聊聊攻击者是如何办到的呢?
一般XSS攻击分为两种:反射型和存储型

反射型

攻击者将JS代码作为请求参数放置URL中,诱导用户点击,落入陷阱
image.png

比如这个,攻击者首先将JS代码作为请求参数放置URL中,诱导用户点击

http://localhost:8080/test?name=

等用户点击后,该JS就会作为请求参数传给Web服务器后端。如果后端服务器没有很完善的检查过滤,就会简单处理后放入网页正文中返回给浏览器,等浏览器解析返回的网页后,用户已经中招了!

存储型

上面反射型攻击脚本直接经服务器,转手后返回浏览器触发执行
存储型和它的区别在于能够将攻击脚本入库存储,在后面进行查询时,再将攻击脚本渲染进网页,返回给浏览器触发执行
image.png

举个例子
XSS攻击就好比攻击者在某网页论坛中回复一个帖子,帖子中包含JS脚本,回帖提交服务器后,就会存储至数据库。其他网友查看这个帖子后,后台会自动查询该帖子的回帖内容,然后构建出完整网页,返回浏览器。此时,该网友浏览器渲染返回的网页已经中招!该网友的浏览器已经变成了靶子。

XSS漏洞的挖掘

黑盒测试

尽可能找到一切用户可控并且能够输出在页面代码中的地方,比如下面这些:

  • URL的每一个参数
  • URL本身
  • 表单
  • 搜索框

白盒测试(代码审计)

关于XSS的代码审计主要就是从接收参数的地方和一些关键词入手。
PHP中常见的接收参数的方式有$_GET、$_POST、$_REQUEST等等,可以搜索所有接收参数的地方。然后对接收到的数据进行跟踪,看看有没有输出到页面中,然后看输出到页面中的数据是否进行了过滤和html编码等处理。

也可以搜索类似echo这样的输出语句,跟踪输出的变量是从哪里来的,我们是否能控制,如果从数据库中取的,是否能控制存到数据库中的数据,存到数据库之前有没有进行过滤等等。
大多数程序会对接收参数封装在公共文件的函数中统一调用,我们就需要审计这些公共函数看有没有过滤,能否绕过等等。

常见业务场景

  • 重灾区:评论区、留言区、个人信息、订单信息等
  • 针对型:站内信、网页即时通讯、私信、意见反馈
  • 存在风险:搜索框、当前目录、图片属性等

XSS的防御

XSS防御的总体思路是:对用户的输入(和URL参数)进行过滤,对输出进行html编码。也就是对用户提交的所有内容进行过滤,对url中的参数进行过滤,过滤掉会导致脚本执行的相关内容;然后对动态输出到页面的内容进行html编码,使脚本无法在浏览器中执行。
对输入的内容进行过滤,可以分为黑名单过滤和白名单过滤。黑名单过滤虽然可以拦截大部分的XSS攻击,但是还是存在被绕过的风险。白名单过滤虽然可以基本杜绝XSS攻击,但是真实环境中一般是不能进行如此严格的白名单过滤的。
对输出进行html编码,就是通过函数,将用户的输入的数据进行html编码,使其不能作为脚本运行。

XSS防范方法(Java开发)

1. 防堵跨站漏洞

阻止攻击者利用在被攻击网站上发布跨站攻击语句不可以信任用户提交的任何内容,首先代码里对用户输入的地方和变量都需要仔细检查长度和对”<”,”>”,”;”,”’”等字符做过滤;其次任何内容写到页面之前都必须加以encode,避免不小心把html tag 弄出来。这一个层面做好,至少可以堵住超过一半的XSS 攻击。

2. Cookie 防盗

首先避免直接在cookie 中泄露用户隐私,例如email、密码等等。其次通过使cookie 和系统ip 绑定来降低cookie 泄露后的危险。这样攻击者得到的cookie 没有实际价值,不可能拿来重放。

3. 尽量采用POST 而非GET 提交表单

POST 操作不可能绕开javascript 的使用,这会给攻击者增加难度,减少可利用的跨站漏洞。

4. 严格检查refer

检查http refer 是否来自预料中的url。这可以阻止第2 类攻击手法发起的http 请求,也能防止大部分第1 类攻击手法,除非正好在特权操作的引用页上种了跨站访问。

5. 将单步流程改为多步,在多步流程中引入效验码

多步流程中每一步都产生一个验证码作为hidden 表单元素嵌在中间页面,下一步操作时这个验证码被提交到服务器,服务器检查这个验证码是否匹配。
首先这为第1 类攻击者大大增加了麻烦。其次攻击者必须在多步流程中拿到上一步产生的效验码才有可能发起下一步请求,这在第2 类攻击中是几乎无法做到的。

6. 引入用户交互

简单的一个看图识数可以堵住几乎所有的非预期特权操作。

7. 只在允许anonymous 访问的地方使用动态的javascript

8. 对于用户提交信息的中的img 等link,检查是否有重定向回本站、不是真的图片等可疑操作

9. 内部管理网站的问题

很多时候,内部管理网站往往疏于关注安全问题,只是简单的限制访问来源。这种网站往往对XSS 攻击毫无抵抗力,需要多加注意。安全问题需要长期的关注,从来不是一锤子买卖。XSS 攻击相对其他攻击手段更加隐蔽和多变,和业务流程、代码实现都有关系,不存在什么一劳永逸的解决方案。此外,面对XSS,往往要牺牲产品的便利性才能保证完全的安全,如何在安全和便利之间平衡也是一件需要考虑的事情。

web应用开发者注意事项

1.对于开发者,首先应该把精力放到对所有用户提交内容进行可靠的输入验证上。
这些提交内容包括URL、查询关键字、http头、post数据等。只接受在你所规定长度范围内、采用适当格式、你所希望的字符。阻塞、过滤或者忽略其它的任何东西。
2.保护所有敏感的功能,以防被bots自动化或者被第三方网站所执行。
实现session标记(session tokens)、CAPTCHA系统或者HTTP引用头检查。
3.如果你的web应用必须支持用户提供的HTML,那么应用的安全性将受到灾难性的下滑。
但是你还是可以做一些事来保护web站点:确认你接收的HTML内容被妥善地格式化,仅包含最小化的、安全的tag(绝对没有JavaScript),去掉任何对远程内容的引用(尤其是样式表和JavaScript)。