1. 背景 - 基础知识

某安全培训资料 - 我不是专业讲师，很多地方可能讲解的并不精确，欢迎大家指出错误。主要目的为让大家了解基本的安全知识，能够处理或者看懂简单的安全问题。

目前互联网基础设施可以分为B/S架构 ， C/S架构 等等，都要有一个基础的划分， 前端和后端 ，两者可以进行拆分和耦合

前端： html css javascript 主要是展示用于可见的界面（广义可见就为前端网站，APP用户界面，小程序等等）
后端： java php .net golang 主要是用于功能处理，任务调度，也可以理解为用于“动态”的处理网页

1.1 协议报文

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。

关于http协议，这里我们要了解一些基础的功能，比如下面是一个常见的请求包，这是在我们尝试登陆智能预填单登陆账号的请求报文：

POST /ipsapp/LoginCheckOpeningHours HTTP/1.1
Host: ips.yillionbank.com
Cookie: sensorsdata2015jssdkcross=%7B%22distinct_id%22%3A%221831160f7d894f-0b7afa739a9551-16303676-1764000-1831160f7d944e%22%2C%22first_id%22%3A%22%22%2C%22props%22%3A%7B%22%24latest_traffic_source_type%22%3A%22%E7%9B%B4%E6%8E%A5%E6%B5%81%E9%87%8F%22%2C%22%24latest_search_keyword%22%3A%22%E6%9C%AA%E5%8F%96%E5%88%B0%E5%80%BC_%E7%9B%B4%E6%8E%A5%E6%89%93%E5%BC%80%22%2C%22%24latest_referrer%22%3A%22%22%7D%2C%22%24device_id%22%3A%221831160f7d894f-0b7afa739a9551-16303676-1764000-1831160f7d944e%22%7D; TS01b5893e=010851e24e69324e7e4a21aecbdcdc8a626ed3d4775e1c52c6385889474997f1fbba0bd5aac1fe153e2ec0aef53e09a7b2387e338c
Accept: application/json, text/plain, */*
Content-Type: application/json;charset=UTF-8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.5195.102 Safari/537.36
Sec-Ch-Ua-Platform: "macOS"
Origin: https://ips.yillionbank.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://ips.yillionbank.com/
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close

{"K1":"o3w3QlajH5RFlv74hZ69XVKkQAehET8+RUdKL28yGaV2sml3mBJO80Yn16efPxKQ42aaLVdjj65uFzngGcqpuw==","K2":"d3a3daa808a492d25c407ff2b2df7623", "K3":" h5 "}

在上文的http请求信息中，我们需要大致了解这些内容：

POST   #http请求模式 GET POST HEAD PUT OPTIONS DELET CONNECT TRACE 共八种 我们暂时只需要了解 GET POST
/ipsapp/LoginCheckOpeningHours#网址路由，请求资源的路径，服务器根据请求的路由跳转到相应的资源，也就是MVC模式
Host   # 请求头指明了请求将要发送到的服务器主机名和端口号 默认省略80 
Cookie # 用户身份凭证 ， Cookie存储在客户端
User-Agent # 浏览器头信息
Origin # 请求标头 Origin 表示了请求的来源（协议、主机、端口）。
			 # 该首部用于 CORS 请求或者 POST 请求。
			 # 用于 CORS: 当我们的浏览器发出跨站请求时，服务器会校验当前请求是不是来自被允许的站点。服务器就是通过    Origin 字段的值来进行判断。 这里可以在后免的同源策略会细讲解
Referer # Referer 首部包含了当前请求页面的来源页面的地址，即表示当前页面是通过此来源页面里的链接进入的。
        # 也会进行一定的身份验证，比如在 https://ips.yillionbank.com/#/login 中就会进行 Referer 验证
session # 用户身份凭证 ，与cookie不同是存储在服务器中的

当然，如果看到这里感觉并不理解，建议先学习下计算机网络基础中的http ，web 相关内容后，再进行学习。

1.2 浏览器的同源策略

同源策略是一个重要的安全策略，它用于限制一个origin的文档或者它加载的脚本如何能与另一个源的资源进行交互。它能帮助阻隔恶意文档，减少可能被攻击的媒介。比如在一个最基本的网址，是由以下几点构成的。

https:// www.yillionbank.com  :80     /page/main.html
 协议         主域名            端口       路由

这里就涉及到一个问题，网站之间难免涉及数据交互的问题，那么我们就需要一个规定，来规定什么样的数据可以进行交互，什么样子的数据不能交互，能进行交互数据的，我们可以称之为同源

比如在下文的URL网址中，和 https://yillionbank.com/login 的关系如下

URL	结果	原因
https://yillionbank.com/login/whoa	同源	路径不同，可以请求到资源
http://ips.yillionbank.com/login	不同源	子域名与主域名不同
https://yillionbank.com:23456	不同源	端口不同
https://yillionbanks.com/login	不同源	域名不同

但是在一些情况下，我们确实还需要一些资源数据在不同源网站之间交互，或者限制一些静态资源（图片，文件）等读取操作，因此在 跨源资源嵌入（Cross-origin embedding）方面一般是被允许的 , 再就是一些特殊规则，可以进行跨域资源访问，其中常见的方式如下：

常见的可跨域的HTML标签有：script、img、audio、video、embed、iframe、link(css)等
<link rel="stylesheet" href="..."> 标签嵌入 CSS 的操作
JSONP跨域：原理：浏览器不会限制script标签读取远程JS文件，客户端发出请求，浏览器动态生成JS文件内容然后返回，客户端再根据预规定的处理逻辑进行处理即可 ( 子瑜域名跨平台信息传输，接口传送信息 )
CORS(跨域资源共享)：跨源资源共享 (CORS) （或通俗地译为跨域资源共享）是一种基于HTTP 头的机制（是CORS是HTTP的一部分），该机制通过允许服务器标示除了它自己以外的其它origin（域，协议和端口），这样浏览器可以访问加载这些资源。
```
# 原理：服务端在响应头中添加Access-Control-Allow-Origin字段标识允许跨域访问的origin，例如
# 这是返回包信息
Access-Control-Allow-Origin: * 允许所有源访问
Access-Control-Allow-Origin: http://example.com 仅允许执行源访问
```

在设置请求配置不当的情况下，就会导致 跨域资源共享 和 敏感信息泄漏的问题，在安全比较常见的就是被做成了蜜罐。比如下面的信息就是利用XSS漏洞加上Referer绕过验证, 主要是获取用户信息

POST /cas/check HTTP/1.1
Host: 某SRC
Connection: close
Content-Length: 82
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: 某SRC
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://某SRC/cas/logins?domain=iask.sina.com.cn&businessSys=iask&channel=null&popup=show&clsId=undefined&fid=%22%3E%3Cscript%3Eeval(name)%3C/script%3E
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

sceneId=1618718932006_39_iask&domain=某SRC&channel=null&clsId=undefined

另一个的蜜罐，经典的jsonp泄漏信息

GET /client.action?functionId=getBabelProductPaged&body=%7b%22%73%65%63%6f%6e%64%54%61%62%49%64%22%3a%22%30%30%31%35%35%35%35%34%37%30%38%39%33%5f%30%33%37%32%36%36%30%30%5f%22%2c%22%74%79%70%65%22%3a%22%30%22%2c%22%70%61%67%65%4e%75%6d%22%3a%22%31%22%2c%22%6d%69%74%65%6d%41%64%64%72%49%64%22%3a%22%22%2c%22%67%65%6f%22%3a%7b%22%6c%6e%67%22%3a%22%22%2c%22%6c%61%74%22%3a%22%22%7d%2c%22%61%64%64%72%65%73%73%49%64%22%3a%22%22%2c%22%70%6f%73%4c%6e%67%22%3a%22%22%2c%22%70%6f%73%4c%61%74%22%3a%22%22%2c%22%66%6f%63%75%73%22%3a%22%22%2c%22%69%6e%6e%65%72%41%6e%63%68%6f%72%22%3a%22%22%7d&screen=2799*1208&client=wh5&clientVersion=1.0.0&sid=&uuid=&area=&_=1585823068850&callback=jsonp1 HTTP/1.1
Host: 某SRC
Connection: close
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Accept: */*
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: script
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

