除此之外，因为 SSRF 最终的结果，是接受代理请求的服务端发生数据泄露。所以，SSRF 防护不仅仅涉及接收 URL 的服务端检测，也需要接受代理请求的服务端进行配合。在这种情况下，我们就需要用到请求端限制，它的防护措施主要包括两个方面。
第一，为其他业务提供的服务接口尽量使用 POST，避免 GET 的使用。因为，在 SSRF 中（以及大部分的 Web 攻击中），发起一个 POST 请求的难度是远远大于 GET 请求的。因为默认的请求方式是 GET，而发起 POST 请求，需要在发起 HTTP 请求的时候进行配置。很多安全漏洞中不包含能够配置协议的地方。在上述百度图片的例子中，黑客显然就只能发起 GET 请求。如果某个敏感服务是 POST 的，黑客就无法请求到相关资源了。
第二，为其他业务提供的服务接口，最好每次都进行验证。通过 SSRF，黑客只能发起请求，并不能获取到服务端存储的验证信息（如认证的 key 和 secret 等）。因此，只要接受代理请求的端对每次请求都进行完整的验证，黑客无法成功通过验证，也就无法完成请求了。
▌总结好了，今天的内容差不多了，让我们来回顾一下，你要掌握的重点内容。
今天我们介绍了 CSRF 和 SSRF 这两种攻击方式。其中，CSRF 是黑客控制用户的浏览器发起伪造的请求，SSRF 则是黑客控制服务端发起伪造的请求。通过伪造的请求，黑客可以伪造用户或者服务器的身份，越权获取数据或者发起请求。应用中的请求接口越敏感，黑客能够造成的伤害就越大。
除此之外，CSRF 和 SSRF 产生于正常的业务功能逻辑中，因此，我们没有办法从根本上组织黑客发起伪造的请求。但是，你可以通过加强接口的安全验证，来避免伪造请求造成影响。在 CSRF 中，我们可以通过 CSRF Token 或者二次验证等操作来加强防护。这样，黑客无法获取到隐私信息，也就无法发起连续的请求了。在 SSRF 中，我们则需要限制可请求的域名，来限制黑客能够访问到的资源。另外，目标服务端，也需要加强接口的验证，来避免伪造请求成功通过授权。
今天的内容比较多，为了方便你记忆，我总结了一个知识脑图，你可以通过它来对今天的重点内容进行复习巩固。
接下来，让我们来看一道思考题。
通过今天的讲解，你可以回忆一下，你的企业是否遇到过 CSRF/SSRF 攻击呢？如果遇到过，当时是如何处理的呢？如果没有遇到过，那你负责的 Web 或者应用中，是否实现了 CSRF/SSRF 的保护逻辑呢？具体又是怎么实现的呢？
欢迎留言和我分享你的思考和疑惑，也欢迎你把文章分享给你的朋友。我们下一讲再见！
反序列化漏洞：使用了编译型语言，为什么还是会被注入？