项目技术分析
根据readme和pom文档可以知道该项目采用了以下技术:
1 | <dependencies> |
项目结构很清楚,不做过多阐述。
代码审计
XSS漏洞
仍然先从简单的XSS开始看,全局搜索XSS关键字,虽然有很多包含XSS的词语,但是感觉都不像是XSS过滤器,因此怀疑存在XSS漏洞。
随意的在一个业务系统下进行测试。
逻辑漏洞
任意密码重置
全局输入resetPasswd
可以发现无论是TeacherController
或者StudentController
中描述的重置密码方式都没有做有效的权限验证。
1 | public String resetPasswrd(String id) { |
以Teacher为例子,在Controller层中没有发现对权限有相关过滤代码,只有单纯的获得id。接下来去看teacherServiceimpl
层里面的东西,其中的updateTeacher
也是直接去调用了dao
层updateTeacher
方法。
1 |
|
所以我猜测应该是存在任意重置密码的漏洞的
这个业务本来只能让管理员访问,但是我用了一下普通教师的账户,去访问该路由/teacher/resetPswd
对应了源码中的”修改失败”,所以觉得八成是存在该漏洞。
我以id为1560321的身份访问/teacher/resetPswd?id=1560322
,回弹true,并且在数据库中查看修改成功。
证明漏洞存在。
同时如果用学生账户,也可以重置其他任意学生的账户。
任意用户删除
同时举一反三,发现其/teacher/delete
功能也有同样的毛病,可以直接删除同一权限下的其他账户。
使用id为1560321的老师账户访问以下路由:
/teacher/delete?id=1560322
可以看到已经删除成功了。
CSRF漏洞(比较鸡肋)
CSRF主要是看代码中是否校验Referer
,是否给cookie设置Samesite
属性,敏感操作是否生成CSRFtoken
,如果都不存在的话,就看请求参数中是否存在不可被攻击者猜测的字段,比如验证码等参数。
在每个账户修改密码的业务系统中,抓包可以发现:
发现并没有相关做验证的字段,手工进行验证,生成CSRFPOC
。使用管理员账户,登录系统后,点击poc。
但是比较鸡肋的一点就在于,他需要输入旧密码在后端进行验证。
这里就没有什么办法,但是如果你是以老师或者学生的身份,可以先去重置它的默认密码,然后进行修改。