1.2 关于 html 与 Javascript

基础语法建议自学下先 , 速成下就行，我们可以简单理解 html是构成前端页面的骨架， JS让前端拥有了一定的动态能力和更多的方法。当然，JS也是可以用于后端的。

html ： https://www.w3schools.com/html/
javascript : https://www.javascript.com/learn/strings

在基础速成后，我们可以基本了解下网站信息，我们一般使用浏览器的开发者模式进行调试：

XssLearning

在了解上述的基本原理后，我们可以学习我们的主题漏洞， XSS了。

2. 关于 XSS

Cross-Site Scripting（跨站脚本攻击）简称XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息或者做出敏感操作，进而危害数据安全。目前XSS主要被划分为三个类型：

DOM型XSS：将代码注入到HTML的DOM节点中，也算是一种“反射型XSS”
反射型XSS：点击一次执行一次，不具有持久性(不会存储在数据库服务器或者前端代码中)，常用于制作钓鱼链接
存储型XSS：代码持久在系统中，用户访问了还有恶意代码的页面及被攻击，危害性最大

简单说，就是利用前端的Javascript代码可控，从而进行一定的危害性行为的操作，但是我们在日常测试中也不能做一些过于危害性的行为，因此往往使用弹窗的行为来作为危害行为的表现方式（尤其是开发同学，XSS的修复方式不是过滤alert！，比如我弹个计算器，你总不能把计算器拉入黑名单吧）。

