一、CSRF介绍

Cross-site request forgery，跨站请求伪造。发生在Web应用当中。有用户登录了Web应用，强制其执行非本意的操作。跨站：发生在用户终端（客户端）。主要目的是伪造更改状态（如，修改密码，转账等）的请求，而非盗取数据。它是一种欺骗受害者提交恶意请求的攻击，它继承了受害者的身份与特权，代表受害者执行非本意操作。对于大多数网站，浏览器请求自动发送与站点关联的所有凭据，例如用户的会话cookie，IP地址，Windows域凭据等。因此，如果用户当前已对该站点进行了身份验证，则该站点将无法区分受害者发送的伪造请求和受害者发送的合法请求。

有时可以把CSRF攻击存储在易受攻击的站点上，被称为“存储的CSRF漏洞”，攻击的严重更大。

角色：攻击者（如：hacker）、服务器（server，如网银页面）、钓鱼网站（hacker搭建）、受害者（如admin）

情景：hacker与admin都在网银页面上有账号，假设hacker当前存款0，admin存款,20000。admin在网银页面没有退出登录的情况下，访问了钓鱼网站，点击了其中的链接，即发生了转账，金额从admin的账户转移到了hacker的账户。因为网银页面与钓鱼网站是两个IP不同的网站，所以叫跨站。

分析原因：

CSRF的触发：

1.a标签

<a href="转账链接">click me.</a>

或者2.<img src="转账链接">（get请求）

admin在触发了以上恶意代码后，请求先由钓鱼网站发送到admin客户端，再由admin客户端发送到网银页面（伪造的请求）。网银页面接收到admin的请求后，将金额由admin账户转移到其下的hacker账户，从而完成了转账。整个过程hacker只搭建了钓鱼网站，不参与到攻击过程中。此攻击具有普遍性，对所有访问者有效。

除了用get方式发送伪造请求外，还可以用post伪造表单的方式发送。

 

二、CSRF防御

（1）无效的防御

1.使用秘密cookie

所有的cookie，即便是加密的，也会随着每一个请求一起提交。无论最终用户是否被欺骗提交请求，都将提交所有身份验证令牌，身份凭据。

2.仅接受POST请求

3.多步交易

4.URL重写

5.https

（2）有效的防御

1.验证referer字段

只接受来自例如网银页面的请求，而referer如果是其他网站的，则拒绝。

注意：因为referer支持客户端自定义，所以也可能无效。

2.添加token（随机字符串）验证

CSRF之所以能成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于cookie中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的cookie来通过安全验证。由此可知，抵御CSRF的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信息不存在于Cookie之中。鉴于此，系统开发者可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，可以认为是CSRF而拒绝请求。

3.二次验证

在转账等关键操作之前提供当前用户密码或验证码。

4.用户养成良好的习惯。

 

三、SSRF介绍

Server-Side request forgery，服务器端请求伪造。本质：强制服务器发送一个攻击者的请求。

如果Web应用开放了类似于“百度识图”类的功能，并且对用户提供的URL和远端服务器返回的信息没有进行合适的验证或过滤就可能存在“请求伪造”的缺陷。

SSRF的危害：端口扫描（扫描内网机器的端口）、内网Web应用指纹识别、攻击内网Web应用、读取本地文件（如用file协议）。

可通过PHP语言实现，但需要开启curl扩展。

 

四、SSRF的防御

1.限制协议

仅允许http和https请求。

2.限制IP

避免应用被用来获取内网数据，攻击内网。不能是内网IP。

3.限制端口

限制http常用端口，如80/443/8080/8090。

4.过滤返回信息

验证远程服务器对请求的响应是比较简单的方法。

5.统一错误信息

比如都用404。避免用户可以根据错误信息来判断远端服务器的端口状态。