实战之巧用header头

案例：

遇到过三次
一次是更改accept，获取到tomcat的绝对路径，结合其他漏洞获取到shell。
一次是更改accept，越权获取到管理员的MD5加密，最后接管超管权限。
一次是更改accept，结合参数获取到key。
这里以越权的案例介绍，其他的两个没保存图

原始请求包：

将Accept改为
Accept: application/json, text/javascript, /; q=0.01
成功获取到当前用户的password以及sql接口

构造参数id=1后成功获取到管理员权限以及管理员md5密码，md5解密后成功接管管理员权限

漏洞分析：

核心还是根据Accept进行不同响应导致的

第一种代码：

RESTful API情况下，直接写在controller中
后端请求根据请求头中Accept 字段判断进行生成不同格式的响应数据。

@RestController
public class MyController {

    @GetMapping(value = "/data", produces = MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<MyData> getJsonData() {
        // 生成 JSON 格式的响应数据
        MyData data = new MyData();
        // 设置数据...
        return ResponseEntity.ok(data);
    }

    @GetMapping(value = "/data", produces = MediaType.TEXT_HTML_VALUE)
    public ResponseEntity<String> getHtmlData() {
        // 生成 HTML 格式的响应数据
        String html = "
Hello, World!
";
        return ResponseEntity.ok(html);
    }
}

第二种代码：

filter进行设置编码

public class MyFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        String acceptHeader = httpRequest.getHeader("Accept");
        if (acceptHeader != null && acceptHeader.contains("text/html")) {
            httpResponse.setHeader("Accept", "text/plain");
        }

        chain.doFilter(request, response);
    }
}

controller进行判断情况

@Controller
public class MyController {

    @GetMapping(value = "/data")
    public String getData(HttpServletRequest request) {
        String acceptHeader = request.getHeader("Accept");
        if (acceptHeader != null && acceptHeader.contains("application/json")) {
            // 返回 JSON 格式的视图
            return "jsonView";
        } else {
            // 返回 HTML 格式的视图
            return "htmlView";
        }
    }
}

漏洞可能出现业务：

从开发角度探讨出现这种业务的原因：

1. 响应内容的格式要根据客户端的需求而动态变化：如果你的业务需要根据客户端的需求动态地生成不同格式的响应数据，例如根据客户端要求返回 JSON 或者 HTML 格式的数据。这通常用于构建 RESTful API 或者多渠道支持的应用程序。
2. 客户端与后端交互方式多样化：如果你的应用程序被多个不同的客户端（如浏览器、移动设备、API 调用等）访问，并且每个客户端对响应数据的需求不同，例如某些客户端需要 JSON 格式，而其他客户端需要 HTML 格式。此时，根据客户端请求头中的 Accept 字段来返回适当格式的数据是很常见的需求。
3. 处理特定类型的请求：有些业务场景可能需要处理特定类型的请求，例如文件上传、XML 数据解析等。这些请求可能需要特殊的处理逻辑，并返回与请求内容相关联的响应数据。

具体业务：

1. 多客户端应用程序时：多客户应用程序需要处理多种类型的客户端请求，如一个web如果同时具有apk，小程序，ios等时可以考虑测试这个。
2. 多组件存在时：多组件程序时需要处理多种不同类型请求的请求包。（上面的案例就是这种情况，因为该系统有多个组件，所以我当时才进行测试该漏洞。）

拓展以及思考：

除了accept以外是否还有其他的header头也会导致不一样呢，比如cdn模式下的Accept-Language会不会也有产生不一样的效果呢？
绕waf时的Accept-Encoding会不会也产生奇效呢？
User-Agent遇到403时，会不会也碰撞出不一样的火花。
这些就留给大家自己去探究了

最后：

基于开发的角度去探究漏洞，或许思路会更巧更妙