<script> alert(1) </script>  # 弹窗测试漏洞存在					
<script>alert?.(document?.cookie)</script> # 弹cookie
<script>document.location.href="http://www.yillionbank.com.com"</script>  # 劫持跳转

当然利用方法远远不止这些，也可以监控键盘记录，截屏，获取位置信息，配合其他漏洞造成SSRF，CSRF，信息泄漏等等操作。

2.1 反射XSS

xss 漏洞寻找，我们可以寻找一切能进行用户输入的地方进行测试，甚至抓包修改不能输入的参数，再就是审计JS代码找一些接口信息。简答来说就是寻找一切输入：签名，API，图片上传名，httpheader，等等等等。

在了解基本的漏洞查找后，再根据我们之前了解的前后端原理，可以这么做一个大致的理解，简单说，我们植入的请求并不会存储在服务器，而是根据JS反馈在前端页面上，这用攻击利用方式较为局限，主要表现需要点击触发。这里找个国外例子：

## 反射案例
http://www.mobileheroes.io/?a=r361t&b=k5kpd&c=ts6pi&callback=jrlsv&d=v0642&debug=j24y7&e=bj0u2&from=vxs68&g=yd8cv&h=wj779&hatw-selector=fyyz5&i=vsp89&j=nag82&m=b009x&mod=mdlre&page=l07kd&q=h066g&region=qrnq7&s=%22/%3E%3Csvg%20onload=alert(1)%3E//=prompt(1)&text=xm5n2&tid=hnh7q&type=vbvx9&uid=imn31

XssLearning

查找搜索触发点，这里简单说就是get接收的参数被带入了js中执行，这里使用了//来过滤一些标签的操作

XssLearning

那么在反射XSS中，一个大致的攻击流程如下：

XssLearning

比如下面这个某社交平台的的，我们就可以吧用户敏感数据发送到我们的恶意服务器中，或者制作成为蜜罐。

https://m.iask.xxxx.com.cn/cas/logins?domain=iask.xxxxx.com.cn&businessSys=iask&channel=null&popup=show&clsId=undefined&fid=wwww

再就是最经典的，盗号行为，比如登陆QQ空间，盗号等等。

2.2 存储 XSS

存储XSS触发点可会更加的多样化，比如WEB端不触发手机端触发，浏览器模式不同触发，接口API信息触发，甚至A网站的功能存在问题在B网站触发等等。

和反射型XSS不同，存储XSS 的恶意payload 信息存储在服务器上，可以永久性质的触发，利用方式更为简单，效果更佳。

