CSRF（跨站请求伪造）

成因：

Web应用缺乏对请求来源的验证，导致攻击者可以利用用户已经登录的状态（通过Cookie）发起伪造请求。

Cookie起的作用：

  • 自动携带机制：浏览器会自动携带Cookie，攻击者可以利用这一点发起伪造请求。

(如果用户已经登录了example.com，浏览器会在访问example.com的任何页面时自动携带session_id Cookie。)

  • 身份验证依赖：Web应用依赖Cookie来验证用户身份，但没有验证请求来源是否合法。

攻击类型分类

GET型：（链接）

POST型：(表单)

XSS型：

（API接口调用触发）？

操作性质分类：

数据操作类：

  • 增加操作
  • 删除操作
  • 修改操作

文件操作类：（?）

  • 文件读取操作
  • 文件上传操作
  • 文件删除操作

如何查看是否有csrf

在报文中找

  • token——CSRF令牌，最有效的
  • Authorization——API认证
  • Referer——检测请求的来源，有可能伪造

看看去掉这些后，重新发request，看看是否能成功

{本质是存在一些我们得不到的防伪数据}

生成相关的脚本

BP上有一个功能可以生成对应简单的链接

例子：

DVWA的low版CSRF题目

直接用bp打开

有1

输入密码后，发现url多了一些内容

2

有3

我删掉referer的内容后仍然是成功的4

而且，好像没有发现什么token值，直接改url上面的password_new和password_conf为111

仍然成功6这就有了CSRF漏洞出现了

现在尝试用bp生成一个脚本：

找到如图按键7

会帮我什么生成相关脚本8

这样就节省了编代码的力气了（不过对于复杂的可能会比较难生成，而且想构造符合具体情况的话，还是要自己去构造的）

它还能生成url——点击Test in browser（仅限于bp的Browser上用），输入到Browser上

9

点那个按键进去后就可以把密码改为111

cors

CORS是一种安全机制，它允许一个域（源）的Web应用去请求另一个域的资源。

它允许服务器明确地告诉浏览器，哪些外部域可以访问它的资源。服务器通过在HTTP响应头中添加Access-Control-Allow-Origin等CORS相关的头信息，来告诉浏览器是否允许跨域请求。

（1）简单请求

（2）预检请求

判断

改一下origin，看看Access-Control-Allow-Origin会不会跟着改动；

或者，Access-Control-Allow-Origin直接就设为*了（任何域都可以访问你的资源）

JSONP

JSONP的核心思想是利用<script>标签的src属性不受同源策略限制的特点，通过动态创建<script>标签来加载跨域服务器上的数据。

（1）基本原理

  • 当浏览器解析<script>标签时，会加载src属性指定的URL，并执行返回的JavaScript代码。
  • 如果服务器返回的是一个JSON对象，直接返回会报错（因为JSON不是有效的JavaScript代码）。因此，服务器需要返回一个函数调用，将JSON数据作为参数传递给这个函数。
  • 客户端定义一个回调函数，用于处理返回的数据。

前提

被攻击网址（服务器）要满足

有JSONP接口，且没有被严格限制：

  1. 支持JSONP接口。（要目标网址上有可以callback的参数（类似的也可）， ——即开放了一个JSONP接口）
  2. 允许用户动态指定回调函数名。
  3. 返回的JSON数据中包含用户可控的内容。
  4. 返回的JSON数据被错误地解析为HTML内容。
  5. 返回的JSON数据包含敏感信息。

[!CAUTION]

实现xss攻击

（如果目标网站的JSONP接口返回的JSON数据被错误地解析为HTML内容，攻击者可以通过构造恶意的JSON数据来实现XSS攻击）

1
<script src="https://example.com/api/data?callback=<script>alert(1)</script>"></script>

xxs+csrf组合拳getshell

待续。。。