【实战】使用抓包工具分析HTTP请求

“上善若水，厚德载物”老爸常挂嘴边，也经常教育自己要多做善事

20200202在这个千年一遇充满爱的日子里献自己一颗爱心作为一名共产党员，国难当头，为我村防守一线值班人员捐赠慰问品，尽一份绵薄之力，共渡难关。

学习了一下通过抓包工具分析http请求以及篡改数据，分享给大家~~

什么是URL 转码？

不管是以何种方式传递url时，如果要传递的url中包含特殊字符，eg：如果想要传递一个“+”，但是这个“+”会被url会被编码成空格，想要传递“&”，会被url处理成分隔符。

尤其是当传递的url是经过Base64加密或者RSA加密后的，存在特殊字符时，这里的特殊字符一旦被url处理，就不是原先你加密的结果了。

我们举个栗子，如下：

@RestController
@RequestMapping("/openApi")
public class HelloApiController extends BaseApiResponse {
    private static Logger logger = LoggerFactory.getLogger(HelloApiController.class);


    @RequestMapping("/getUserName")
    public BaseResponseVO getUserName(String userName){
        logger.info("接受到的参数:"+userName);
        return this.setResultSuccessData(userName);
    }
}

我们访问getUserName，传参“张三”，获取到的就是“张三”，结果如下图：

如果我们访问getUserName，传参“1+1”,接口返回是什么呢？

我们看到返回的是：1 1，“+”跑哪里了呢？这个就是我们上面所说的url编码，“+”会被url编码成空格，同理如果我们传参为：userName=1?//2&mm，运行结果如下：

那么要传什么参数才能获取到“1+1”，其实url中有些特殊字符有其对应的编码，如下表所示：（理解的时候就类似我们java中的转义字符，只不过这是url中特殊字符的处理）

   public static void main(String[] args) {
        String getUserNameUrl = null;
        try {
            getUserNameUrl = "http://localhost:8080/openApi/getUserName?userName="+URLEncoder.encode("1?//2&mm","utf8");
            JSONObject resultJson = HttpClientUtils.httpGet(getUserNameUrl, "localhost", 8080);
            logger.info("返回结果："+resultJson);
        } catch (UnsupportedEncodingException e) {
            logger.error("URL编码异常：",e);
        }
    }

可以看到通过URLEncoder.encode对参数编码处理后变成了：1%3F%2F%2F2%26mm，返回结果也是我们预期结果。

什么是HTTP请求？

HTTP请求就是超文本传输协议，底层使用Socket TCP长连接，基于请求与响应，是一个同步过程。

HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且顺序与发送顺序一致。TCP协议是可靠的、面向连接的。

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码Connection:keep-alive，在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

Fiddler是强大好用的Web调试工具之一，它能拦截同局域网段的所有wifi客户端和服务器的http和https请求。允许监视、设置断点、甚至修改输入输出数据。Fiddler包含了一个强大的基于事件脚本的子系统，并且能使用.net语言进行扩展。

Fiddler是一个抓包工具，以代理web服务器的形式工作，当浏览器访问服务器会形成一个请求，此时，fiddler就处于请求之间，当浏览器发送请求，会先经过fiddler，然后再到服务器；当服务器有返回数据给浏览器显示时，也会先经过fiddler，然后数据才到浏览器中显示，这样一个过程，fiddler就抓取到了请求和响应的整个过程，其原理图如下：

我们知道http重定向的时候浏览器会像服务端发送两次请求，并且地址栏会发生改变，我们也和转发做过对比，转发是服务器内部转发，浏览器只会发送一次请求，那么重定向为什么会发送两次请求呢？整个过程是什么样子的呢？我们具体写代码操作看一下：

 @RequestMapping("/index")
    @ResponseBody
    public String  index(){
        return "重定向到index页面";
    }


    /**
     * 访问/redirectIndex重定向到/index
     * @return
     */
    @RequestMapping("/redirectIndex")
    public String redirectIndex(){
        return "redirect:index";
    }

在浏览器中访问redirectIndex：

我们看到访问redirectIndex后被重定向到了index，地址路径也发生了变化，我们使用抓包工具Fiddler分析如下：

我们可以看到进行了两次请求，第一次请求/redirectIndex时返回状态码302，然后在响应的headers中有location属性，值为：http://localhost:8080/index，其实这个location属性就相当于location.href=“地址”发送新的请求即第二次/index，那么我们是不是也可以自己模拟一下重定向呢，其实很简单。主要第一个就是第一次请求的返回码是302，第二就是响应头中加上location属性，值为新的请求地址，代码如下：

 @RequestMapping("/customRedirecet")
    public void customRedirecet(HttpServletResponse response){
        response.setStatus(302);
        response.setHeader("location","/index");
 }

访问/customRedirecet，同样会重定向到/index：

效果是一样的。HTTP重定向的原理总结如下：

客户端向服务器发送请求的时候，服务端如果重定向的话，返回状态码302给客户端，在响应头中存放location，对应的值就是重定向地址，客户端收到状态为302的话，直接浏览器进行访问。

前面我们说了Fiddler是客户端和服务端之间的一个代理工具，能够抓取统一局域网中的所有请求，那么就可以修改请求的参数和响应的数据，下面我们演示一下：

@RequestMapping("/getUserInfo")
    public BaseResponseVO getUserInfo(@RequestBody User user){
        logger.info("接受到的参数:"+user);
        return this.setResultSuccessData("用户名:"+user.getName()+",年龄："+user.getAge());
    }

然后对参数进行篡改，这里修改为李四，返回结果如下：

以上就模拟了通过Fiddler抓包工具篡改了请求参数，同理也可以篡改返回的结果，比如在支付的时候修改了支付金额等，所以我们在开发的时候，客户端和服务器端的交互过程一定要使用加密方式传输，参数加签验签，使用https传输，防止黑客抓包分析http请求。

欢迎关注ITSK，每天进步一点点，我们追求在交流中收获成长和快乐