最近接手一个老项目，因为历史原因，接过来的很多接口都没有做好参数的过滤和校验，导致了很多攻击漏洞。
最近遇到的一个攻击漏洞就是ssrf攻击，ssrf攻击即服务器端请求伪造，是一种由攻击者构造形成由服务器端发起请求的一个安全漏洞，一般情况下，ssrf攻击的目标是从外网无法访问的内部系统，正是因为它是服务器端发起的，所以它能够请求到与它相连而与外网隔离的系统内部。
简单点说用户构造一个探测内网的地址，比如test.sina.com，如果返回的错误与test123.sina.com返回的错误信息不一致，那就有可能说其中一个是内网。
ssrf形成的原因大都是由于服务器提供了从其他服务器应用获取数据的功能，且没有对目标地址做过滤和限制，比如从指定URL地址获取网页文本内容，加载指定地址的图片等，利用的是服务器的请求伪造，ssrf是利用缺陷的web应用作为代理攻击远程和本地的服务器。
针对我这个项目做的防御方式是，对url地址做过滤，如果不是标准的url地址返回报错，然后测试URL地址的有效性，因为我这边正常的是一个下载地址，如果地址无效也返回报错，最后做获取地址的域名，通过域名获取IP地址，检测IP地址是否是一个内网地址，如果是也返回报错，最后的地址一定是一个有效的可以下载的外网地址，否则都是统一的报错信息。
还有其他的防御方式比如
- 限制协议为HTTP、HTTPS
- 禁止30x跳转
- 设置URL白名单或者限制内网IP
具体：
白名单和DNS解析
直接在用户的输入上实时简单的黑名单或者正则表达式来过滤IP地址或者域发送的这个请求，这对于避免SSRF是一个坏方法。
通常，黑名单都是一个糟糕的安全控制因为总是会有开发者忽视的漏网之鱼有。在这样的情况下，攻击者就能够利用这样的旁路来产生HTTP重定向，一个通配符DNS服务比如xip.io或者甚至是可用的IP编码.
相反，最通用的解决SSRF的方式是使用你的应用需要访问DNS名称或者IP地址的白名单。如果白名单方案不适合你的用户案例，那么你必须依赖黑名单，适当地验证你的用户输入是非常重要的。一个例子就是不允许向私有IP地址（非路由）发送请求（详细参考RFC 1918），然而，在使用黑名单的情况下，正确的采取什么样的避免措施往往取决于具体的应用。换句话说，对于SSRF没有一个通用的修复方法，因为它非常依赖于应用的功能以及商业需求。
响应处理
确保响应是远程服务器接收的响应是它应该接收的是非常重要的，这对于阻止响应数据意想不到的泄露给攻击者是非常重要的。以上其他的，无论在任何情况下，服务器发送的原生响应体都不应该直接发送给客户端。
关闭无用的URL协议
如果你的应用仅仅使用HTTP或者HTTPS来发送请求，那么应该就仅仅允许这些URL协议。关闭不使用的的URL协议能够阻止web应用使用潜在危险的URL协议，比如file:///，dict://，ftp://以及gopher。
认证内部服务
服务比如Memcached，Redis，Elasticsearch以及MongoDB默认不需要认证的。SSRF漏洞可以提供给攻击者一个没有任何认证阻拦的机会来访问这些服务。因此，最好是在人地方都使用认证，这也是一个防护机制。