webgoat-Request Forgeries 请求伪造

测试-东方不败之鸭梨

已于 2023-11-29 15:45:34 修改

阅读量541

点赞数 1

分类专栏：安全测试工具和靶场实战文章标签：安全

于 2023-11-07 22:42:45 首次发布

本文链接：https://blog.csdn.net/seanyang_/article/details/134277976

版权

安全测试工具和靶场实战专栏收录该内容

60 篇文章 5 订阅

订阅专栏

(A8:2013) Request Forgeries

Cross-Site Request Forgeries

01

什么是跨站请求伪造？

跨站请求伪造，也称为一键攻击或会话骑乘，缩写为 CSRF或 XSRF，是一种对网站的恶意利用，其中网站的用户传输未经授权的命令信任。与利用用户对特定站点的信任的跨站点脚本 (XSS) 不同，CSRF 利用站点在用户浏览器中的信任。
is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user’s browser.
跨站点请求伪造是针对浏览器的“责任混淆”攻击。

CSRF通常具有以下特点：
它涉及依赖用户身份的网站。
它利用了网站对该身份的信任。
它欺骗用户的浏览器向目标站点发送 HTTP 请求。
它涉及有副作用的 HTTP 请求。

存在风险的是基于受信任和经过身份验证的用户的输入执行操作而不需要用户授权特定操作的 Web 应用程序。通过保存在用户 Web 浏览器中的 cookie 进行身份验证的用户可能会在不知情的情况下向信任该用户的站点发送 HTTP 请求，从而导致不必要的操作。

CSRF 攻击针对/滥用基本 Web 功能。如果网站允许，则会导致服务器状态发生变化，例如更改受害者的电子邮件地址或密码，或者购买某些东西。强迫受害者检索数据对攻击者没有好处，因为攻击者没有收到响应，而受害者收到了。因此，CSRF 攻击的目标是状态更改请求。

02

CSRF with a GET request

这是最简单的 CSRF 攻击。例如，您会收到一封电子邮件，其中包含以下内容：

View my Pictures!

如果用户仍然登录到 bank.com 的网站，这个简单的GET请求会将资金从一个账户转移到另一个账户。当然，在大多数情况下，网站可能很多控制来限制这样的请求

0x03

题目要求使用外部资源触发提交按钮。如果直接点击提交，会提示Appears the request came from the original host
意思就是不能从webgoat触发这个url，最简单的方法就是修改请求的refer，refer表示这个请求从哪个网站来的。
在这里插入图片描述

点击提交按钮，看到接口，修改请求头中的referer字段（相当于从其他网站向目标请求发送请求），发送请求，获得flag。
在这里插入图片描述

04

代表他人发表评论
下面的页面模拟评论/评论页面。此处的区别在于，您必须在其他地方启动提交，就像使用 CSRF 攻击以及之前的练习一样。这比你想象的要容易。在大多数情况下，更棘手的部分是找到您想要执行 CSRF 攻击的地方。典型的例子是某人银行账户中的账户/电汇。

但我们在这里保持简单。在这种情况下，您只需代表当前登录的用户触发审核提交即可。
在这里插入图片描述
仍然抓包，修改referer后请求

05 框架支持xsrf

大多数框架现在都默认支持防止 CSRF。例如，在 Angular 中，默认情况下，拦截器会从 cookie 中读取 XSRF-TOKEN，并将其设置为 HTTP 头 X-XSRF-TOKEN。由于只有运行在您的域上的代码才能读取 cookie，因此后端可以确定 HTTP 请求来自您的客户端应用程序，而不是攻击者。

为了实现此功能，后端服务器在cookie中设置token。客户端在每次向服务器发出请求时，将令牌作为HTTP标头放入X-XSRF-TOKEN中。服务器可以验证这两个令牌是否匹配，这将确保服务器上的请求运行在相同的域上。
（服务端给客户端发token，并将token存放在cookie上，客户端请求时需要带上token，攻击者不知道token，当然就无法请求。）

custom header是不安全的

另一种防御措施是在每次调用中添加自定义请求标头。如果与服务器进行的所有交互都是用JavaScript执行的，这将起作用。在服务器端，您只需检查是否存在此标头，如果不存在，则拒绝请求。一些框架默认提供此实现，但研究人员Alex Infuhr发现，此实现也可以被绕过。

06

But I only have JSON APIs and no CORS enabled, how can those be susceptible to CSRF?
只是用jsonapi，不允许跨域，还会存在CSRF漏洞吗？

A lot of web applications implement no protection against CSRF they are somehow protected by the fact that they only work with application/json as content type. The only way to make a request with this content-type from the browser is with a XHR request. Before the browser can make such a request a preflight request will be made towards the server (remember the CSRF request will be cross origin). If the pre-flight response does not allow the cross origin request the browser will not make the call.

长话短说：这不是防御CSDRF的有效方法
因为 Navigator.sendBeacon()允许使用任意的content-type来发送POST请求。
The navigator.sendBeacon() method can be used to asynchronously transfer a small amount of data over HTTP to a web server. This method addresses the needs of analytics and diagnostics code that typically attempts to send data to a web server prior to the unloading of the document. Sending the data any sooner may result in a missed opportunity to gather data…

