这个OA是os_system；不能算一个大众的oa；只能说是一个小型的oa；简单审计一下看看效果；
打开项目先看依赖很显然的看到是springboot+mybaits+freemarker+bootstrap组合，那么针对于这种一般sql注入是很难进行攻击，往往在一些敏感的输入点，会利用mybatits的#{}进行接收参数；其本质上也是利用了jdbc的preparement；但是还是抱着试一试的态度进行相关的审计，这种入口点我喜欢直接看数据持久层mapper；
一个显然的点映入眼帘，这个也是sql的一个明显利用点，尽管使用了mybatis可以避免大多数sql注入；但是like或者order by之类的是无法进行相关的预处理；所以这里显然是一个漏洞利用点；回溯一下看看；
可以看到在此进行了调用；然后在路由的地方直接拿到了baseKey参数的值，并且没有对baseKey的值进行相关的处理；意味着完全可控；那么就很显然的一个利用点；本地起一个数据库简单的测试一下；
显然可以报错；那么直接传入看下效果；
发现无回显；意料之中，因为报错注入一般的情况下是要后端处理将错误信息抛出在前端才可进行有效的攻击，为什么说有效；我们虽然无回显，但是已经攻击成功；
这个点是可以进行注入；尽管无法进行报错注入；但是可以尝试盲注；经过一些测试；
可以看到盲注是可以的hhh；直接可以拿到内容了；挺好；
那么同理，其他的一些地方也可造成sql注入；
还有一些地方都可进行注入，这里不多举例子了，有兴趣可以自行下载看一下；
然后看一个文件上传的点；
看到相关的路由，我的第一想法是能否直接进行跨目录上传，因为springboot摒弃了传统的jsp；所以尽管上传jsp文件也是无法进行有效的攻击的，所以只能从上传jar这类的方式进行入手，尽管上传jar后续的利用也很苦恼，不过还是先来看看是否可以利用；上面是controller的代码；看到是调用了savafile方法，跟进去，
可以看到相关的上传目录并不是我们想的path+filename拼接的那样，而是直接按照拿到rootPath然后拼接根据时间生成的path；接着往下看一下发现更狠一点；
可以清楚的看到生成了新的filename但是有意思的是没有对后缀进行相关的处理，估计是因为springboot的原因，内部也使用了相关的模版，所以上传一般的文件是无法有用的，当然这里也可考虑模版注入；模版引擎是freemarker；考虑到模版注入。所以直接先测试一下：
可以看到已经被解析，那么我们可以上传一个模版文件进行注入解析；先在原本的模版里修改一下尝试触发rce；
可看到已经触发rce；现在思路就很明显了，直接上传模版文件造成注入；测试一下：发现无法直接读取到，我随后又找了一个图片预览的地方，发现是直接将数据输出了；看一下后端的逻辑：
可以看到后面是直接去数据库里进行find；然后拿到数据列表，然后从列表里get到相关的file；所以这里想要跨目录读也是有点不太现实的，因为是直接从数据库里只直接find了；不是从系统里find；
而且这个最后的输出也是直接进行底层流的操作，所以无法进行相关的渲染；所以这个点还是最终G；因为文件的操作是基于数据库的，而且最开始存入的路径已经无法进行修改；
后来看到可以移动文件，但是看了下相关的处理；
发现最开始的topath就是已经拦住了，可以看到都是在数据库里进行搜素，然后拿到相关的path；贴一下数据库的图：
很清晰了，路径都是传入的时候固定的，如果想要将ftl移动到相关的目录之下去覆盖一些ftl，就需要有对应的sql数据，但是很可惜没有，一些sql注入也无法进行堆叠，所以也无发修改相关的内容；总的来说这个项目的文件相关点设置的很完美，一些路径都采用硬编码，一些filename都要进行二次加密之后存放，操作的时候也会去数据库进行相关的映射，所以对于文件来说还是很安全的；
后续的一些测试中，我也发现了一些xss漏洞点，这里就不细说了；因为其cookie设置了httponly属性，所以也很难拿到相关的cookie；总体而言项目除了sql注入那个点整体还是比较的安全的；