这里举例子我挖到的一个腾讯的存储XSS ，在腾讯文档中的思维导图功能，插入如下恶意的 payload （经过了一些编码这里方便看就没写），输入点是一个标签的描述内容，描述内容本来没有输入点，但是可以抓包进行修改，修改内容如下：

<iframe src=\"javascript:alert(1)\"></iframe>

直接触发问题，利用这个XSS ，我们就可以达到一些恶意攻击行为和效果，再就是这个还有个小bug，可以直接吧MAC用户电脑卡死（前端问题估计是，搞崩溃了）。

XssLearning

2.3 DOM型XSS

也是属于反射XSS的一种在我看来，主要是js代码在本地生成造成的注入，比如在这个例子中，js“动态”的吧xxx替换成了yyyyy

<div id="a">xxx</div>
<script> document.getElementById("a").innerHTML="yyyyyy";
</script>

因此，在操作不当的情况下，就会导致问题，这里举个例子

<html>
<head>
        <title>DOM XSS</title>
        <meta charset="utf-8">
</head>
<body>
        <div id="area"></div>
        <script>
                document.getElementById("area").innerHTML = unescape(location.hash); //location.hash函数要从uri中的#
        </script>
</body>
</html>
XML 复制 全屏

访问触发问题

http://192.168.2.147/DOMxss.html#<img src=x onerror='alert(/xss/)'>

3. 危害 && 修复方式

XSS真正的危害是JS任意代码执行，当前端JS可控的情况下，我们可以造成很多危害

盗取cookie登陆账号 - QQ 微博等等
暗链/SEO - 黑产暗链
CSRF/SSRF - 配合打出利用链接
记录敏感信息 - 跨域资源共享配合蜜罐信息
配合用于其他漏洞

XssLearning

修复方式

过滤特殊字符（<> = “ ” ‘ ‘）, 总会有绕过方法的
使用HTML实体编码，推荐
使用框架语言自带的函数或者规则库进行过滤

4. 进阶

在了解基本后，这节课基本就算完成了，但是如果想更进一步，就需要了解更多，下面的是我的一些简单记录

4.1 富文本编辑器造成的 XSS

富文本编辑器比如ueditor会提html编写方式，在用户限制不严格的情况下就会造成XSS问题，常用语普通用户获取管理员账号cookie信息等操作。

在就就是markdown文本编辑模式，也会造成XSS问题，比如在某站存在的问题

XssLearning

4.2 常见的一些 bypass 方式

XSS 由于特征相对简单也很容易被检测到，因此基本还要进行一定的bypass , 其中常见的方式如下：

%27-window[%27\x61\x6c\x65\x72\x74%27](1)-%27 # 使用编码绕过
<svg onload=alert(1)>    # 利用特殊标签
<svg/onload =[]['pu'+'sh']['const'+'ructor']('ale'+'rt(1)')``> # 这个就说来话长了，得从JS特性讲起来
<iframe src="javascript:alert(1)"></iframe>  # 伪协议利用

除此之外之外还有二次渲染， CSP过滤绕过等等。

4.3 基于 Code Search 发现XSS问题

搜索简单的XSS漏洞：感觉后续的一些PHP危险函数之类的也可以使用这种方式进行搜索排查

"echo $_GET['"   # XSS 类问题
language:php  /SELECT \* FROM.*\$_GET/   # 注入类问题

就可以根据脚本语言特性搜索，寻找到一些问题

XssLearning

5. 参考文章 && 靶场

参考学习

靶场

本文作者： shangzeng
版权声明： 本博客所有文章除特别声明外，均采用「知识共享署名4.0 」创作共享协议，转载请注明作者及原网址。

[培训课程系列]常见漏洞类型XSS介绍

1. 背景 - 基础知识

1.1 协议报文

1.2 浏览器的同源策略

1.2 关于 html 与 Javascript

2. 关于 XSS

2.1 反射XSS

2.2 存储 XSS

2.3 DOM型XSS

3. 危害 && 修复方式

4. 进阶

4.1 富文本编辑器造成的 XSS

4.2 常见的一些 bypass 方式

4.3 基于 Code Search 发现XSS问题

5. 参考文章 && 靶场