OASYS代码审计

项目技术分析

根据项目readme文档可知，该项目采用了如下技术：

代码审计

XSS漏洞

直接全局搜索XSS，发现未使用XSS相关过滤器进行过滤，猜测应该是没有XSS相关防护。

随后简单的看了一下Controller和Service层，发现也没有什么过滤机制，貌似直接带入了dao层进行数据库操作。

调用的dao层的save方法也是jpa框架封装好的save方法。

所以确定是没有XSS过滤的。

直接去复现，在用户面板-写便签处存在XSS漏洞。

CSRF漏洞

CSRF漏洞可能出现的场景：更改个人信息，添加修改资料，关注/取关用户，发布主题或者信息。

常见的漏洞点在于见擦汗是否校验Referer，是否给cookie设置samesite属性，敏感操作是否会生成CSRFtoken，如果都不存在再查看请求参数中是否存在不可被攻击者猜测的字段，比如验证码等参数。

就在刚才的写便签处来抓包，发现，包中并不存在防止CSRF的token，也没有给cookie设置samesite属性。

https://blog.csdn.net/weixin_47450807/article/details/123248357

所以推测存在CSRF漏洞。

使用burp的自带生成csrf。

点击后发现已经触发csrf漏洞。

越权漏洞

在日程管理删除处存在越权漏洞，可以越权删除他人的日程管理。

@RequestMapping("dayremove")
	public String dayremove(@RequestParam(value="rcid") Long rcid){
		ScheduleList rc = daydao.findOne(rcid);
		
		daydao.delete(rc);
		
		return "/daymanage";
	}

但从这行代码看，仅仅是查询了rcid参数后，进行了删除。从上面可以看出，使用了daydao.findone来操作rcid，查看daydao发现来自daymanageDao.java

但是daydao里面也没有发现findone这个方法，于是又去看jparepository，发现里面也没有findone方法，最后在jparepository的父类querybyExampleExcute看到了原来有这个方法。

所以我们可以确定这个方法来自于框架，没有做什么处理。

接着去看delete方法，发现delete也是一个框架方法

最后，我们回顾整个流程，也就是说查询了rcid的值，然后进⾏删除。整个流程没有任何权限的验 证，因此导致了越权的操作。

当然如果使用了权限校验相关的框架，那就另当别论了。

验证：首先使用管理员账户去登陆抓删除日程得包。

接着使用一个低权限账户去抓包删除

将13改为3

删除成功，证明漏洞存在。

去数据库中看也发现id为3得信息没有了