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
在基础速成后 ,我们可以 基本了解下网站信息 , 我们一般使用浏览器的开发者模式进行调试:
在了解上述的基本原理后,我们可以学习我们的主题漏洞, 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®ion=qrnq7&s=%22/%3E%3Csvg%20onload=alert(1)%3E//=prompt(1)&text=xm5n2&tid=hnh7q&type=vbvx9&uid=imn31
查找搜索触发点, 这里简单说就是get接收的参数被带入了js中执行,这里使用了//
来过滤一些标签的操作
那么在反射XSS中,一个大致的攻击流程如下:
比如下面这个某社交平台的的,我们就可以吧用户敏感数据发送到我们的恶意服务器中,或者制作成为蜜罐。
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用户电脑卡死(前端问题估计是,搞崩溃了)。
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 - 配合打出利用链接
- 记录敏感信息 - 跨域资源共享 配合蜜罐信息
- 配合用于其他漏洞
修复方式
- 过滤特殊字符(<> = “ ” ‘ ‘), 总会有绕过方法的
- 使用HTML实体编码 ,推荐
- 使用框架语言自带的函数或者规则库进行过滤
4. 进阶
在了解基本后,这节课基本就算完成了,但是如果想更进一步,就需要了解更多,下面的是我的一些简单记录
4.1 富文本编辑器造成的 XSS
富文本编辑器比如ueditor
会提html编写方式,在用户限制不严格的情况下就会造成XSS问题 , 常用语普通用户获取管理员账号cookie信息等操作。
在就就是markdown文本编辑模式,也会造成XSS问题,比如在某站存在的问题
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/ # 注入类问题
就可以根据脚本语言特性搜索,寻找到一些问题
5. 参考文章 && 靶场
参考学习
靶场
- 版权声明: 本博客所有文章除特别声明外,均采用「 知识共享署名4.0 」创作共享协议,转载请注明作者及原网址。