场景一：获取URL参数含有脚本执行

比如我们需要获取URL中某个参数，然后输出到页面当中
比如链接是http://xxx?search="><script>alert('xss')</script>这种，我们解析search参数拼接html的之后直接用了这个参数，这个时候浏览器不知道是恶意代码，直接就执行了，

<div>xxx: "><script>alert('xss')</script>
</div>

这样这个脚本就会在页面上执行，显示xss
如果是input属性，也会弹


<input type="text" value=""><script>alert('xss');</script>">

这是因为浏览器把参数当作脚本执行了，我么只需要告诉浏览器这个是文本就行了。

我们使用escapeHTML进行转义就可以了。这个方法原生没有，需要我们自己实现，转成html实体字符即可。

简单方法可以做一张实体转换表。

|&|&amp;| |<|&lt;| |>|&gt;| |"|&quot;| |'|&#x27;| |/|&#x2F;|

经过转移后在html中成为这种形式，

&quot;&gt;&lt;script&gt;alert(&#x27;XSS&#x27;);&lt;&#x2F;script&gt;

这样就可以在浏览器中显示了，也能不会当作脚本去执行。
总结如下：

通常页面中包含的用户输入内容都在固定的容器或者属性内，以文本的形式展示。
攻击者利用这些页面的用户输入片段，拼接特殊格式的字符串，突破原有的限制，形成了代码片段
攻击者通过在目标网站上注入脚本，使之在用户的浏览器上运行，从而引发潜在风险
通过html转义，就可以防范此类风险

场景2：html特殊属性、JavaScript API

我们如果拿URL中参数去设置到a的href属性，也会有安全风险。
比如
http://xxx?redirectTo=javascript:alert('xss')。
我们拿到这个redirectTo参数设置到了页面的a标签href属性，就成了

<a href="javascript:alert(&#x27;XSS&#x27;)">跳转...</a>

这样用户一点击a标签的时候就会弹出万恶的xss。
所以不仅仅是特殊字符script，连JavaScript这种也是，出现在特殊位置也会出现xss攻击。

如果我们URL判断如果不是JavaScript开头呢，但是如果输入的是JAvascript,也会中招，

我们可能会想着先小写在判断，但是攻击者往前面加了%20，其实是个空格的转义，这样又会执行被攻击。

所以最好的办法是采用白名单，判断是不是http开头或者https开头的才能通过，

场景3:JSON内嵌到html中

<script>var initData = <%= data.toJSON() =%></script>

插入json的地方不能用html转义，因为json的"会被破坏，导致不能使用。
但是json也是不安全的

当json中包含U+2028或U+2029这两个字符的时候，不能作为JavaScript的字面量使用，否则会抛出语法错误。
当JSON中包含字符串</script>时，当前的script标签将会被闭合，后面的字符串内容浏览器会按照html进行解析，通过增加下一个<script>标签等方法完成注入，
于是我们又要实现一个转义JSON的函数，对内联JSON进行转义。

|U+2028|\u2028| |U+2029|\u2029| |<|\u003c|

利用这个表对特殊字符进行转义显示，
例如代码<script>var initData = <%= escapeEmbedJSON(data.toJSON()) %></script>
总结如下：

html转义时比较复杂的，在不同情况下要使用不能的转移规则，
应当避免自己写转义库，而应当采用成熟，业界通用的转义库。

漏洞总结

我们总结一下xss有哪些注入的方法

在html中内嵌的文本中，恶意内容以script标签形成注入
在内联的Javascript中，拼接的数据突破了原本的限制（字符串，变量，方法名等）
在标签属性中，恶意内容包含引号，从而突破属性限制，注入其他属性或者标签
在标签的href、src等属性中，包含JavaScript:等可执行代码
在onload、onError、onClick等事件中，注入不受控制的代码
在style属性和标签中，包含类似background-image: url("javascript:console.log(1)");新版浏览器已经可以防范
在style属性和标签中，包含类似expression()的css表达式代码，新版浏览器已经可以防范

xss攻击的分类

什么是xss

cross-site Scripting（跨站脚本攻击）简称XSS，是一种代码攻击。攻击者通过在目标网站注入恶意脚本，使之在用户的浏览器上运行，利用这些恶意脚本，攻击者可获取用户的敏感信息如cookie、sessionId等，进而危害数据安全。

为了和CSS区分，我们把攻击的第一个字母改成了X，于是叫做XSS。

XSS的本质是：恶意代码未经过滤，与正常代码混在一起，浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行

而由于直接在用户的终端执行。恶意代码能够获取用户信息，或者利用这些信息冒充用户向网站发起攻击

在部分情况下，由于输入长度的限制，注入的恶意脚本比较短，但可以通过引入外部的脚本，并由浏览器执行，来完成比较复杂的攻击策略。

那么用户是通过哪种方式完成的注入呢？
不仅仅是用户ugc内容可以注入，包括url的参数都可以是攻击的来源。在处理时，以下内容都不可信

来自用户的ugc信息
来自第三方的链接
URL参数
POST参数
Referer(可能来自不可信的来源）
Cookie（可能来自其他子域注入）

xss分类

根据攻击的来源可以分为存储型、反射型和DOM型3种。

类型	存储区	插入点
存储型 XSS	后端数据库	HTML
反射型 XSS	URL	HTML
DOM 型 XSS	后端数据库/前端存储/URL	前端 JavaScript

存储区：恶意代码存放的位置
插入点：由谁取得恶意代码，并插入到网页上

存储型XSS

存储型XSS攻击步骤

攻击者将恶意代码提交到目标网站的数据库中
用户打开目标网站时，网站服务端将恶意代码从数据库中取出，并拼接在html中返回给浏览器
用户浏览器接收到影响后解析执行，混在其中的恶意代码也被执行
恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标接口执行攻击者指定的操作
这种攻击常见于带有用户保存数据的网站功能，如论坛发帖，商品评论，用户私信等。

反射型XSS

反射型XSS的攻击步骤：

攻击者构造出特殊的URL，其中包含恶意代码
用户打开带有恶意代码的URL时，网站服务端将恶意代码从URL中取出，拼接在html中返回给浏览器
用户浏览器接受到响应解析执行，混在其中的恶意代码也被执行
恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作
反射型XSS和存储型XSS的区别是：存储型XSS的恶意代码存在数据库中，反射型XSS恶意代码存在URL中。
反射型XSS漏洞常见于通过URL传递参数的功能，如网站搜索，跳转等。
由于需要用户主动打开恶意的URL才能生效，攻击者往往会结合多种手段诱导用户点击。

POST的内容也可以触发发射型XSS，只不过其触发条件比较苛刻（需要构造表单，并引导用户提交）所以不常见

DOM型XSS

攻击步骤

攻击者构造出特殊的URL，其中包含恶意代码
用户打开带有恶意代码的URL
用户浏览器接受到响应后解析执行，前端JavaScript取出URL中的恶意代码并执行
恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作
DOM型XSS和前两种的区别：DOM型XSS攻击中，取出和执行恶意代码由浏览器端完成，属于前端JavaScript自身的漏洞，而其他两种都属于服务端的安全漏洞

XSS攻击的预防

通过前面的介绍我们知道XSS攻击两大要素：

攻击者恶意提交代码
浏览器执行恶意代码
针对第一个要素，我们要在用户输入阶段进行过滤

输入过滤

在用户提交时，由前端过滤输入，然后提交到后端，这样做是否可行呢？
答案是不可行，一旦攻击者绕过前端直接让后端发送请求，就挂了。
那么换一个过滤时机，后端在写入数据库之前进行过滤，然后把安全的内容返回给前端，这样可以吗？
假设一个正常的用户输入了5 < 7这个内容，在写入数据库前，被转义，变成了5 < 7
问题是，我们并不知道这个内容将要输出到哪里展示

输入的内容可能同时提供给前端和客户端，而一旦经过html转义，到了客户端就变成了5 < 7乱码了
在前端中，不同位置的编码也不一样，
- 当5 < 7作为html拼接页面时，可以正常显示
- 当5 < 7通过ajax返回时，然后赋值给JavaScript变量时，前端得到的字符就是转义后的字符，这个内容不能直接用于自己vue等模版的展示，也不能用户内容长度的计算，不能用于标题和alert等。
  所以，输入侧过滤能够在某些情况下解决特定的xss问题，但是会引入更大的不确定性和乱码问题，在防范xss攻击时应避免此方法。

当然，对于明确的输入类型，例如数字、URL、电话号码、邮件地址等内容，进行输入过滤有必要。

既然输入过滤并非完全可靠，我们就要通过防止浏览器执行恶意代码来防范xss，分为两类

防止html中出现注入
防止JavaScript执行时，执行恶意代码

预防存储型和反射型XSS攻击

存储型和反射型都是在服务端取出恶意代码后，插入到响应html里，攻击者恶意写的数据被内嵌到代码中，被浏览器所执行
预防这两种漏洞，有两种常见的做法

改成纯前端渲染，把代码和数据分开
对html做充分转义

纯前端渲染

纯前端渲染过程

浏览器先夹在一个静态的html，此html中不包含任何根业务相关的数据
然后浏览器执行html中的JavaScript
JavaScript通过ajax加载业务数据，调用dom api渲染到页面上
在纯前端渲染的时候，我们会明确的告诉浏览器，下面要设置的内容是文本的（.innerText)，还是属性(.setAttribute)，还是样式(.style)等等。浏览器不会轻易的被欺骗，执行预期以外的代码了。

但纯前端渲染还需注意DOM型xss，例如onload事件和href中的JavaScript:xxx，等，请参考下文预防DOM型XSS。

在很多内部管理系统中，采用纯前端渲染师非常合适的，但对于性能要求比较高，或者有SEO需要的页面，我们仍然要面对拼接html的问题。

转义html

如果拼接html是必要的，就需要采用合适的转义库进行，对html模版各个插入点进行转义

常用的模版引擎，如ejs等，对html通常只有一个规则，就是把& < > " ’ / 这几个字符转义掉。确实能起到一定作用。但不完善。

XSS 安全漏洞	简单转义是否有防护作用
HTML 标签文字内容	有
HTML 属性值	有
CSS 内联样式	无
内联 JavaScript	无
内联 JSON	无
跳转链接	无

所以要完善xss防护措施，我们要采用专门的库来解决。

预防DOM型XSS攻击

DOM型XSS攻击，实际就是网站前端不严谨，把不可信的数据当作代码执行了。
在使用.innerHTML、outHTML、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

其他xss防范措施

虽然在渲染页面和执行JavaScript时，通过谨慎的转移可以防止xss的发生，但是完全靠开发的谨慎值不够，还有一些通用方案来防范

Content Security Policy

禁止加载外域代码，防止复杂的攻击
禁止外域提交，网站被攻击后，用户的数据不会泄露到外域
禁止内联脚本执行（比较严格）
禁止未授权的脚本执行
合理使用上报可以及时发现XSS利于尽快修复问题

输入内容长度限制

虽然不能完全阻止，但是能大大降低风险

其他安全措施

http-only cookie：禁止JavaScript读某些敏感cookie
验证码，防止脚本冒充用户提交危险操作

xss检测

使用xss攻击字符串检测
使用扫描工具进行检测

xss漏洞原因以及如何应对相关推荐

版本帝 GitLab 连发五版，应对 XSS 漏洞
GitLab 8.17.0-rc2 .8.16.5.8.15.6.8.14.9 和 8.17.0-rc3 发布了.GitLab 是一个利用 Ruby on Rails 开发的开源应用程序,实现一个自托 ...
xss攻击突破转义_每个人都应该了解的7种xss漏洞
在阅读有关XSS的材料时,我们通常会看到经典的<script> alert(1)</ script>作为这种漏洞的证明(PoC –概念证明).虽然是正确的,但它并没有超出此范围 ...
反射型XSS漏洞详解
反射型XSS漏洞如果一个应用程序使用动态页面向用户显示错误消息,就会造成一种常见的XSS漏洞.通常,该页面会使用一个包含消息文本的参数,并在响应中将这个文本返回给用户.对于开发者而言,使用这种机制 ...
windows系统和linux系统可以使用相同的js代码吗_使用Sboxr自动发现和利用DOM（客户端）XSS漏洞...
这一系列的博客文章将向你展示如何在单页或富JavaScript的应用程序上识别DOM XSS的问题.作为示例,我们将在DOM XSS playground(https://domgo.at)上解决10 ...
ecshop pages.lbi.php,关于Ecshop pages.lbi.php Xss漏洞的修复
前段时间在用ecshop建站的时候,360报警说出现了严重的漏洞:Ecshoppages.lbi.phpXss漏洞==============================我是分割线======== ...
网站安全之XSS漏洞攻击以及防范措施
在网站开发中,安全问题是重中之重的问题,特别像一个sql注入,XSS漏洞攻击,等的防范,如果不做好,网站将存在很大的隐患 XSS漏洞是网站漏洞中最容易出现的一种,至少现在的各大网站中基本都存在,传闻只 ...
php 其他页面获取session_PHP安全：XSS漏洞防御
一次性付费进群,长期免费索取教程,没有付费教程. 进微信群回复公众号:微信群:QQ群:460500587 教程列表见微信公众号底部菜单 | 本文底部有推荐书籍微信公众号:计算机与网络安全 I ...
url存在宽字节跨站漏洞_【XSS漏洞】XSS漏洞相关总结v1.0
点击上方"公众号" 可以订阅哦! Hello,各位小伙伴周五晚上好~ 终于到了XSS漏洞的完结篇啦~~ 感觉本公众号写的最多的就是XSS,现在可以告一段落了... 让我们来看看第一 ...
xss漏洞学习心得（泪目）
XSS学习心得大杂烩背景 xss的定义 xss漏洞的分类 xss绕过技巧payload 常见的有: 绕过payload 背景领导给了我一些资产让我去测试,发现其中藏有不少的xss漏洞,含泪做一个总 ...

xss漏洞原因以及如何应对