我的Web运用安全含糊测验之路
什么是Web运用中的含糊测验？
Web运用是根据什么进行传输的？HTTP协议。
含糊测验是什么？Payload随机。
Payload放哪里？HTTP恳求报文格局是什么？恳求行(恳求办法 URI HTTP/1.1)、恳求头、恳求报文主体(POST Data)。
含糊测验秘籍->增(Add) && 删(Del)
被固化的测验思想
我列出一个恳求，边看边考虑你会怎样测验这个恳求呢？
HTTP恳求报文(Request)：
GET /uc/getInfo HTTP/1.1
Host: gh0st.cn
Origin: http://gh0st.cn
...
HTTP呼应主体(Response Content):
{
    "id": "1024",
    "realName": "yudan",
    "mobilePhone": "13888888888",
    "cardNo": "111111111111111111"
}
看到这想必你现已知道自己要测验的内容是什么了，一般来讲许多人会先留意Origin这个HTTP恳求报文头，看呼应的HTTP头：
...
Access-Control-Allow-Origin: http://gh0st.cn
Access-Control-Allow-Crdentials: True
Access-Control-Allow-Methods: OPTION, POST, GET
...
假如我修正Origin的值为http://qianan.cn，回来的也是Access-Control-Allow-Origin: http://qianan.cn，那就代表着这儿存在CORS跨域资源共享(恣意域)的问题，详细在这儿就不多说了参阅我之前的一篇文章：http://gh0st.cn/archives/2019-03-22/1
这儿或许会有什么匹配之类的验证，一般的两种绕过办法：
1.子域名(http://{domain}.mst.cn/ -> http://gh0st.cn.mst.cn/)
2.域名前缀(http://{a-z}{domain} -> http://agh0st.cn/)
或许到这儿部分人的测验现已Over了～那么我还会持续测验下去，怎么测？往下看↓
含糊测验之增
增 – 入门
调查呼应报文格局：
{
    "id": "1024",
    "realName": "yudan",
    "mobilePhone": "13888888888",
    "cardNo": "111111111111111111"
}
这儿的格局为 *** ON格局，那么跟 *** ON有关的缝隙最早想到的是什么？
没错， *** ONP跨域绑架（想科普下？看这儿-> http://gh0st.cn/archives/2019-03-22/1）。
*** ONP跨域绑架需求具有的条件是回调参数，而这儿并没有，没有回调参数，那我就添加一个回调参数，如下是我的一份字典：

运用BurpSuite的Intruder模块，进行枚举测验：
GET /uc/getInfo?callback=mstkey HTTP/1.1
GET /uc/getInfo?cb=mstkey HTTP/1.1
GET /uc/getInfo?jsonp=mstkey HTTP/1.1
...
总算某一条恳求得到了我想要的成果：
mstkey({"id":"1024","realname":"yudan","mobilePhone":"13888888888","cardNo":"111111111111111111"})
那在这儿我就能够构建PoC了：
script>function mstkey(data){alert( *** ON.stringify(data));}script>
script src="http://gh0st.cn/uc/getInfo?callback=mstkey">script>
增 – 进阶
除了上面所说的添加回调参数以外，还能够添加什么呢？

添加的参数和值能够剖析网站数据、相关网站数据、整合自用字典与网站字段结合。
呼应报文转化：
{
    "id": "1024",
    "realName": "yudan",
    "mobilePhone": "13888888888",
    "cardNo": "111111111111111111"
}
转化为HTTP恳求参数 键=值 格局：
id=1024
realName=yudan
mobilePhone=13888888888
cardNo=111111111111111111
初度之外还有什么？当然是运用自用字典和如上总结的进行整合：

留意一点，参数都整理好之后，对应的值选用B账号的对应值，由于这样才会有差异，才干进行剖析是否存在相关的缝隙，一般加参数会存在越权问题～
增 – 深化
许多小伙伴挖缝隙的时分中心事务挖不动那必定怼一些边际事务和一些后台体系了，大多数人应该都遇见过这样的问题，找到了一个后台的地址点进去是办理界面，忽然的有js跳转到登录界面去了，可是检查页面代码却能获取到许多的后台接口～
许多人会挑选登录爆炸、未授权接口运用这些惯例操作类型去测验，或许测完就会抛掉了，而我之前测验某项意图时分碰见的便是当我在接口后边加上admin=1的时分呼应报文回来了这样的头：
Set-Cookie: xxxxxx=xxxxxxx
给我设置了一个Cookie，我运用这个Cookie直接就进入了后台。

含糊测验之删
在这儿有一处实践场景：

其流程是这样的：输入邮箱->点击修正邮箱->发送修正链接到该邮箱->邮箱翻开修正链接->成功修正

[1] [2]  黑客接单网