Web安全-跨站脚本攻击XSS

跨站脚本攻击XSS

跨站脚本攻击（XSS），是目前最普遍的Web应用安全漏洞。这类漏洞能够使得攻击者嵌入恶意脚本代码到正常用户会访问到的页面中，当正常用户访问该页面时，则可导致嵌入的恶意脚本代码的执行，从而达到恶意攻击用户的目的。

跨站

简单来说，如果有一个网站，希望网站中所有运行的逻辑都来自本站。如果运行了别的网站的脚本，就产生了跨站脚本攻击。

XSS攻击原理

攻击者向有XSS漏洞的网站中输入(传入)恶意的HTML代码，当用户浏览该网站时，这段HTML代码会自动执行，从而达到攻击的目的。如，盗取用户Cookie信息、破坏页面结构、重定向到其它网站等。

XSS能做什么

• 获取页面数据
• 获取Cookie信息
• 截取前端逻辑
• 发送请求
• 偷取网站任意数据
• 偷取用户资料
• 偷取用户密码和登录态
• 欺骗用户
• 等等…

XSS攻击类型

• 反射型：攻击代码直接由url参数注入，页面直接执行了注入的代码
  • 通过将攻击的url转为短网址，可以屏蔽脚本信息，攻击更加隐蔽
• 存储型：XSS代码会被保存到网站的数据中，如数据库，在其他用户访问到这条记录时，这条攻击代码会被读取出来，显示在页面上。（危害性更大）

XSS攻击注入点

• HTML节点内容：节点内容是动态生成，包含用户输入的信息
• HTML属性：节点属性如果由用户输入信息组成
• Javascript代码：由用户输入信息组成
• 富文本：由用户输入信息组成

基本上页面内容，由用户输入信息动态生成，都可能存在XSS攻击。

HTML节点内容

<div>
    #{content}
</div>
//XSS攻击
<div>
    <script>
       alert(1)
    </script>
</div>

HTML属性

<img src="#{image}"/>
//提前关闭src属性 注入攻击代码：1" onerror="alert(1)
<img src="1" onerror="alert(1)"/>

Javascript代码

<script>
    var data = "#{data}";
    //提前关闭data变量 注入攻击代码：hello"; alert(1);"
    var data = "hello"; alert(1);""
</script>

富文本

• 富文本得保留HTML
• HTML有XSS攻击风险

浏览器自带防御

• X-XSS-Protection：通过设置响应头处理XSS攻击
• 只能处理反射型攻击类型， url参数出现在HTML节点内容或HTML属性中
• Content-Security-Policy：允许站点管理者控制用户代理能够为指定的页面加载哪些资源。这将帮助防止跨站脚本攻击（Cross-Site Script）

语法

X-XSS-Protection: 0 // 表示关闭浏览器的XSS防护机制
X-XSS-Protection: 1 // 启用XSS过滤（通常浏览器是默认的）。 如果检测到跨站脚本攻击，浏览器将清除页面（删除不安全的部分）
X-XSS-Protection: 1; mode=block // 启用XSS过滤。 如果检测到攻击，浏览器将不会清除页面，而是阻止页面加载。
X-XSS-Protection: 1; report=<reporting-uri> // 启用XSS过滤。 如果检测到跨站脚本攻击，浏览器将清除页面并使用CSP report-uri指令的功能发送违规报告。

//默认会拦截XSS攻击
The XSS Auditor refused to execute a script in 'http://localhost/?from=%3Cscript%3Ealert(1)%3C/script%3E' because its source code was found within the request. The auditor was enabled as the server did not send an 'X-XSS-Protection' header.

HTML节点内容防御方法

将 < > 尖括号进行转义，替换成html字符实体。

• 将< 转义为 &lt;
• 将 > 转义为&gt;

<div>
    #{content}
</div>
//XSS攻击
<div>
    <script>
       alert(1)
    </script>
</div>

var escapeHtml = function (str) {
    if (!str) return ''
    str = str.replace(/</g, '&lt;');//处理 <
    str = str.replace(/>/g, '&gt;');//处理 >
    return str;
}

HTML属性防御方法

由于引号，将属性提前关闭了，所以需要进行转义。

• 将” 转义为&quto;。
• 将’ 转义为&#39;。
• 将 转义为&nbsp;：属性没有引号情况下，转义空格。

<img src="#{image}"/>
//提前关闭src属性 注入攻击代码：1" onerror="alert(1)
<img src="1" onerror="alert(1)"/>
//属性没有引号
<img src=1 onerror=alert(1) />