— developer.mozilla.org

For example:

function postBeacon() {
var data= new Blob([JSON.stringify({“author” :“WebGoat”})], {type : ‘application/json’});
navigator.sendBeacon(“http://localhost:8083”, data)
}
I think Content-Type restrictions are useful for websites that are accidentally safe against CSRF. They are not meant to be, but they are because they happen to only accept XML or JSON payloads.

That said, it’s somewhat obvious the websites depending on this behavior should be fixed, and any reputable pentesters will point that out. The issue is whether it’s the browser responsibility to act as a nanny to weak websites, or we should leave weak websites as sacrifice for great justice. Survival of the fittest.

IMHO, the answer is somewhere in between, and a good first step would be to document all these Same Origin Policy gotchas that websites might depend upon for security.

But wrt to this bug in specific, if it never got fixed, I don’t think it would be the end of the world. But then again, on this day and age, maybe there’s a way to launch nuclear missiles with a XML RPC interface, so maybe it would be the end of the world.

— Eduardo Vela

Firefox和Chrome修复了这个问题，但是这说明应该采取主动地CSRF防御错误，而不是依赖API的content-type

0x07 CSRF and content-type

In the previous section we saw how relying on the content-type is not a protection against CSRF. In this section we will look into another way we can perform a CSRF attack against a APIs which are not protected against CSRF.

题目要求向终端发送如下post请求，注意需要从其他域请求且需要登录webgoat(可以用webwolf)
更多信息 https://pentestmonkey.net/blog/csrf-xml-post-request

POST /csrf/feedback/message HTTP/1.1

{
  "name"    : "WebGoat",
  "email"   : "webgoat@webgoat.org",
  "content" : "WebGoat is the best!!"
}

方法一：利用wolf上传html文件进行请求，实现跨域。

<form name="attack" enctype="text/plain" action="http://10.100.33.188:8080/WebGoat/csrf/feedback/message" METHOD="POST">
<input type="hidden" name='{"name": "Testf", "email": "teddst1233@163.com", "subject": "service", "message":"' value='dsaffd"}'>
</form>
<script>document.attack.submit();</script>

新建文件a.html如上，提交到wold中，然后访问wolf该文件对应的url。
在这里插入图片描述

原理是请求wolf返回的html，向webgoat发送了请求提交了表单。该请求的origin和referer都是wolf的地址，所以实现了跨域请求。

方法二：
直接抓包修改referer字段，修改后发现不行，查看源码进行了三处校验
1、请求要携带wengoatCookie
2、请求的content-type需要是text/plain
3、请求的host或者referer需要不一致

 boolean correctCSRF = requestContainsWebGoatCookie(request.getCookies()) && request.getContentType().contains(MediaType.TEXT_PLAIN_VALUE);
    correctCSRF &= hostOrRefererDifferentHost(request);
    if (correctCSRF) {
      String flag = UUID.randomUUID().toString();
      userSessionData.setValue("csrf-feedback", flag);
      return success(this).feedback("csrf-feedback-success").feedbackArgs(flag).build();
    }
    return failed(this).build();
  }

构造请求，发送后通过。
在这里插入图片描述

08 Login CSRF attack

登录CSRF攻击
在登录 CSRF 攻击中，攻击者使用自己在该站点的用户名和密码伪造对站点的登录请求。如果伪造成功，服务器会响应一个Set-Cookie标头，指示浏览器通过存储会话 cookie 来改变其状态，用户作为攻击者登录站点。
此会话 cookie 用于将后续请求绑定到用户的会话，从而绑定到攻击者的身份验证凭据。登录 CSRF 攻击可能会造成严重后果，例如，请参见下图，攻击者在 google.com 创建帐户，受害者访问恶意网站，并且用户以攻击者身份登录。攻击者随后可以收集有关用户活动的信息
在这里插入图片描述
在此作业中，尝试查看 WebGoat 是否也容易受到登录 CSRF 攻击。保持此选项卡打开，然后在另一个选项卡中根据您自己的用户名（前缀为）创建一个用户csrf-。因此，如果您的用户名是，tom您必须创建一个名为的新用户csrf-tom。

以新用户身份登录。这就是攻击者使用 CSRF 所做的事情。然后单击原始选项卡中的按钮。由于您以其他用户身份登录，攻击者会得知您单击了该按钮。

注册个csrf-开头的用户，比如我的用户名为tntaxin，然后我再注册一个csrf-tntaxin,然后登录csrf-tntaxin访问这道题目，点击提交 solved就过了，当然这题的真实目的是希望你构建一个csrf 恶意链接，然后访问这个链接就会自动登录csrf-tntaxin这个账户，这样受害者的访问记录你就都知道了。
在这里插入图片描述

09 CSRF 影响

影响仅受登录用户可以执行的操作的限制（如果站点/功能/操作未得到适当保护）。真正容易受到 CSRF 攻击的领域是物联网设备和“智能”设备。可悲的是，许多消费级路由器也被证明容易受到 CSRF 的影响。

CSRF解决方案

