涉及到的源码及部署的war github

 

用于演示Java Web项目中,漏洞的成因及修复方案,可用于黑盒测试和白盒测试,部分修复方案可用于生产环境。

包含以下缺陷:

  1. SQLi(字符型)
  2. XSS(反射型、存储型)
  3. 命令执行
  4. 任意文件上传
  5. 文件包含(任意文件下载)

其他功能:

  1. 解决中文乱码
  2. 敏感词过滤

开发环境及目录详细

开发环境

目录详细

过滤器及功能

过滤器

CharacterEncodingFilter 编码过滤器解决中文乱码

HtmlFilter 全局输出编码过滤器(HTML实体)

WordsFilter 敏感词过滤器

XssFilter XSS黑名单过滤器,可在此配置其他需要过滤的恶意字符如. ../ ? %等

功能

具备以下功能:

  1. 基于filter和<c:out>标签的XSS输出编码防护,黑名单为辅助防护方案

  2. 解决全站中文乱码

  3. 可配置敏感词汇,用于审核等

注意:对于输入没有净化,即多重编码数据没有还原

缺陷及修复方案

此项目包含缺陷及部分缺陷修复方案

SQLi(字符型)

缺陷代码

UserDaoImpl类,方法findUser直接拼接前端传入的username

修复方案

使用预编译

XSS(反射型、存储型)

a.未启用HtmlFilter、XssFilter且JSP页面没有用<c:out>标签,直接提交可以触发反射型,burp中跑payload可以触发存储型

b.启用XssFilter且JSP页面没有用<c:out>标签,可用黑名单之外的标签提交触发XSS

c.启用HtmlFilter、XssFilter且JSP页面使用<c:out>标签,二次编码的数据会解码一次后展现,此时无法触发XSS

缺陷代码

  1. xss.jsp向XSSServlet提交数据
  2. XSSServlet将数据保存到hMap集合,并存入request域,将请求转发到show.jsp
  3. show.jsp通过<c:forEach>标签取hMap中的数据,触发xss payload

修复方案

  1. 根据不同的场景采用输出编码,此处为HTML实体,所以使用了HTML实体输出编码

  2. 黑名单为辅助方案

  3. 净化输入

  4. 可以使用ESAPI进行不同场景的输出编码或自己实现,参考Java EE XSS防护Demo

命令执行

缺陷代码

CmdServlet类,使用ProcessBuilder直接执行前端传入的命令

修复方案

  1. 避免命令用户可控,如注释中所示

  2. 严格校验传入的命令,黑名单(总会被绕过,对吧),不建议

任意文件上传

缺陷代码

UploadServlet类直接处理上传文件

修复方案

  1. 见缺陷代码中,Content-Type及文件类型校验。

  2. 不建议采用黑名单

  3. 设置上传目录权限(WEB-INF默认不能直接访问,所以即使上传后也没有路径来访问文件)

  4. 随机上传文件的文件名及文件夹名

文件包含(任意文件下载)

缺陷代码

DownloadServlet类根据传入的filename直接下载文件

修复方案

  1. 过滤传入的路径,见缺陷代码中,恶意字符可在filter中配置,跟XSS黑名单一样(不过会被绕过?可能….)

  2. 判断下载路径是否合法,这个还没做…

演示

本处主要是演示黑盒测试,后续会有白盒测试的文章

页面是这样的…请无视样式

SQLi(字符型)

burp和SQLmap都没扫出来,可能代码里有坑….这跟平时黑盒测试一样,工具没扫出来,并且可能fortify也没扫出来…但是实际上缺陷是存在的。

burp结果:

SQLmap:

但是代码中是这样:

为哈没扫出来…可能代码里有坑>-<

XSS(反射型、存储型)

a:

  1. 手动触发反射型

当然毫无疑问会弹窗,因为没有输出编码

  1. burp触发存储型

    burp扫描结果(请无视反射型的):

    再访问提交后的页面,当然所有的payload都进来了,弹窗也就蹦沙卡拉了

b:

先看XssFilter配置的黑名单

由XssDefend中的stripXSS方法,对传入值进行UTF-8一次解码,这就是二次编码的数据在前端展示是一次编码的原因,之后根据正则匹配黑名单,显然,script和onload在黑名单中,不过绕过也太简单了….

页面提交<scirpt>alert(666)</scirpt>,全部被吃掉了,因为黑名单中匹配到了

换成<svg onclick=alert(666)>,提交后,点击触发XSS

如果此时,jsp取数据时用到是<c:out>标签,则无法触发XSS,但是…..你总会有漏掉的变量吧:)

此时<等已被编码,无法触发XSS

c:

需要注意过滤器的顺序

为什么用了过滤器就不用<c:out>标签

只用过滤器,不用<c:out>标签

 

此时,完成输出编码,以上可以知道,对于HTML实体而言,过滤器和<c:out>标签都是输出编码,实际上这两个代码是一样的….

但是使用<c:out>标签时,注意是否有遗漏的变量,如果涉及其他的输出编码,如输出到JS中,则需要自定义标签来输出

命令执行

执行gnome-terminal试试,弹个终端

如果是windows环境,可以calc.exe来弹计算器

不过burp中好像没扫出来…

任意文件上传

这一块就比较好玩了

  1. 仅校验Content-Type

上传个不是jpg的文件(md格式的),提示Content-Type不对…

那就把Content-Type修改成jpg的好了Content-Type: image/jpg

提示上传成功,然后查看了一下发布后的Web目录下的upload,嗯…多个了诡异的文件

此时应该可以任意文件上传了….en

  1. 同时校验Content-Type和后缀

这里后缀成合法的就可以了,可是1.jsp.jpg在tomcat上貌似没啥意思?….

结果是这样的,又多了个诡异的文件

那其它校验和绕过呢….代码没涉及到=-=

文件包含(任意文件下载)

先把过滤的去掉注释掉

我猜,burp会先试能不能下/etc/passwd….奇怪的是这次burp没跑出来…不过幸好我有上次的payload

手动敲payload

文件内容没啥好看的…

敏感词汇过滤

词汇如下

结果是这样

演示结果分析

可以看到在SQLi、命令执行、文件包含这三个缺陷中,burp没有扫出来…也许是代码里有坑…

XSS和文件上传(没扫)应该会有结果提示

此处应该需要白盒测试

部署说明

可以手动创建表,或者导入

数据库:root/root,可在dbcp.properties中指定

使用VulnWeb.warVulnWeb.sql部署

  1. 使用source导入数据库

    create database VulnWeb;

    use VulnWeb;

    source VulnWeb.sql路径(这里没有分号)

  2. 将VulnWeb.war复制到tomcat webapps目录下

  3. 启动tomat

  4. 访问http://127.0.0.1:8080/VulnWeb/

发表评论

电子邮件地址不会被公开。 必填项已用*标注