本文仅用于技术讨论与学习，利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，文章作者不为此承担任何责任。

只供对已授权的目标使用测试，对未授权目标的测试作者不承担责任，均由使用本人自行承担。

这个方法帮助了我挖掘了到许多的src漏洞，效果也很比较好

请求一个域名的流程是怎么样的？首先看本机缓存，再看HOSTS记录，如果都没有则请求本地DNS服务器，本地DNS服务器中没有，则本地DNS服务器迭代去请求根DNS服务器，上面的图中在本机的HOSTS写上两个模拟的地址，因为条件有限啊，模拟不了DNS服务器，所以这里就模拟HOSTS作为DNS服务器

挖掘zpchcbd.com的域名的漏洞，发现收集的域名其中DNS解析的一个IP为192.168.4.136（假设外网IP），直接访问192.168.4.136却是回显为nginx 403拒绝访问的界面

但是此时该nginx为反向代理的服务器，且配置情况如下所示

这时候就可以通过该ip来匹配不同的host字段来进行访问，比如访问hosts字段头为admin.zpchcbd.com

实战中的host碰撞的总结和利用如下

• • 内网的管理系统和业务系统都用同一台nginx服务器进行反向代理

• • 扫外网的时候扫到解析ip为内网的域名（如何大量的搜集内部的域名才是最重要的）

• • 通过hosts碰撞，来遍历域名绑定外网的这个Nginx的ip，如果正好如何这个nginx的配置项的server_name则hosts碰撞成功

实战中的利用效果也很好，这里推荐的碰撞工具：

https://github.com/pmiaowu/HostCollision
https://github.com/cckuailong/hostscan/

如何有效的发现反向代理的服务器

想要进行host碰撞首先肯定需要先知道哪些服务器是存在反向代理的，这里给出几个方法

trace方法

通过默认的trace方法可以判断Max-Forwards为0的时候的第一台代理服务器或者是非代理服务器（最终的web容器）

即使现在的trace方法都已经被禁止了，但是响应包中还是会通过via字段来进行显示，所以可以通过判断Via字段或者是X-Via来判断是否是代理服务器，比如下面就是通过slb负载均衡来进行反向代理的服务器

如果用trace访问不存在反向代理，一般显示如下不存在Via字段

如果默认的trace方法配合上Max-Forwards的时候，此时Max-Forwards小于中间要跳转的次数，那么最终响应包中返回的状态码是483

一些别人整理的查找反向代理的时候响应包中的特征

# Heuristics :
# - Status Codes :
# - HTTP Status Code == 502
# - HTTP Status Code == 483
# - Specific data in body or headers :
# - X-Forwarded-For in body when using TRACE
# - Via or X-Via in headers
# - Differences between hops :
# - HTTP Status Codes
# - Server headers
# - Content-Type headers
# - Via headers
# - HTML titles
# - HTML <address> tags
# - X-Forwarded-For values when using TRACE 

这种还没有遇到过，也是这几天刚看到的一个2017年的议题才在这里进行的记录，之后如果有找到这种情况的话会在这边进行记录更新

• • 不正确的HTTP主机头，修改host字段导致的ssrf的情况，可能是配置问题，也可能是代码问题，或者是后端的日志分析系统发起的请求

• • 请求行覆盖host字段，下面的图中已经知道了www.icefilms.info真实ip地址^[1]

• • @转发问题，bp中请求host指定为incap-client:[email protected]^[2]，可能在后端转发处理的时候处理为http://user:[email protected]/，导致后端进行@重定向

• • Apache HttpComponents库的安全问题，允许请求行可以不以/开头，导致指定url为@burp-collaborator.net，最终后端转发被重定向，请求的地址为http://[email protected]/

参考文章：https://issues.apache.org/jira/browse/HTTPCLIENT-1803

Url backendURL = "http://public-backend/";
String uri = ctx.getRequest().getRawUri();
        
URI proxyUri;
try {
proxyUri = new URIBuilder(uri) // uri -> @burp-collaborator.net
        .setHost(backendURL.getHost()) -> public-backend@burp-collaborator.net
        .setPort(backendURL.getPort()) -> 80
        .setScheme(backendURL.getScheme())
        .build();
} catch (URISyntaxException e) {
    Util.sendError(ctx, 400, INVALID_REQUEST_URL);
    return;
}

• • headers字段头fuzz

X-Forwarded-For: a.burpcollaborator.net
True-Client-IP: b.burpcollaborator.net
Referer: http://c.burpcollaborator.net/

这里分享两种情况，一个是我自己的 一个是pmiaowu师傅的

pmiaowu师傅的分享

有时候，设计统一登录链接(SSO)各种站点的时候，判断是否登录，不会去真的获取登录信息，为了减少请求压力，都是判断数据包某个值是否存在，值可能就是下面的某个字段

header头加:
    Authorization: JWT 1
    ticket: 1
    token: 1
Cookie添加:
    ticket=1;
    Authorization=JWT 1;
    token=1;
    user=1;
    userId=1;
    UserId=1;
    admin=1;
    adminId=1;
    adminid=1;
    AdminId=1;
    Adminid=1;
    xh=1;
    xuehao=1;
    gh=1;
    gonghao=1;
    username=1;
header头加:
    X-Forwarded-For: 10.10.10.10
    x-originating-ip: 127.0.0.1
    x-remote-ip: 127.0.0.1
    x-remote-addr: 127.0.0.1
    X-Real-IP: 192.168.1.1
    X-Original-URL: /admin

自我分享

相关src平台的报告有期间查看时间，所以这边看不了就没有图了，主要就是对于一些统一的单点登录(SSO)验证的接口的跳转302，有时候你会看到在跳转之前还会有相关的登录显示，这种情况下可以尝试去观察下js的代码，去发现相关的登录接口构造账号密码的参数进行登陆，如果成功获取token的话那么就可以绕过单点登录，构造token来进行登陆单系统.

来源

https://www.cnblogs.com/zpchcbd/p/17071179.html

引用链接

[1] www.icefilms.info真实ip地址: http://www.icefilms.info真实ip地址
[2] [email protected]: mailto:[email protected]

致力于红蓝对抗，实战攻防，星球不定时更新内外网攻防渗透技巧，以及最新学习研究成果等。常态化更新最新安全动态。专题更新奇技淫巧小Tips及实战案例。

涉及方向包括Web渗透、免杀绕过、内网攻防、代码审计、应急响应、云安全。星球中已发布 200+ 安全资源，针对网络安全成员的普遍水平，并为星友提供了教程、工具、POC&EXP以及各种学习笔记等等。

关注公众号回复“加群”，添加Z2OBot 小K自动拉你加入Z2O安全攻防交流群分享更多好东西。

关注福利：

回复“app" 获取  app渗透和app抓包教程

回复“渗透字典" 获取 针对一些字典重新划分处理，收集了几个密码管理字典生成器用来扩展更多字典的仓库。

回复“书籍" 获取 网络安全相关经典书籍电子版pdf

回复“资料" 获取 网络安全、渗透测试相关资料文档