var escapeHtmlProperty = function (str) {
    if (!str) return ''
    str = str.replace(/"/g, '&quto;');//处理 "
    str = str.replace(/'/g, ''');//处理 '
    str = str.replace(/ /g, ' ');//处理空格
    return str;
}

HTML节点内容，HTML属性防御方法

var escapeHtmlAndProperty = function (str) {
    if (!str) return ''
    str = str.replace(/&/g, '&');//处理 & 需要放在最前面 一般不需要处理
    str = str.replace(/</g, '&lt;');//处理 <
    str = str.replace(/>/g, '&gt;');//处理 >
    str = str.replace(/"/g, '&quto;');//处理 "
    str = str.replace(/'/g, '&#39;');//处理 '
    //处理空格 由于html内容中，多个连续的空格，在渲染时只会产生一个空格，将空格全部转为&nbsp;（html实体）可能显示存在问题，一般情况下，空格不进行转义。基于这种情况，必须确保属性带上引号，否则不能处理属性没有引号情况下的XSS攻击
    // str = str.replace(/ /g, '&nbsp;');
    return str;
}

Javascript代码防御方法

• 将 “ 转义为 \“
• 转换成josn（推荐）

<script>
    var data = "#{data}";
    //提前关闭data变量 注入攻击代码：hello"; alert(1);"
    var data = "hello"; alert(1);""
</script>

//不完善的方法
var escapeForJs = function (str) {
    if (!str) return ''
    str = str.replace(/\\/g, '\\\\');//将\ 转义为\\
    str = str.replace(/"/g, '\\"');//将" 转义为\"
    return str;
}

//转换成josn
var escapeForJsJson = function (str) {
    if (!str) return ''
    return JSON.stringify(str)
}

富文本防御方法

• 使用黑名单过滤，过滤不符合要求的标签和属性。实现相对简单，只需要按照正则表达式过滤。但是html是非常庞大，繁杂的，有太多的标签和属性，容易忽略，产生漏洞
• 使用白名单，保留部分标签和属性。过滤比较彻底，只允许指定的标签，属性存在。但是实现比较麻烦，需要将html完全解析成树状结构，针对这个dom树，遍历它的元素，保留白名单中的标签和属性，其他的过滤掉。过滤完之后，再组装成html。

使用黑名单过滤

//需要过滤javascript
<a href="javascript:alert(1)">点击</a>

//需要过滤script
<script>
    alert(2);sssss;
</script>

//通过黑名单过滤
var xssFilter = function (html) {
    if (!html) return ''
    html = html.replace(/<\s*\/?script\s*>/g, '');//将script转义为空
    html = html.replace(/javascript[^'"]*/g, '');//将javascript转义为空
    return html
}

使用白名单过滤

• 使用cheerio处理XSS攻击
  • 解析html，对标签，属性进行过滤，最终返回html，需要自己维护，完善白名单列表
• 使用js-xss处理XSS攻击

//使用白名单处理富文本
const cheerio = require('cheerio')
var xssFilter3 = function (html) {
	if (!html) return ''
	const $ = cheerio.load(html)

	//定义白名单 需要进行维护，完善该名单
	const whiteList = {
		'img': ['src'],//标签名：属性列表
    }
    //过滤标签属性
	$('*').each((index, elem) => {
		//标签不存在白名单中 直接移除
		if (!whiteList[elem.name]) {
			$(elem).remove();
			return;
		}
		// //标签在白名单中 处理属性
		for (let attr in elem.attribs){
			if(whiteList[elem.name].indexOf(attr)===-1){
				//移除属性
				$(elem).attr(attr,null)
			}
		}
    })
    //返回过滤后的标签属性
	return $.html()
}

防御 XSS 攻击

• HttpOnly 防止劫取 Cookie
• 用户的输入检查
• 服务端的输出检查
• 使用js-xss处理XSS攻击

CSP

HTTP 响应头Content-Security-Policy（内容安全策略）允许站点管理者控制用户代理能够为指定的页面加载哪些资源，可以指定哪些内容可以执行。这将帮助防止跨站脚本攻击（Cross-Site Script）（XSS）。

内容安全策略CSP) 是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本 (XSS) 和数据注入攻击等。无论是数据盗取、网站内容污染还是散发恶意软件，这些攻击都是主要的手段。

启用CSP

• 服务器响应头添加 Content-Security-Policy 来指定规则
• HTML 中 <meta> 元素也可以被用来配置该策略

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

制定策略

你可以使用 Content-Security-Policy HTTP头部 来指定你的策略，像这样:

// policy参数是一个包含了各种描述你的CSP策略指令的字符串。
Content-Security-Policy: policy

更多策略指令

更多策略指令

描述策略

一个策略由一系列策略指令所组成，每个策略指令都描述了一个针对某个特定类型资源以及生效范围的策略。你的策略应当包含一个default-src策略指令，在其他资源类型没有符合自己的策略时应用该策略。一个策略可以包含 default-src 或者 script-src 指令来防止内联脚本运行, 并杜绝eval()的使用。 一个策略也可包含一个 default-src 或 style-src 指令去限制来自一个 <style> 元素或者style属性的內联样式。

常见用例

• 示例 1：一个网站管理者想要所有内容均来自站点的同一个源 (不包括其子域名)

  Content-Security-Policy: default-src 'self'

• 示例 2：一个网站管理者允许内容来自信任的域名及其子域名 (域名不必与CSP设置所在的域名相同)

  Content-Security-Policy: default-src 'self' *.trusted.com

• 示例 3：

  • 一个网站管理者允许网页应用的用户在他们自己的内容中包含来自任何源的图片, 但是限制音频或视频需从信任的资源提供者(获得)，所有脚本必须从特定主机服务器获取可信的代码.

  • 在这里，各种内容默认仅允许从文档所在的源获取, 但存在如下例外:

    • 图片可以从任何地方加载(注意 “*” 通配符)。
    • 多媒体文件仅允许从 media1.com 和 media2.com 加载(不允许从这些站点的子域名)。
    • 可运行脚本仅允许来自于userscripts.example.com。

    Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com

• 示例 4：

  • 一个线上银行网站的管理者想要确保网站的所有内容都要通过SSL方式获取，以避免攻击者窃听用户发出的请求。
  • 该服务器仅允许通过HTTPS方式并仅从onlinebanking.jumbobank.com域名来访问文档。

    Content-Security-Policy: default-src https://onlinebanking.jumbobank.com

• 示例 5：

  • 一个在线邮箱的管理者想要允许在邮件里包含HTML，同样图片允许从任何地方加载，但不允许JavaScript或者其他潜在的危险内容(从任意位置加载)。
  • 注意这个示例并未指定script-src。在此CSP示例中，站点通过 default-src 指令的对其进行配置，这也同样意味着脚本文件仅允许从原始服务器获取。

    Content-Security-Policy: default-src 'self' *.mailsite.com; img-src *

更多案例说明

更多案例说明

对策略进行测试

为降低部署成本，CSP可以部署为报告(report-only)模式。在此模式下，CSP策略不是强制性的，但是任何违规行为将会报告给一个指定的URI地址。此外，一个报告模式的头部可以用来测试一个修订后的未来将应用的策略而不用实际部署它。

你可以用Content-Security-Policy-Report-Only HTTP 头部来指定你的策略，像这样：

Content-Security-Policy-Report-Only: policy

如果Content-Security-Policy-Report-Only 头部和 Content-Security-Policy 同时出现在一个响应中，两个策略均有效。在Content-Security-Policy 头部中指定的策略有强制性 ，而Content-Security-Policy-Report-Only中的策略仅产生报告而不具有强制性。

支持CSP的浏览器将始终对于每个企图违反你所建立的策略都发送违规报告，如果策略里包含一个有效的report-uri 指令。

启用违例报告

默认情况下，违规报告并不会发送。为启用发送违规报告，你需要指定 report-uri 策略指令，并提供至少一个URI地址去递交报告：

Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi

然后你需要设置你的服务器能够接收报告，使其能够以你认为恰当的方式存储并处理这些报告。

违例报告的语法

作为报告的JSON对象报告包含了以下数据：

• document-uri：发生违规的文档的URI。
• referrer：违规发生处的文档引用（地址）。
• blocked-uri：被CSP阻止的资源URI。如果被阻止的URI来自不同的源而非文档URI，那么被阻止的资源URI会被删减，仅保留协议，主机和端口号。
• violated-directive：违反的策略名称。
• original-policy：在 Content-Security-Policy HTTP 头部中指明的原始策略。

违例报告样本

我们假设页面位于 http://example.com/signup.html。它使用如下策略，该策略禁止任何资源的加载，除了来自cdn.example.com的样式表。

Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports

signup.html 的HTML像这样：

<!DOCTYPE html>
<html>
  <head>
    <title>Sign Up</title>
    <link rel="stylesheet" href="css/style.css">
  </head>
  <body>
    ... Content ...
  </body>
</html>

你能看出其中错误吗？样式表仅允许加载自cdn.example.com，然而该页面企图从自己的源 (http://example.com) 加载。当该文档被访问时，一个兼容CSP的浏览器将以POST请求的形式发送违规报告到 http://example.com/_/csp-reports，内容如下：

{
  "csp-report": {
    "document-uri": "http://example.com/signup.html",
    "referrer": "",
    "blocked-uri": "http://example.com/css/style.css",
    "violated-directive": "style-src cdn.example.com",
    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
  }
}

如你所见，该报告在blocked-uri字段中包含了违规资源的完整路径 ，但情况并非总是如此。比如，当signup.html试图从 http://anothercdn.example.com/stylesheet.css 加载CSS时，浏览器将不会包含完整路径，而只会保留源路径 (http://anothercdn.example.com)。CSP技术规范对此古怪行为给出了解释。大体上说，这样是为了防止泄露跨域资源的敏感信息。

参考

• 内容安全策略
• Web前后端漏洞分析与防御
• Content-Security-Policy