Pikachu靶场练习——CSRF-Toy模板网

这篇具有很好参考价值的文章主要介绍了Pikachu靶场练习——CSRF。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

Pikachu靶场练习——CSRF

前言

打开pikachu靶场的CSRF我们可以看到CSRF的练习共有三项，分别为get、post、CSRF Token，在概述的地方有对CSRF的简单描述和一个小场景，对CSRF不熟悉的话建议先看看，看完之后那就开始趴。
Pikachu靶场练习——CSRF

CSRF（get）

模拟用户登录

点击CSRF（get）我们可以看到一个登录页面，点一下提示我们能够得到用户的登陆密码（后面两个的第一部也是一样的操作哦~要先登进去再进行后面的操作）
Pikachu靶场练习——CSRF
登陆进去我们能够看到一些基本的信息

尝试修改一下（点击submit之前记得打开bp抓一下包）

修改成功！

获取修改提交的URL

去bp里面瞅一眼看看抓到了什么
Pikachu靶场练习——CSRF

构造恶意执行语句

Pikachu靶场练习——CSRF

将构造的URL诱骗用户点击

在同一浏览器中（敲黑板！！！）打开这个URL将执行修改操作
Pikachu靶场练习——CSRF

其他伪装方法

写入html文件中，诱骗用户点击，并使用各种提示打消用户的疑虑。在这里我浅试一下，还有一些其他的方法可以从文章最后的传送门走

伪装成错误页面（即404页面）

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>页面找不到</title>
</head>
<body>
    <img src="http://localhost/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=18888883333&add=地球村55号&email=18888888888@163.com&submit=submit" border="0"style="display:none;"/>
 
    <h1>404<h1>
    <h2>file not found.<h2>

</body>
</html>

Pikachu靶场练习——CSRF
建议把这个文件和csrf_get.php放到同一个目录下

不然就会象这样（个人觉得就是有问题的一个链接）

CSRF（post）

Pikachu靶场练习——CSRF

获取用户修改提交的URL

修改信息、抓包、提交、看bp
Pikachu靶场练习——CSRF

构造恶意执行语句

Pikachu靶场练习——CSRF
刷新页面

CSRF Token

这是一个防范CSRF的常用方法演示
Pikachu靶场练习——CSRF
修改用户信息并提交，在bp里可以看到报文中包含token

Pikachu靶场练习——CSRF
到浏览器中看一下源代码，多刷新几次我们可以看到它的token值都是不一样的，想深入了解的话可以看一下token_get_eidt.php

每次请求，都增加一个随机码（需要够随机，不容易被伪造），后台每次对这个随机码进行验证。在生成新token之前会先销毁老token，避免token重复使用。
Pikachu靶场练习——CSRF

Token的特点

Token的值必须是随机的，可以通过安全的随机数生成算法实现
Token值是私密的，不能被第三方知晓。可存放在服务器的cookie中，也可以存放在浏览器的cookie中，但（敲黑板！！！）不能直接存放在URL中，可能会导致浏览器通过Refer的方式泄露。
在使用Token时，尽量将其放在表单中，把敏感操作由GET改成POST，以表单的形式提交，避免Token泄露
Token需要同时放在表单和session中。在提交请求时，服务器只需要验证表单中的Token与用户session(或者cookie)中的Token值是否相同，如果一致，则是合法请求，如果不一致，或者有一个为空，则请求不合法，就可能是CSRF攻击

防护策略总结

CSRF自动防御策略：同源检测（Origin 和 Referer 验证）。
CSRF主动防御措施：Token验证或者双重Cookie验证以及配合Samesite Cookie。
保证页面的幂等性，后端接口不要在GET页面中做用户操作。
为了更好的防御CSRF，最佳实践应该是结合上面总结的防御措施方式中的优缺点来综合考虑，结合当前Web应用程序自身的情况做合适的选择，才能更好的预防CSRF的发生。