cookie的Same site属性
这是现代浏览器支持的新扩展，它限制了 cookie 的范围，使其仅如果这些请求是“同一站点”，则附加到请求例如，如果请求是从 webgoat.org来的，请求http://webgoat.org/something，则请求将附加同一站点 cookie。
有两种模式，严格和宽松。第一个不允许跨站点请求，
SameSite的Strict和Lax选项在处理跨站点请求时具有不同的行为。

SameSite的Strict选项是最严格的设置，它禁止在任何跨站点请求上发送cookie。这意味着，如果黑客从他的网站去访问你网站的资源，如果你的网站的某些Cookie设置了SameSite = Strict，那么在黑客网站上的Cookie是不会发送到你的网站上的，只有你从你的站点去请求你站点的资源，才会带上这些Cookie。

相比之下，SameSite的Lax选项相对宽松。在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交Get方式的表单这两种方式都会携带Cookie。但如果使用Post方法或在第三方站点中使用img、iframe等标签加载的URL，这些场景都不会携带Cookie。

总结来说，SameSite的Strict和Lax选项在处理跨站点请求时具有不同的规则，都旨在增强网站的安全性。

其他保护措施
幸运的是，许多（Web）应用程序框架现在都内置了处理CSRF攻击的支持。例如，Spring 和默认情况下，Tomcat 会启用此功能。只要你不关闭它（就像在 WebGoat 中一样），你应该不会受到 CSRF 攻击。

有关 CSRF 保护的更多信息，请参阅以下内容：

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html（预防/防御）

https://owasp.org/www-community/attacks/csrf（攻击）

https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CSRF_Prevention_Filter / https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#CSRF_Prevention_Filter （Tomcat）

https://docs.spring.io/spring-security/site/docs/current/reference/html5/#csrf

总结

CSRF本质是利用用户已登录网站，浏览器存储了网站的cookie，当向这个网站发送请求时，对服务端来说这个用户是认证的。
攻击者通过伪造请求，让用户执行某些操作。
攻击者伪造的请求中，referer字段与网站是不同源的，相当于跨域请求，当cookie的属性设置了same site为严格，则无法执行CSRF攻击。

CSRF和XSS区别

CSRF和XSS的区别体现在以下方面：

攻击方式：CSRF是利用网站A本身的漏洞，去请求网站A的api。XSS则是向网站 A 注入 JS代码，然后执行 JS 里的代码，篡改网站A的内容。
针对对象：XSS主要指向客户端，而CSRF针对服务端。
危害程度：CSRF相对于XSS漏洞的危害程度更高一些。
其他差异：CSRF相当于是XSS的基础版，CSRF能做到的XSS都可以做到。XSS是利用合法用户获取其信息，而CSRF是伪造成合法用户发起请求。
总的来说，CSRF和XSS在攻击方式、针对对象、危害程度以及其他方面都存在明显的差异。

Server-Side Request Forgery

01

概念
In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to. Moreover, by carefully selecting the URLs, the attacker may read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases, or perform post requests towards internal services that are not intended to be exposed.
在服务器端请求伪造（SSRF）攻击中，攻击者可以滥用服务器上的功能来读取或更新内部资源。攻击者可以提供或修改服务器上运行的代码将读取或提交数据的 URL。而且，通过仔细选择 URL，攻击者可能能够读取服务器配置（如 AWS 元数据）、连接到内部服务（如启用了 HTTP 的数据库）或对内部服务执行 POST 请求，而这些服务并不打算公开。

目标
在接下来的几页的练习中，您需要检查浏览器向服务器发送的内容，以及如何调整请求以从服务器获取其他内容。

SSRF 操作方法
https://www.hackerone.com/blog-How-To-Server-Side-Request-Forgery-SSRF

0x02

题目要求修改请求展示jerry的图像
在这里插入图片描述
点击steal the cheese 显示tom的图像

抓包，修改url为url=images%2Fjerry.png，发送请求。
在这里插入图片描述

0x03

题目要求修改请求，使服务器从给的地址获取信息
在这里插入图片描述

抓包，修改url为http://ifconfig.pro
在这里插入图片描述

04 如何防止SSRF？

使用允许的域、资源和协议的白名单，Web 服务器可以从中获取资源。
如果从用户接受的任何输入与预期的正面规范不匹配，则应进行验证和拒绝。
如果可能，请不要在控制 Web 服务器获取资源的位置的函数中接受用户输入。

参考：https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html

SSRF的讲解不是很清楚。

测试-东方不败之鸭梨

关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
1
评论
webgoat-Request Forgeries 请求伪造

跨站请求伪造，又称一键攻击或会话骑乘，简称CSRF （有时发音为 sea-surf）或 XSRF，是一种恶意利用网站，其中传输未经授权的命令来自网站信任的用户。与跨站点脚本（XSS）不同，XSS 利用用户对特定站点的信任，CSRF 利用网站对用户浏览器的信任。这是最简单的 CSRF 攻击。如果用户仍然登录到 bank.com 的网站，这个简单的GET请求会将资金从一个账户转移到另一个账户。当然，在大多数情况下，网站可能很多控制来限制这样的请求。
复制链接

扫一扫