XSS
Cross-Site Scripting (跨站脚本攻击)简称XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使其在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如Cookie、SessionID等，进而危害数据安全。
1.XSS的本质是：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本执行。
2.由于直接在用户的终端执行，恶意代码能够直接获取用户的信息，或者利用这些信息冒充用户向网站发起攻击者定义的请求。
3.在部分情况下，由于输入的限制，注入的恶意脚本比较短。但可以通过引入外部的脚本，并由浏览器执行，来完成比较复杂的攻击策略。
XSS注入方式
- 在
HTML中内嵌的文本中，恶意内容以script标签形成注入。 - 在内联的
JavaScript中，拼接的数据突破了原本的限制（字符串，变量，方法名等）。 - 在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签。
- 在标签的
href、src等属性中，包含javascript:等可执行代码。 - 在
onload、onerror、onclick等事件中，注入不受控制代码。 - 在
style属性和标签中，包含类似background-image:url("javascript:...");的代码（新版本浏览器已经可以防范）。 - 在 style 属性和标签中，包含类似
expression(...)的 CSS 表达式代码（新版本浏览器已经可以防范）。
总之，如果开发者没有将用户输入的文本进行合适的过滤，就贸然插入到 HTML 中，这很容易造成注入漏洞。攻击者可以利用漏洞，构造出恶意的代码指令，进而利用恶意代码危害数据安全。
2、XSS攻击的分类
根据攻击的来源，XSS 攻击可分为存储型、反射型和 DOM 型三种。
（1）存储型XSS
存储型 XSS 的攻击步骤：
- 攻击者将恶意代码提交到目标网站的数据库中。
- 用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
- 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
- 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。
（2）反射型XSS
反射型 XSS 的攻击步骤：
- 攻击者构造出特殊的
URL，其中包含恶意代码。 - 用户打开带有恶意代码的
URL时，网站服务端将恶意代码从URL中取出，拼接在HTML中返回给浏览器。 - 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
- 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。
反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。
由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。
POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。
（3）DOM型XSS
DOM 型 XSS 的攻击步骤：
- 攻击者构造出特殊的
URL，其中包含恶意代码。 - 用户打开带有恶意代码的
URL。 - 用户浏览器接收到响应后解析执行，前端
JavaScript取出URL中的恶意代码并执行。 - 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，不需要服务器解析响应的直接参与，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。
对比表格
XSS攻击类型 |
存储位置 | 插入点 |
|---|---|---|
存储型XSS |
后端数据库 | HTML |
反射型XSS |
URL |
HTML |
DOM型XSS |
后端数据库/前端存储/URL |
前端JavaScript |
XSS攻击的防御措施
（1）输入过滤
只要有输入数据的地方，就存在XSS攻击，XSS攻击就有两大因素：
- 攻击者提交恶意代码
- 浏览器执行恶意代码
所以，防御措施主要从这两个方面下手：
针对用户输入过程
在用户输入过程中，前端过滤输入的恶意代码，然后再提交给后端，这是不可行的，攻击者完全可以绕过前端过滤，直接构造请求提交恶意代码。
对于明确的输入类型，例如数字、URL、电话号码、邮件地址等等内容，进行输入过滤是必要的。
所以不仅需要前端对输入的格式进行格式检查，然后后端做相关的过滤检查。
针对浏览器执行恶意代码
输入过滤不是万全之策，那就要防止浏览器执行恶意代码，这个分为两步进行：
- 防止
HTML中出现注入 - 防止
JavaScript执行时，执行恶意代码
（2）预防存储型和反射型XSS攻击
存储型和反射型 XSS 都是在服务端取出恶意代码后，插入到响应 HTML 里的，攻击者刻意编写的“数据”被内嵌到“代码”中，被浏览器所执行。
预防这两种漏洞，有两种常见做法：
- 纯前端渲染，代码和数据分离
- 转义
HTML
1）纯前端渲染
纯前端渲染的过程：
- 浏览器先加载一个静态
HTML，此HTML中不包含任何跟业务相关的数据 - 然后浏览器执行
HTML中的JavaScript JavaScript通过Ajax加载业务数据，调用DOM API更新到页面上
在纯前端渲染中，会明确的告诉浏览器：下面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式（.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。
但纯前端渲染还需注意避免 DOM 型 XSS 漏洞（例如 onload 事件和 href 中的 javascript:xxx 等，请参考下文”预防 DOM 型 XSS 攻击“部分）。
在很多内部、管理系统中，采用纯前端渲染是非常合适的。但对于性能要求高，或有 SEO 需求的页面，我们仍然要面对拼接 HTML 的问题。
2）转义HTML
如果拼接 HTML 是必要的，就需要采用合适的转义库，对 HTML 模板各处插入点进行充分的转义。
常用的模板引擎，如 doT.js、ejs、FreeMarker 等，对于 HTML 转义通常只有一个规则，就是把 & < > " ' / 这几个字符转义掉，确实能起到一定的 XSS 防护作用，但并不完善：
|XSS 安全漏洞|简单转义是否有防护作用| |-|-| |HTML 标签文字内容|有| |HTML 属性值|有| |CSS 内联样式|无| |内联 JavaScript|无| |内联 JSON|无| |跳转链接|无|
所以要完善 XSS 防护措施，我们要使用更完善更细致的转义策略。
（3）预防DOM型XSS攻击
DOM 型 XSS 攻击，实际上就是网站前端 JavaScript 代码本身不够严谨，把不可信的数据当作代码执行了。
在使用 .innerHTML、.outerHTML、document.write() 时要特别小心，不要把不可信的数据作为 HTML 插到页面上，而应尽量使用 .textContent、.setAttribute() 等。
如果用 Vue/React 技术栈，并且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端 render 阶段避免 innerHTML、outerHTML 的 XSS 隐患。
DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等，<a> 标签的 href 属性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必避免。
-
<!-- 内联事件监听器中包含恶意代码 -->
-
-
-
<!-- 链接内包含恶意代码 -->
-
<a href="UNTRUSTED">1
</a>
-
<script>
-
// setTimeout()/setInterval() 中调用恶意代码
-
setTimeout(
"UNTRUSTED")
-
setInterval(
"UNTRUSTED")
-
-
// location 调用恶意代码
-
location.href =
'UNTRUSTED'
-
-
// eval() 中调用恶意代码
-
eval(
"UNTRUSTED")
-
</script>
（4）其他防御措施
虽然在渲染页面和执行 JavaScript 时，通过谨慎的转义可以防止 XSS 的发生，但完全依靠开发的谨慎仍然是不够的。以下介绍一些通用的方案，可以降低 XSS 带来的风险和后果。
1）Content Security Policy
严格的 CSP 在 XSS 的防范中可以起到以下的作用：
- 禁止加载外域代码，防止复杂的攻击逻辑。
- 禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。
- 禁止内联脚本执行（规则较严格，目前发现
GitHub使用）。 - 禁止未授权的脚本执行（新特性，
Google Map移动版在使用）。 - 合理使用上报可以及时发现
XSS，利于尽快修复问题。
2）输入内容长度控制
对于不受信任的输入，都应该限定一个合理的长度。虽然无法完全防止 XSS 发生，但可以增加 XSS 攻击的难度。
3）其他
HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此Cookie- 验证码：防止脚本冒充用户提交危险操作
- 白名单: 对于显示富文本来说，不能通过上面的办法来转义所有字符，因为这样会把需要的格式也过滤掉。这种情况通常采用白名单过滤的办法，当然也可以通过黑名单过滤，但是考虑到需要过滤的标签和标签属性实在太多，更加推荐使用白名单的方式
XSS攻击检测
两种方法：
（1）使用通用 XSS 攻击字符串手动检测 XSS 漏洞
jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e这个字符串能够检测到存在于 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等多种上下文中的 XSS 漏洞，也能检测 eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write() 等 DOM 型 XSS 漏洞，并且能绕过一些 XSS 过滤器。
只要在网站的各输入框中提交这个字符串，或者把它拼接到 URL 参数上，就可以进行检测了。
http://xxx/search?keyword=jaVasCript%3A%2F*-%2F*%60%2F*%60%2F*%27%2F*%22%2F**%2F(%2F*%20*%2FoNcliCk%3Dalert()%20)%2F%2F%250D%250A%250d%250a%2F%2F%3C%2FstYle%2F%3C%2FtitLe%2F%3C%2FteXtarEa%2F%3C%2FscRipt%2F--!%3E%3CsVg%2F%3CsVg%2FoNloAd%3Dalert()%2F%2F%3E%3E（2）使用扫描工具自动检测 XSS 漏洞
常见自动扫描工具寻找 XSS 漏洞，例如 Arachni、Mozilla HTTP Observatory、w3af 等
5、XSS攻击简单总结
- 防御存储型和反射型
XSS是后端的责任。而DOM型XSS是前端 的责任。防御XSS是需要后端和前端共同参与的系统工程 - 转义应该在输出
HTML时进行，而不是在提交用户输入时 - 不同的上下文，如
HTML属性、HTML文字内容、HTML注释、跳转链接、内联JavaScript字符串、内联CSS样式表等，所需要的转义规则不一致。 业务 需要选取合适的转义库，并针对不同的上下文调用不同的转义规则 - 不仅需要在全部需要转义的位置，对数据进行对应的转义。而且要防止多余和错误的转义，避免正常的用户输入出现乱码
-
总结以下原则减少漏洞的产生：
-
利用模板引擎 ：开启模板引擎自带的
HTML转义功能。例如：- 在
ejs中，尽量使用<%= data %>而不是<%- data %> - 在
doT.js中，尽量使用{ {! data }而不是{ {= data } - 在
FreeMarker中，确保引擎版本高于 2.3.24，并且选择正确的freemarker.core.OutputFormat
- 在
- 避免内联事件： 尽量不要使用
onLoad="onload('{ {data}}')"、onClick="go('{ {action}}')"这种拼接内联事件的写法。在JavaScript中通过.addEventlistener()事件绑定会更安全 - 避免拼接 HTML ：前端采用拼接
HTML的方法比较危险，如果框架允许，使用createElement、setAttribute之类的方法实现。或者采用比较成熟的渲染框架，如Vue/React等 - 时刻保持警惕 ：在插入位置为
DOM属性、链接等位置时，要打起精神，严加防范 - 增加攻击难度，降低攻击后果 ：通过
CSP、输入长度配置、接口安全措施等方法，增加攻击的难度，降低攻击的后果 - 主动检测和发现： 可使用
XSS攻击字符串和自动扫描工具寻找潜在的XSS漏洞
-
在开始本文之前，我们先提出一个问题，请判断以下两个说法是否正确：
1.XSS 防范是后端 RD（研发人员）的责任，后端 RD 应该在所有用户提交数据的接口，对敏感字符进行转义，才能进行下一步操作。
2.所有要插入到页面上的数据，都要通过一个敏感字符过滤函数的转义，过滤掉通用的敏感字符后，就可以插入到页面中。
如果你还不能确定答案，那么可以带着这些问题向下看，我们将逐步拆解问题。
XSS 漏洞的发生和修复
XSS 攻击是页面被注入了恶意的代码，为了更形象的介绍，我们用发生在小明同学身边的事例来进行说明。
一个案例
某天，公司需要一个搜索页面，根据 URL 参数决定关键词的内容。小明很快把页面写好并且上线。代码如下：
-
< input type = "text" value = "
<%= getParameter(" keyword ") %>
">
-
< button > 搜索
</ button >
-
< div >
-
您搜索的关键词是：
< %= getParameter (" keyword ") %>
-
</ div >
-
然而，在上线后不久，小明就接到了安全组发来的一个神秘链接：
http://xxx/search?keyword="><script>alert('XSS');</script>
小明带着一种不祥的预感点开了这个链接 [请勿模仿，确认安全的链接才能点开] 。果然，页面中弹出了写着"XSS"的对话框。
可恶，中招了！小明眉头一皱，发现了其中的奥秘：
当浏览器请求 http://xxx/search?keyword="><script>alert('XSS');</script> 时，服务端会解析出请求参数 keyword，得到 "><script>alert('XSS');</script>，拼接到 HTML 中返回给浏览器。形成了如下的 HTML：
-
< input type = "text" value = "" >
< script > alert( 'XSS' );
</ script > ">
-
< button > 搜索
</ button >
-
< div >
-
您搜索的关键词是：">
< script > alert( 'XSS' );
</ script >
-
</ div >
浏览器无法分辨出 <script>alert('XSS');</script> 是恶意代码，因而将其执行。
这里不仅仅 div 的内容被注入了，而且 input 的 value 属性也被注入， alert 会弹出两次。
面对这种情况，我们应该如何进行防范呢？
其实，这只是浏览器把用户的输入当成了脚本进行了执行。那么只要告诉浏览器这段内容是文本就可以了。
聪明的小明很快找到解决方法，把这个漏洞修复：
-
< input type = "text" value = "
<%= escapeHTML(getParameter(" keyword ")) %>
">
-
< button > 搜索
</ button >
-
< div >
-
您搜索的关键词是：
< %= escapeHTML ( getParameter (" keyword ")) %>
-
</ div >
-
escapeHTML() 按照如下规则进行转义：
|字符|转义后的字符|
|-|-|
|&|&|
|<|<|
|>|>|
|"|"|
|'|'|
|/|/|
经过了转义函数的处理后，最终浏览器接收到的响应为：
-
< input type = "text" value = ""><script>alert('XSS');</script>" >
-
< button > 搜索
</ button >
-
< div >
-
您搜索的关键词是：
"
>
<script
>alert(
'XSS
');
<
/script
>
-
</ div >
恶意代码都被转义，不再被浏览器执行，而且搜索词能够完美的在页面显示出来。
通过这个事件，小明学习到了如下知识：
通常页面中包含的用户输入内容都在固定的容器或者属性内，以文本的形式展示。
攻击者利用这些页面的用户输入片段，拼接特殊格式的字符串，突破原有位置的限制，形成了代码片段。
攻击者通过在目标网站上注入脚本，使之在用户的浏览器上运行，从而引发潜在风险。
通过 HTML 转义，可以防止 XSS 攻击。 [事情当然没有这么简单啦！请继续往下看]
大家想必都听过xss攻击，那么这个xss到底是如何攻击、我们又应该如何防范的呢？
xss攻击主要是针对表单的input文本框发起的，比如有这样一个文本框：
xss攻击图1
在说明一栏填入一段js代码，如果前端不进行过滤直接提交到后端（比如php），而php端也没有进行过滤直接入库，那么在下一个展示页面，就会发生这样的情况：
xss攻击图2
为什么会酱紫呢？
因为我们在说明这一栏的input，会将后端返回的内容直接追加进去，导致js代码执行。
可能有同学会不屑一顾：
你弹个框又能怎样呢？大不了我关了就是了呗！
那假设是cookie这样的敏感信息呢？我们不妨来做个试验：
xss攻击图3
执行代码：
xss攻击图4
这样就可以获取到一个用户的cookie了。那再进一步，如果把所有的cookie都想办法弄出来，然后存到自己的库里面的话。。。
想想挺带劲的哈，咱们不妨动手搞一下。
我们可以直接注入这样一段js脚本：
xss攻击图5
这段脚本呢，我就直接这么搞：
xss攻击图6
您别误会，我的本意不是创建一个图片，而是利用图片的src跨域属性，直接把cookie的值，传送到我的php后端代码里面，接下来就可以入库了哈哈~~
by the way，将图片的宽高设置为0，用户是不会看到这个图片的，因此这段js一旦注入生效，所有的用户都会触发这个js，从而将自己的cookie源源不断的输送到我的php代码中。
二、防范
好了，原理有了一定的了解之后，接下来就是如何防范了。
问题的源头在于js代码的注入，我们可以想个办法，不让js生效不就行了？
大家要注意两头的防范：
1）输入。
在提交表单时，前端最好将文本内容转为html实体编码，也就是过滤掉<script>、<a>、这样的内容，然后再提交到后台去。当然保险起见，后台也要再做一遍html实体转码，然后再入库。
2）输出。
在显示文本内容时，最好也要做一次html实体编码转换后再显示，防止<script>标签生效
转载：https://blog.csdn.net/qq_32766999/article/details/117161229