
前言
这里包括两个内容:xxe和csrf。
为什么归类在错误的安全配置里,我觉得是这两个漏洞的修复主要依靠各种配置,不太涉及到大量的代码修改,修复过程不容易对业务产生影响。
刚接触网安的时候,学的是ctf。由于ctf里没遇到过太多xxe和csrf的题目,所以这一块知识一直很薄弱,借此机会巩固一下。
xxe
基础复习
又去问了AI,发现了以前没注意的一些点。
1、DTD中,通用实体不能直接引用参数实体
1 |
|
上面的例子中,% all 这种带百分号的,就是参数实体,只能在DTD中使用。
一开始我在想,为什么不直接写 ,而是要用 %all 套一层。后面才知道通用实体直接引用参数实体会报错。
最后的poc:
1 |
|
第一题
很简单,直接通过file协议读文件就行。记得注入的实体要写在text标签内,这样才能回显在评论区,才满足题目要求。同时注意一下windows下调用file协议读文件的格式,file:///C:/
源码部分,重点在org.owasp.webgoat.lessons.xxe.CommentsCache#parseXml:
这里调用xml解析时,securityEnabled默认是false的,所以运行外部实体和DTD。想要修复漏洞也很简单,把这些配置打开即可。由于业务中一般不会用到外部实体,所以对正常业务没有影响。
第二题
就是抓包手动将Content-Type改成application/xml。payload和上面一致。
源码部分就是根据Content-Type进入不同方法,没什么好说的
第三题
无回显的xxe。
先看exp:
dtd文件:
1 |
|
数据包:
1 |
|
收到请求,记得url解码:
下面介绍几种常见的错误写法:
1、直接引用参数实体
1 |
|
这两种写法都会报错:参数实体引用 “%test;” 不能出现在 DTD 的内部子集中的标记内
所以不能直接创建一个%file,然后在下面的send 中直接引用
2、不远程加载dtd,直接写到数据包中
我一开始想,为什么不直接写到请求体里,效果不是一样吗,就像这样:
1 |
|
然而,这里的报错和上面的是一样的。
上面问题的原因都是一样的,就是xml1.0不允许这种语法,即不允许內部子集(没有用SYSTEM的)引用参数实体。但是通过dtd加载可以绕过这种限制。
3、%file引用未生效
1 |
|
这种情况,%file不会解析
总之,很多情况下我们都需要依赖dtd去远程加载,然后再到主文档里展开。
csrf
第一题
让你从非同源的host点击按钮,这里可以用到bp自带的工具:
这样可以直接生成一个表单,然后从非同源位置提交:
源码方法,这里主要是根据referer和host的关系来判断:
第二题
基本一样,但是这里多了一个weakAntiCSRF,相当于一个token吧,但是这个token是固定的,所以没有起到防护作用。
第三题
这里主要考查的是 怎么通过表单提交json格式的数据。
我们跟之前一样,直接用bp自带的工具产生的表单在提交时会出现一个问题,即数据最后会有一个等号,导致报错:
这是由于我们提交的是一个表单,表单肯定时param=value这样的形式,但是我们的value实际为空:
因此会产生这个问题。要做的就是改变value的值,使json闭合。可以这样设置:
这样就行了:
源码没什么可讲的,就是按之前的逻辑判断,再加一个对Content-Type的判断。
第四题
模拟受害者无意中登录攻击者的账号,攻击者从而可以记录受害者在此账号上的活动记录。
去另外注册一个csrf-xxxx,xxx是你的用户名,然后点击题目对应的按钮就行。
小结
这里先简单过一遍,详细的后面遇到具体问题再补充