CSRF/SSRF：为什么避免了XSS，还是“被发送”了一条微博？

CSRF 攻击是如何产生的？

当我们在访问一个 Web 页面的时候，并不是我们自己去获取页面信息，而是浏览器去获取了这些信息，并将它们进行了展示。这就说明，你允许浏览器代表你去和 Web 的服务端进行交互。为了能够准确地代表你的身份，浏览器通常会在 Cookie 中存储一些必要的身份信息。所以，在我们使用一个网页的时候，只需要在首次访问的时候登录就可以了。

从用户体验上来说，这当然是非常方便的。但是，黑客正是利用这一点，来编写带有恶意 JavaScript 脚本的网页，通过“钓鱼”的方式诱导你访问。然后，黑客会通过这些 JavaScript 脚本窃取你保存在网页中的身份信息，通过仿冒你，让你的浏览器发起伪造的请求，最终执行黑客定义的操作。而这一切对于你自己而言都是无感知的。这就是 CSRF（Cross-Site Request Forgery，跨站请求伪造）攻击。

当你在银行页面发起一笔转账时，这个过程其实是通过一个转账接口来完成的。这个接口的内容可能包括下面这些内容：

接口地址：http://bank.com/transfer ；
HTTP 方法：POST；
接口参数：to（目标账户）、amount（金额）。

通过 CSRF 攻击，黑客能做什么？

和 XSS 一样，CSRF 也可以仿冒用户去进行一些功能操作的请求，比如修改密码、转账等等，相当于绕过身份认证，进行未授权的操作。

即使你的网页中没有任何注入漏洞，但只要接口配置不当，就能够被 CSRF 利用。而黑客也只需要在自己的域名中，搭建一个诱导性的网页，就可以让任何访问网页的用户都遭受到 CSRF 攻击。而且，用户每天需要访问大量的网页，根本没有办法确认每一个网页的合法性。而从严格意义上来说，用户根本没有办法防止 CSRF 攻击。因此，我们只能从应用本身入手去加强防护。

如何进行 CSRF 防护？

行业内标准的 CSRF 防护方法是 CSRFToken。

CSRF 是通过自动提交表单的形式来发起攻击的。所以，在前面转账的例子中，黑客可以通过抓包分析出 http://bank.com/transfer 这个接口所需要的参数，从而构造对应的 form 表单。因此，我们只需要在这个接口中，加入一个黑客无法猜到的参数，就可以有效防止 CSRF 了。这就是 CSRF Token 的工作原理。

除了 CSRF Token 之外，我们也可以通过二次验证来加强防护。

黑客通过 CSRF 攻击，替你发起了一笔转账。在支付的时候，银行会发起一个全新的页面，让你验证支付密码。这个时候你发现，这个支付请求不是你本人发起的，那你肯定不会输入支付密码来完成验证。所以，在用户进行支付这样的敏感操作时，应用通常会要求用户提供一些私密的信息，就是为了对 CSRF 攻击进行防护。

CSRF 其实就是黑客利用浏览器存储用户 Cookie 这一特性，来模拟用户发起一次带有认证信息的请求，比如转账、修改密码等。

防护 CSRF 的原理也很简单，在这些请求中，加入一些黑客无法得到的参数信息即可，比如 CSRF Token 或者独立的支付密码等。

SSRF：同样的原理，发生在服务端又会发生什么？

当我们在百度中搜索图片时，会涉及图片的跨域加载保护，百度不会直接在页面中加载图片的源地址，而是将地址通过 GET 参数提交到百度服务器，然后百度服务器请求到对应的图片，再返回到页面展示出来。

这个过程中，百度服务器实际上会向另外一个 URL 地址发起请求（比如，上图中的http://s1.sinaimg.cn）。利用这个代理发起请求的功能，黑客可以通过提交一个内网的地址，实现对内网任意服务的访问。这就是 SSRF 攻击的实现过程，也就是我们常说的“内网穿透”。

通过 SSRF 攻击，黑客能做什么？

内网探测

我们假定这样一个服务端逻辑：在这个请求过程中，服务端会判断 objurl 返回数据的 Content Type 是否为 image/jpeg。那么，可能的返回结果就有三种：

“是”，则展示图片；
“不是”，则返回“格式错误”；
无响应，则返回“找不到图片”。

基于这三种返回逻辑，黑客可以构造一个恶意的请求地址：https://image.baidu.com/search/detail?objurl=127.0.0.1:3306。如果服务器返回“格式错误”，则代表服务端本地的 3306 端口可用；如果返回“找不到图片”，则代表不可用。我们知道，3306 是 MySQL 对应的端口号，因此，根据这个返回的信息，黑客就能够知道服务端本地是否开启了一个 MySQL 服务。接下来，黑客只需要不断重复这个过程，尝试不同的 IP 和端口号，就能够一点一点探测出整个内网的结构。

文件读取

服务器除了对图片的代理不做合法性判断之外，对很多其他的代理也不做判断，而是直接将代理的结果返回到前端。我们称这种情况为“有回显的 SSRF”。在这种情况下，黑客不仅能够知道请求是否成功了，还能够知道具体返回的内容。

在 URI 中，开头的 http:// 和 https:// 代表需要使用什么协议去进行请求。除了 HTTP 之外，URI 还有很多种协议可以选择，比如 file:// 就是直接读取本地的文件。通过输入 file://etc/passwd，黑客就能够通过一个请求获取到本地的 passwd 文件，从而知道本地有哪些用户。经过不断地尝试，黑客就能够把整个服务器中的文件内容都给拉取出来，这其中包括密钥、源码等极度敏感的信息。

如何进行 SSRF 防护？

白名单限制、协议限制和请求端限制。

白名单的限制永远是最简单、最高效的防护措施。 SSRF 中的白名单，就是对用户提交上来的目标 URL 进行限制。比如，只允许是同一个域名下的 URL。你可以理解为，让百度图片的代理服务只允许代理 baidu.com 的 URL。

对协议和资源类型等进行限制。比如：对于使用协议，我们只允许 HTTP 或者 HTTPS 协议；对于返回的内容，我们只允许图片格式的内容。

请求端限制

第一，为其他业务提供的服务接口尽量使用 POST，避免 GET 的使用。

第二，为其他业务提供的服务接口，最好每次都进行验证。

总结

CSRF 是黑客控制用户的浏览器发起伪造的请求，SSRF 则是黑客控制服务端发起伪造的请求。通过伪造的请求，黑客可以伪造用户或者服务器的身份，越权获取数据或者发起请求。应用中的请求接口越敏感，黑客能够造成的伤害就越大。

CSRF 和 SSRF 产生于正常的业务功能逻辑中，因此，我们没有办法从根本上组织黑客发起伪造的请求。但是，你可以通过加强接口的安全验证，来避免伪造请求造成影响。在 CSRF 中，我们可以通过 CSRF Token 或者二次验证等操作来加强防护。这样，黑客无法获取到隐私信息，也就无法发起连续的请求了。在 SSRF 中，我们则需要限制可请求的域名，来限制黑客能够访问到的资源。另外，目标服务端，也需要加强接口的验证，来避免伪造请求成功通过授权。