影刀HTTP请求——操作超时问题（有关”x-secsdk-csrf-token“参数校验和CSRF攻击）

        在这几天，一个稳定的稳定的应用接口请求报了操作超时，如图：

打开应用查找这条报错指令，发现是HTTP请求报的错，报的这个超时我有点懵，在这条指令的选项里有个设置超时时间的，但是这个如果请求超时，应该报的是《The request was canceled due to the configured HttpClient.Timeout of 30 seconds elapsing》而不是“操作超时”，而且第一次操作超时后，过一段时间，再次发请求，就可正常响应返回了

        所以，我怀疑是我们发请求的问题，不是关于请求超时问题，刚开始，我以为是请求参数的问题，因为这个接口的请求参数是有加密参数的，有可能是平台更新了算法，我们还在使用旧的算法，导致不稳定，会出现操作超时，后来就更新了加密算法。

        可是过一段时间后，还是会出现这个问题，怎么拼接参数都不行，还是不稳定，偶尔会出现这个问题，怎的是百思不得其解，抓耳挠腮啊，算了，还是抓原接口，使用postman调试仔，细查看一下有什么不同。

        果然，被我发现了不同的地方，原接口的headers是有“x-secsdk-csrf-token”这个协议头的，而在影刀请求的headers里是没有这个协议头的：

那么，有可能就是这个问题了，为什么，总结：
1、如果是我们请求超时，会报：《The request was canceled due to the configured HttpClient.Timeout of 30 seconds elapsing》，而不是操作失败。
2、加密算法已更新，请求其他接口是正常的。
3、参数拼接和cookie是完全正常的。
4、如果2和3错误，会一直报错，不可能一会成功一会不成功。

所以根据这个协议头NAME和我们知道的情况来判断，可能是网站检测到我们的请求，有可能是CSRF攻击，所以返回一个异常给我们。说到这个，也提一嘴，在做HTTP请求时，不要忽略了协议头重定向referer这个参数，很多友友都会觉得这个参数意义不大，但是说到CSRF攻击那就有意义了，有关CSRF攻击可以查看这篇博文，讲的非常细：https://blog.youkuaiyun.com/qq_43378996/article/details/123910614?spm=1001.2014.3001.5506

        刷新网页发现，发现这个参数是动态的，唉，那就慢慢找咯，又得掉几根头发咯。最后，皇天不负有心人，也是找到了，封装成一个通用的工具指令：

通过几天的测试，发现没有任何接口报操作超时的异常了，哈哈哈哈哈哈哈哈，开心的一批。后面跟同事聊才知道，原来是他当时在做这个接口时，以为这个参数没有特殊的校验，他就给删了。