请求伪造漏洞 CSRF&SSRF
CSRF
漏洞原理
CSRF（跨站请求伪造，Cross-Site Request Forgery）允许攻击者在不知情的用户的帮助下，以该用户的身份执行恶意请求。这类攻击通常针对已经向某网站进行身份认证的用户（例如，通过登录认证的用户）。
实际上攻击者并没有获取到用户在网站上的具体Cookie内容，而且请求头和请求体的内容也都是由攻击者构造的
CSRF攻击的核心在于利用了web应用程序对用户的信任。浏览器允许网站A向和自己无关的网站B发起请求（并携带网站B的Cookie）。
假设用户已经登录了一个银行网站，并在同一浏览器中访问了另一个恶意网站。恶意网站可以包含一些请求，如HTML表单或JavaScript代码，这些请求被设计为自动向银行网站发送请求。因为用户已经在银行网站上验证了其身份，所以银行网站会认为这些请求是合法的用户请求。
在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。所以CSRF攻击也成为”one click”攻击。
场景举例
下面的场景转载自Pikachu靶场
场景需求：
小黑想要修改大白在购物网站www.xx.com上填写的会员地址。
先看下大白是如何修改自己的密码的：
登录—-修改会员信息，提交请求—-修改成功。
所以小黑想要修改大白的信息，他需要拥有：1，登录权限 2，修改个人信息的请求。
但是大白又不会把自己xxx网站的账号密码告诉小黑，那小黑怎么办？
于是他自己跑到www.xx.com上注册了一个自己的账号，然后修改了一下自己的个人信息（比如：E-mail地址），他发现修改的请求是：http://www.xxx.com/edit.php?email=xiaohei@88.com&Change=Change
于是，他实施了这样一个操作：把这个链接伪装一下，在小白登录xxx网站后，欺骗他进行点击，小白点击这个链接后，个人信息就被修改了,小黑就完成了攻击目的。
为啥小黑的操作能够实现呢。有如下几个关键点：
1.www.xxx.com这个网站在用户修改个人的信息时没有过多的校验，导致这个请求容易被伪造;
—-因此，我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作(增删改)是否容易被伪造。
2.小白点击了小黑发给的链接，并且这个时候小白刚好登录在购物网上;
—-如果小白安全意识高，不点击不明链接，则攻击不会成功，又或者即使小白点击了链接，但小白此时并没有登录购物网站，也不会成功。
—-因此，要成功实施一次CSRF攻击，需要“天时，地利，人和”的条件。
当然，如果小黑事先在xxx网的首页如果发现了一个XSS漏洞，则小黑可能会这样做： 欺骗小白访问埋伏了XSS脚本（盗取cookie的脚本）的页面，小白中招，小黑拿到小白的cookie，然后小黑顺利登录到小白的后台，小黑自己修改小白的相关信息。
—-所以跟上面比一下，就可以看出CSRF与XSS的区别：CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS是直接盗取到了用户的权限，然后实施破坏。
因此，网站如果要防止CSRF攻击，则需要对敏感信息的操作实施对应的安全措施，防止这些操作出现被伪造的情况，从而导致CSRF。比如：
—对敏感信息的操作增加安全的token；
—对敏感信息的操作增加安全的验证码；
—对敏感信息的操作实施安全的逻辑流程，比如修改密码时，需要先校验旧密码等。
漏洞防御
验证 HTTP Referer 字段
Referer字段记录了该 HTTP 请求的来源地址。通常情况下，安全的页面的会要求请求来自于同一个网站
然而由于浏览器本身的漏洞，目前也有一些绕过方法，黑客篡改 Referer 值以通过验证
在请求地址中添加 token 并验证
设置Cookie的SameSite属性
Cookie的SameSite属性可以确保携带Cookie发起请求的网站和请求目标的服务是同站
SameSite属性包括如下取值
- Strict 完全禁止跨站传递Cookie，比如A网站通过超链接跳转B网站也不行，必须用户手动输入这个B网站浏览器才允许使用B网站的Cookie。 过于严格，很少使用。
- Lax 相对宽松(reLax)的规则，大部分情况也不允许跨站传递Cookie，但是对于较为安全的场景：超链接跳转，get类型的Form表单，是允许的。 这个模式是大部分浏览器的SameSite的默认取值（当服务端SetCookie没有制定SameSite时，大部分现代浏览器会默认使用Lax）。使用Lax已经能够杜绝CSRF攻击。
- None 完全没有限制。老版本浏览器默认仍然会使用None作为SameSite的默认取值。 大部分现代浏览器默认是Lax。以及None默认过于危险，如果要使用SameSite=None则浏览器会要求网站服务使用https才行。
在 HTTP 头中自定义属性并验证
SSRF
漏洞原理
SSRF(Server-Side Request Forgery:服务器端请求伪造) 是一种由攻击者构造形成由服务端发起请求的安全漏洞。
所有目标服务器会从自身发起请求的功能点，且攻击者可以控制地址的参数，都可能造成SSRF漏洞
可能产生漏洞的函数包括
file_get_contents
file_get_contents函数从用户指定的url获取图片。然后把它用一个随即文件名保存在硬盘上，并展示给用户。
1
2
3
4
5
6
7
8
9
10
11
if (isset($_POST['url']))
{
$content = file_get_contents($_POST['url']);
$filename ='./images/'.rand().';img1.jpg';
file_put_contents($filename, $content);
echo $_POST['url'];
$img = "<img src=\"".$filename."\"/>";
}
echo $img;
sockopen()
这个函数会使用socket跟服务器建立tcp连接，传输原始数据。
1
2
3
4
5
6
7
8
9
10
11
if (isset($_POST['url']))
{
$content = file_get_contents($_POST['url']);
$filename ='./images/'.rand().';img1.jpg';
file_put_contents($filename, $content);
echo $_POST['url'];
$img = "<img src=\"".$filename."\"/>";
}
echo $img;curl_exec()
curl也可以用于从目标站点获取内容
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
if (isset($_POST['url']))
{
$link = $_POST['url'];
$curlobj = curl_init();
curl_setopt($curlobj, CURLOPT_POST, 0);
curl_setopt($curlobj,CURLOPT_URL,$link);
curl_setopt($curlobj, CURLOPT_RETURNTRANSFER, 1);
$result=curl_exec($curlobj);
curl_close($curlobj);
$filename = './curled/'.rand().'.txt';
file_put_contents($filename, $result);
echo $result;
}
发现SSRF漏洞后，首先要做的事情就是测试所有可用的URL伪协议
- file:/// 从文件系统中获取文件内容，如，file:///etc/passwd
- dict:// 字典服务器协议，访问字典资源，如，dict:///ip:6739/info：
- sftp:// SSH文件传输协议或安全文件传输协议
- ldap:// 轻量级目录访问协议
- tftp:// 简单文件传输协议
- gopher:// 分布式文档传递服务，可使用gopherus生成payload
漏洞防御
过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。
统一错误信息，避免用户可以根据错误信息来判断远端服务器的端口状态。
限制请求的端口为http常用的端口，比如，80,443,8080,8090。
黑名单内网ip。避免应用被用来获取获取内网数据，攻击内网。
禁用不需要的协议。仅仅允许http和https请求。可以防止类似于file:///,gopher://,ftp:// 等引起的问题。
