Web攻击之CSRF和SSRF

水深无声 2022-09-09 00:18 215阅读 0赞

### 文章目录 ###

*  WEB攻击
 *   *  一、CSRF
     *   *  1. 举例
         *  2. 漏洞防御方式
         *   *  2.1 验证Referer字段
             *  2.2 在请求地址中添加token并验证
     *  二、SSRF
     *   *  1. 举例
         *  2. 漏洞防御方式
         *  3. 二者的区别

# WEB攻击 #

## 一、CSRF ##

### 1. 举例 ###

通过对银行的网站发送请求 “http://bank.example/withdraw?account=bob&amount=1000000&for=bob2”可以使 Bob把1000000块的存款转到Bob2的账号下。黑客自己做一个网站，在网站中放入如下代码： src=“http://bank.example/withdraw?account=bob&amount=1000000&for=Hacker”，并且通过广告等诱使 Bob 来访问他的网站。

当Bob访问该网站时，上述URL就会从Bob的浏览器发向银行，而这个请求会附带Bob浏览器中的 Cookie 一起发向银行服务器。如果Bob当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的Session尚未过期，浏览器的Cookie之中含有Bob的认证信息。那么这个URL请求就会得到响应，钱将从Bob的账号转移到Hacker的账号。

### 2. 漏洞防御方式 ###

#### 2.1 验证Referer字段 ####

根据 HTTP 协议，在HTTP头中有一个字段叫Referer，它记录了该 HTTP 请求的来源地址。如果用户想要访问银行的服务器，那么该转帐请求的Referer必须是以银行域名开头的地址。

如果黑客要对银行网站实施 CSRF 攻击，他只能在他自己的网站构造请求，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站。

因此，要防御CSRF攻击，银行网站只需要对于每一个转账请求验证其Referer值，如果是以bank.example开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果Referer是其他网站的话，则有可能是黑客的CSRF攻击，拒绝该请求。

#### 2.2 在请求地址中添加token并验证 ####

攻击之所以能够成功，是因为黑客可以在不知道cookie的内容的前提下直接利用用户自己的Cookie来通过安全验证。

所以可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。

## 二、SSRF ##

通过篡改获取资源的请求发送给服务器，但是服务器并没有检测这个请求是否合法的，然后服务器以他的身份来访问其他服务器的资源。

### 1. 举例 ###

假如有个请求是www.baidu,com/xxx.php?image=URL，如果服务器端的验证并没有对其请求获取图片的参数（image=）做出严格的过滤以及限制，那么用户可以将image参数修改为image=www.abc.com/1.jpg，用户就可以从一个服务器访问其内部的服务器。