记. ZIP炸弹防御问题

本文讲述了在遇到ZIP炸弹攻击时,后台系统未能有效识别的问题。通过排查,发现校验ZIP解压大小的代码存在缺陷。文章详细描述了从问题定位、代码阅读到寻找替代方案的过程,包括遇到的`ZipException`和编码问题,并最终优化了解压大小计算的效率。
摘要由CSDN通过智能技术生成

背景:

测试组搞了个“ZIP炸弹”传给后台,发现后台并没有识别,一度怀疑后台是不是偷懒了压根没有做安全校验。

于是,激动万分地给我提了个单。

排查:

阅读同事的代码,发现有做校验,步骤如下:

  1. 第一步,校验ZIP压缩包大小。
  2. 第二步,校验ZIP压缩包解压后的大小。

于是随便拿了个ZIP包本地验了一把,明明算得很准啊,一个字节都不差,是不是测试搞错了?!

再去测试组要了他们搞出来的变态ZIP包验了一把,发现校验得出的解压大小比实际小了许多。

问题:

显然,问题就出在第二步。

有个ZipUtil工具类,注释清一色地道英文,不知道原作者是哪位大神,也不知最初是谁从哪里拷过来的。

这个类提供的校验方法是通过传入ZIP文件的输入流,然后一顿字节操作猛如虎得出解压大小。计算过程涉及的变量和运算没有任何注释,看不懂啊——我摊牌了!

解决:

既然看不懂改不动,网上找替代方案吧。

很快,找到了一个方法改造一下:

/**
  * 计算ZIP文件的解压大小
  * 
  * @param filePath 文件路径
  * @return 解压大小
  */
public static long getUncompressedSize(String filePath) throws IOException {
    ZipFile zipFile = new ZipFile(filePath);
	
    long 
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值