Open yang-xianzhu opened 1 year ago
Cross-Site-Scripting（跨站脚本攻击）简称XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如Cookie、SeesionID等，进而危害数据安全。
为了和CSS区分，就把攻击的第一个字母改成了X，于是叫做了XSS。
XSS的本质是：恶意代码未经过滤，与网站正常代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。
而由于直接在用户的终端执行，恶意代码能够直接获取用户的信息，从而利用这些信息冒充用户向网站发起攻击者定义的请求。
在部分情况下，由于输入的限制，注入的恶意脚本比较短。但可以通过引入外部的脚本，并由浏览器执行，来完成比较复杂的攻击策略。
用户是通过哪种方法注入恶意脚本的呢？
注入
不仅仅是业务上的用户的UGC内容可以进行注入，包括URL上的参数等都可以是攻击的来源。在处理输入时，以下内容都不可信：
用户的UGC内容
根据攻击的来源，XSS攻击可分为存储型、反射型和DOM型三种。
存储型： 存储型XSS的攻击步骤：
这种攻击常见于带有用户保存数据的网站功能，比如论坛发帖、商品评论、用户私信等。
反射型： 反射型XSS的攻击步骤：
反射型XSS跟存储型XSS的区别是：存储型XSS的恶意代码存在数据库里，反射型XSS的恶意代码存在URL里。
反射型XSS漏洞常见于通过URL传递参数的功能，如网站的搜索、跳转等。
由于需要用户主动打开恶意的URL才能生效，攻击者往往在结合多种手段诱导用户点击。
POST的内容也可以触发反射型XSS，只不过其出发条件比较苛刻（需要构造表单提交页面，并诱导用户点击），所以非常少见。
DOM型XSS： DOM型XSS的攻击步骤：
DOM型XSS跟前两种XSS的区别：DOM型XSS攻击中，取出和执行恶意代码由浏览器端完成，属于前端JavaScript自身的安全漏洞，而其他两种XSS都属于服务端的安全漏洞。
XSS攻击有两大要素 ：
针对第一个要素：我们是否能够在用户输入的过程，过滤掉用户输入的恶意代码呢？
在用户提交时，由前端过滤输入，然后提交到后端。这样做是否可行？
答案：不可行。因为一旦攻击者绕开了前端过滤，直接构造请求，就可以提交恶意代码了。
那么，换一个过滤时机：后端在写入数据库前，对输入进行过滤，然后把安全的/消毒后的内容，返回给前端。这样做是否可行？
举个例子，一个正常用户输入了5 < 7这个内容，在写入数据库前，被转译了，变成了5 < 7。
5 < 7
5 < 7
问题是：在提交阶段，我们并不确定内容要输出到哪里。 这里的 "并不确定要输出到哪里"有两层含义：
escapeHTML()
所以，输入测过滤能够在某些情况下解决特定的XSS问题，但会引入很大的不确定性和乱码问题。在防范XSS攻击时应避免此类方法。 当然，对于明确的输入类型，例如数字、URL、电话号码、邮箱地址等等内容，进行输入过滤还是必要的。 既然输入过滤并非完全可靠，我们就要通过防止浏览器执行恶意代码来防范XSS。这部分分为两类：
防止浏览器执行恶意代码
存储型和反射型XSS都是在服务端取出恶意代码后，插入到响应HTML里的，攻击者刻意编写的"数据"被内嵌到"代码"中，被浏览器所执行。 预防这两种漏洞，有两种常见做法：
纯前端渲染的问题：
在纯前端渲染中，我们会明确的告诉浏览器：下面要设置的内容是文本(innterText)，还是属性(setAttribute)，还是样式(style)等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。
但纯前端渲染还需注意避免DOM型XSS漏洞(例如onLoad事件和href中的javascript:xxx)等。
onLoad
href
javascript:xxx
在很多内部、管理系统中，采用纯前端渲染是非常合适的，但对于性能要求高 ，或有SEO需求的页面，我们仍然要面对拼接HTML的问题。
如果拼接HTML是必要的，就需要采用合适的转义库，对HTML模版各处插入点进行充分的转义。 常用的模版引擎，如：doT.js、ejs、FreeMarker等，对于HTML转义通常只有一个规则，就是把& < > " ' /这几个字符转义掉，确实能起到一定的XSS防护作用，但并不完善。
& < > " ' /
DOM型XSS攻击，实际上就是网站前端JavaScript代码本身不够严谨，把不可信的数据当作代码执行了。 在使用innterHTML、outerHTML、document.write()时要特别小心，不要把不可信的数据作为HTML插入到页面上，而应尽量使用textContent、setAttribute()等。
innterHTML
outerHTML
document.write()
textContent
setAttribute()
如果使用的Vue/React技术栈，并且不使用v-html/dangerouslySetInnerHTML功能，就在前端render阶段避免innterHTML、outerHTML的XSS隐患。
v-html
dangerouslySetInnerHTML
DOM中的内联事件监听器，如location、onclick、onerror、onload、onmouseover等，<a>标签的href属性、JavaScript的eval()、setTimeout()、setInterval()、new Function()等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些API，很容易产生安全隐患。
location
onclick
onerror
onload
onmouseover
<a>
eval()
setTimeout()
setInterval()
new Function()
虽然在渲染页面和执行JavaScript时，通过谨慎的转义/消毒可以防止XSS的发生，但完全依靠开发的谨慎仍然是不够的。以下介绍一些通用的方案，可以降低XSS带来的风险和后果。
严格的CSP在XSS的防范中可以起到以下的作用：
对于不受信任的输入，都应该限定一个合理的长度。虽然无法完全防止XSS发生，但可以增加XSS攻击的难度。
XSS防范是后端的责任，后端应该在所有用户提交数据的接口，对敏感字符进行转义，才能进行下一步操作。
不正确。因为防范存储型和反射型XSS是后端的责任，而DOM型XSS攻击不发生在后端，是前端的责任。防范XSS是需要后端和前端共同参与的系统工程。转义应该在输出HTML时进行，而不是在提交用户信息输入时。
所有要插入到页面上的数据，都要通过一个敏感字符过滤函数的转义，过滤掉通用的敏感字符后，就可以插入到页面中。
不正确。不同的上下文，如HTML属性、HTML注释、跳转链接、内联JavaScript字符串、内联CSS样式表等，所需要的转义规则不一致。业务需要选取合适的转义库，并针对不同的上下文调用不同的转义规则。
整体的XSS防范是非常复杂和繁琐的，我们不仅需要在全部需要转义/消毒的位置，对数据进行对应的转义。而且要防止多余和错误的转义，避免正常的用户输入出现乱码。 虽然很难通过技术手段完全避免XSS，但我们可以总结以下原则减少漏洞的产生：
onload="onload('{{data}}')"
onClick="go('{{action}}')"
addEventlistener()
createElement
setAttribute
1、XSS
1.1 什么是 XSS
Cross-Site-Scripting（跨站脚本攻击）简称XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如Cookie、SeesionID等，进而危害数据安全。
为了和CSS区分，就把攻击的第一个字母改成了X，于是叫做了XSS。
XSS的本质是：恶意代码未经过滤，与网站正常代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。
而由于直接在用户的终端执行，恶意代码能够直接获取用户的信息，从而利用这些信息冒充用户向网站发起攻击者定义的请求。
在部分情况下，由于输入的限制，注入的恶意脚本比较短。但可以通过引入外部的脚本，并由浏览器执行，来完成比较复杂的攻击策略。
用户是通过哪种方法
注入恶意脚本的呢？不仅仅是业务上的
用户的UGC内容可以进行注入，包括URL上的参数等都可以是攻击的来源。在处理输入时，以下内容都不可信：1.2 XSS分类
根据攻击的来源，XSS攻击可分为存储型、反射型和DOM型三种。
存储型： 存储型XSS的攻击步骤：
这种攻击常见于带有用户保存数据的网站功能，比如论坛发帖、商品评论、用户私信等。
反射型： 反射型XSS的攻击步骤：
反射型XSS跟存储型XSS的区别是：存储型XSS的恶意代码存在数据库里，反射型XSS的恶意代码存在URL里。
反射型XSS漏洞常见于通过URL传递参数的功能，如网站的搜索、跳转等。
由于需要用户主动打开恶意的URL才能生效，攻击者往往在结合多种手段诱导用户点击。
POST的内容也可以触发反射型XSS，只不过其出发条件比较苛刻（需要构造表单提交页面，并诱导用户点击），所以非常少见。
DOM型XSS： DOM型XSS的攻击步骤：
DOM型XSS跟前两种XSS的区别：DOM型XSS攻击中，取出和执行恶意代码由浏览器端完成，属于前端JavaScript自身的安全漏洞，而其他两种XSS都属于服务端的安全漏洞。
XSS攻击的预防
XSS攻击有两大要素 ：
针对第一个要素：我们是否能够在用户输入的过程，过滤掉用户输入的恶意代码呢？
输入过滤
在用户提交时，由前端过滤输入，然后提交到后端。这样做是否可行？
答案：不可行。因为一旦攻击者绕开了前端过滤，直接构造请求，就可以提交恶意代码了。
那么，换一个过滤时机：后端在写入数据库前，对输入进行过滤，然后把安全的/消毒后的内容，返回给前端。这样做是否可行？
举个例子，一个正常用户输入了
5 < 7这个内容，在写入数据库前，被转译了，变成了5 < 7。问题是：在提交阶段，我们并不确定内容要输出到哪里。 这里的 "并不确定要输出到哪里"有两层含义：
escapeHTML()，客户端显示的内容就变成了转译后的代码(5 < 7)。5 < 7作为HTML拼接页面时，可以正常显示。5 < 7作为Ajax/fetch等请求返回，然后赋值给JavaScript的变量时，前端得到的字符串就是转义后的字符。这个内容不能直接用于Vue/React等模版的展示，也不能用于内容长度计算。不能用于标题等。所以，输入测过滤能够在某些情况下解决特定的XSS问题，但会引入很大的不确定性和乱码问题。在防范XSS攻击时应避免此类方法。 当然，对于明确的输入类型，例如数字、URL、电话号码、邮箱地址等等内容，进行输入过滤还是必要的。 既然输入过滤并非完全可靠，我们就要通过
防止浏览器执行恶意代码来防范XSS。这部分分为两类：预防存储型和反射型XSS攻击
存储型和反射型XSS都是在服务端取出恶意代码后，插入到响应HTML里的，攻击者刻意编写的"数据"被内嵌到"代码"中，被浏览器所执行。 预防这两种漏洞，有两种常见做法：
纯前端渲染
纯前端渲染的问题：
在纯前端渲染中，我们会明确的告诉浏览器：下面要设置的内容是文本(innterText)，还是属性(setAttribute)，还是样式(style)等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。
但纯前端渲染还需注意避免DOM型XSS漏洞(例如
onLoad事件和href中的javascript:xxx)等。在很多内部、管理系统中，采用纯前端渲染是非常合适的，但对于性能要求高 ，或有SEO需求的页面，我们仍然要面对拼接HTML的问题。
转义HTML
如果拼接HTML是必要的，就需要采用合适的转义库，对HTML模版各处插入点进行充分的转义。 常用的模版引擎，如：doT.js、ejs、FreeMarker等，对于HTML转义通常只有一个规则，就是把
& < > " ' /这几个字符转义掉，确实能起到一定的XSS防护作用，但并不完善。预防DOM型XSS攻击
DOM型XSS攻击，实际上就是网站前端JavaScript代码本身不够严谨，把不可信的数据当作代码执行了。 在使用
innterHTML、outerHTML、document.write()时要特别小心，不要把不可信的数据作为HTML插入到页面上，而应尽量使用textContent、setAttribute()等。如果使用的Vue/React技术栈，并且不使用
v-html/dangerouslySetInnerHTML功能，就在前端render阶段避免innterHTML、outerHTML的XSS隐患。DOM中的内联事件监听器，如
location、onclick、onerror、onload、onmouseover等，<a>标签的href属性、JavaScript的eval()、setTimeout()、setInterval()、new Function()等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些API，很容易产生安全隐患。其他XSS防范措施
虽然在渲染页面和执行JavaScript时，通过谨慎的转义/消毒可以防止XSS的发生，但完全依靠开发的谨慎仍然是不够的。以下介绍一些通用的方案，可以降低XSS带来的风险和后果。
Content Security Policy
严格的CSP在XSS的防范中可以起到以下的作用：
输入内容长度控制
对于不受信任的输入，都应该限定一个合理的长度。虽然无法完全防止XSS发生，但可以增加XSS攻击的难度。
其他安全措施
XSS攻击的总结
XSS防范是后端的责任，后端应该在所有用户提交数据的接口，对敏感字符进行转义，才能进行下一步操作。
所有要插入到页面上的数据，都要通过一个敏感字符过滤函数的转义，过滤掉通用的敏感字符后，就可以插入到页面中。
整体的XSS防范是非常复杂和繁琐的，我们不仅需要在全部需要转义/消毒的位置，对数据进行对应的转义。而且要防止多余和错误的转义，避免正常的用户输入出现乱码。 虽然很难通过技术手段完全避免XSS，但我们可以总结以下原则减少漏洞的产生：
onload="onload('{{data}}')"、onClick="go('{{action}}')"这种拼接内联事件的写法。在JavaScript中通过addEventlistener()事件绑定会更安全。createElement、setAttribute之类的方法实现。或者采用比较成熟的渲染框架，比如Vue/React等。