JAVA代码审计09:WEBGOAT Request Forgeries 请求伪造

常见的请求伪造有两种，第一种跨站请求伪造也就是我们的CSRF，第二种服务端请求伪造也就是我们的SSRF。

CSRF 通俗的说就是构造payload 然后诱导受害者点击，从而利用受害者的身份去做一些事情

SSRF 服务端请求伪造简单的来说就是，这个请求是服务端发起的，通常有的功能会存在从第三方的链接等获取资源，但是如果没有对资源来源进行一个限定那么就可以导致我们可以利用服务端来请求他本地或者他其中的内网信息

简单来说就是弄一个csrf的poc 获取我们的flag

我这里直接使用的是burp的功能

但是发现生成过程中是有问题的，当我们点击payload中的submit之后

发现burp传输过程中的数据最后面会有一个莫名其妙的等号

我们来查看一下我们的poc

我们进行一下解码

      <input type="hidden" name="{
  "name"    : "WebGoat",
  "email"   : "webgoat@webgoat.org",
  "content" : "WebGoat is the best!!"
}" value="" />

仔细观察发现这里的name value是键值对

name=value

所以像上图的poc的话 html中的结果就是如下

由于value为空所以便会出现如下这种情况

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

所以我们需要对poc进行改进，因为无论如何都有 = 所以我们得把等号包含进去

比如

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

Value 'sdfsdfdf"}

这样的话正常结果就是如下

name = value

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

题目要求我们去找到jerry的图片

发现请求了images下的tom图片，我们修改为jerry就可以了

看了看后端代码发现就是一个简单的判断语句，没啥好说的233

第二题让我们请求他给出的网址，也是很简单直接换成url即可

如下图

CSRF的修复方法很简单，因为csrf的本质就是攻击者知道对应的url导致可以进行伪造，那么我们只要添加随机化的token让攻击者无法伪造就可以了，当然也可以通过校验Referer来进行判断

SSRF的修复方法就是对请求的资源进行严格的过滤，如果发现请求到本地或者内网的资源返回不合法等信息即可

做一个总结，这个章节相比之前后端代码不那么贴近真实环境，算是为了做靶场而写的所以代码审计也做不了什么，只能说是提供提供思路这种，所以这篇文章只是简单的介绍了题解但是没有着重介绍后端代码的原因

发送评论 编辑评论