JAVA安全—目录遍历访问控制XSS等安全问题

JAVA安全—目录遍历访问控制XSS等安全问题

7b1ab264cf4274f3454e2bc55c2ae52c

我的那个靶场不知道抽什么风,又打不开了,无大语了

Snipaste_2022-06-09_09-24-12

这关过关技巧就是将文件名,改成一个..\的方式,从而达到上传到其他目录的效果,那么这样做的意义是什么?目录解析:简单来说就是有的目录进行了一些权限设置,那么你的文件或者说是后门上传到了这个权限受限的目录,就会出现后门执行不了等等的情况,所以说如果用这个方法是有机会绕过的

第二关

比第一关,多了一个过滤,下图是源码

Snipaste_2022-06-09_09-40-32

  • 发现return中的执行语句多了一个判断,表单中的用户名不为空,并且用户名中的../用空替换掉
  • 这里的../只被replace过滤了一次,可以通过....//123重复构造来进行绕过

Snipaste_2022-06-09_09-42-48

可以直接用双写的方法进行绕过,也就是像上图一样多写一次,这样匹配替换一次,就刚好可以拼接上

前端验证

Snipaste_2022-06-09_09-54-59

账号和密码就写在这个前端的js文件中

对象引用

Snipaste_2022-06-09_09-58-12

—在文本输入框中输入role,userid过关(这是用户的另外两个属性,我也不知道从哪里得来的)

源代码分析

---@PostMApping({“/IDOR/diff-attributes”})提交数据的地址

—将传递的参数trim()去空—将参数以逗号分隔传递给数组diffAttribs,也就是说diffAttribs[0]=role, diffAttribs[1]=userid—如果数组长度<2报错(传递了2个以上参数)—判断数组[0/1]的小写,去空后的值是否=role/userid—是的话返回idor.diff.success(emmmm但是这里我不知道这是啥意思)

水平越权

—继承AssignmentEndpoint(这里应该是页面模板)

—接受参数URL,赋值给字符串URL

—如果用户的session值是Tom的话,执行以下操作

—从session中获取用户授权id

—将URL传参以**/**分割为数组

—如果数组元素第一个为webgoat,并且第二个为idor,并且第三个为profile,且第四个为授权用户id的话

—就创建一个用户预文件对象(传参授权id)

—返回成功界面

Snipaste_2022-06-09_10-09-58

—创建一个用户session会话的私有对象(用hashmap的方式,我觉得这里可以把它看成一个栈)(这里的hashmap是以键值对的形式储存,)

—传参key和value调用设置数值的方法

—在设置数值的方法中,检测栈中的key值是否存在,存在就返回key值(这里应该就是前面的用户授权id)

—然后用value替换到这个key所属键值对应的值

—如果栈中的key值不存在的话,就往hashmap里面添加键值对

—这一部分代码就是检测session中的授权id是否在hashmap中,不在就添加(但是在下面预文件类中,只有两个特有id才能为hashmap赋值,因次,也就是检测用户授权id是否等于两个特有的值)

Snipaste_2022-06-09_10-10-16

—在用户预文件中对象中,设置存在的属性和方法(传参用户授权id)(调用设置预文件表格id函数

Snipaste_2022-06-09_10-10-40

—设置预文件表格id函数中,比对授权id的值来为预文件类的属性(这里就是页面回显的数据)

Snipaste_2022-06-09_10-10-55

\5. 构造payload

—WebGoat/IDOR/profile/2342384

—漏洞的含义:接口uid=1,2,3等等,每一个不同的值会对应不同的用户

—这里应该是变换授权id(key)值来对应不同的用户的信息(hashmap里面的键值对)(key和value,这里面只有两个用户信息)

—漏洞存在的原因:这里好像没有验证cookie(这里的session的产生机制好像不是cookie里面的,而是涉及hashmap)

Javaweb 代码分析-XSS 跨站安全问题

\1. 进入靶场

Snipaste_2022-06-09_10-11-38

#抓包分析

—查看指向文件和传参

Snipaste_2022-06-09_10-11-53

\2. 源代码分析

—访问网页路径

—传参赋值给字符串

—如果字符串的小写(转化为字符串格式)==yes,就返回成功

\3. 进入第七关

—确定下面哪一个字段容易受到XSS攻击(管理员查看订单时被攻击)

Snipaste_2022-06-09_10-12-09

#抓取数据包分析

—这里传递了六个参数:QTY1-4;field1-2

Snipaste_2022-06-09_10-12-37

\4. 源代码分析

—field2匹配XSS的关键字过滤(感觉这里可以绕过)

— QTY1-4是数值型变量,无法进行XSS攻击,

—field2的return后面其实是有一个else语句,构成if匹配到XSS,就返回失败,没匹配到,就执行创建对象的语句等等(这里根小迪的有区别,视频中的field2如果正确就直接执行创建对象就过关了)

—然后再匹配field1的关键字过滤(这里感觉多了一步过滤,即field1小写如果包含在console.log)(好像又不是,迪总是从页面回显功能,来判断XSS注入点的)

—绕过思路:field2正常,在field1处进行XSS注入

Snipaste_2022-06-09_10-12-42

\5. 根据回显判断XSS的写入点

—这里回显了信用卡的id和购物的总金额(XSS注入点可能是cardid这里(从回显功能来说))

Snipaste_2022-06-09_10-13-12

—构造payload

Snipaste_2022-06-09_10-13-26

Snipaste_2022-06-09_10-13-29

拓展-安卓 App 反编译 JAVA 代码(审计不香吗?)

原理分析

—将apk文件拖动进去之后,会在工具的路径下生成jar的包

—然后用idea或者jd打开之后,进行Java的代码审计

3.一键提取apk的URL

—将apk文件放在“Apps”文件夹下运行apkAnalyser.exe,程序会在“result”文件夹下创建以apk文件名命名的文件夹来存放反编译文件

—文件夹中有“urls.txt”存放apk中涉及网站,没有该文件则没有对应内容

Snipaste_2022-06-09_10-14-26