엑셀 업로드 중 발생한 Zip Bomb 에러 파헤치기! 🥊

고객사가 올린 엑셀(.xlsx) 업로드가 Apache POI의 "Zip bomb detected" 오류로 막힌 사건을, 엑셀이 실은 압축 파일이라는 사실부터 POI의 압축비 검사 원리까지 풀어낸 글이다.

핵심 포인트

.xlsx는 여러 XML을 담은 ZIP 구조라, Apache POI가 XSSFWorkbook 생성 시 압축을 풀며 압축비(compressed/uncompressed)를 검사한다.
압축 해제 크기와 원본 크기의 비율이 POI 기본값 MIN_INFLATE_RATIO(0.01, 약 100배)를 넘으면 Zip Bomb으로 보고 예외를 던진다.
실제 원인은 악성 파일이 아니라 styles.xml에 동일 셀 스타일 정의가 과도하게 반복돼 압축률이 비정상적으로 높아진 정상 파일이었다.
계약된 사용자만 접근하는 서비스라 공격 가능성이 낮다고 보고, 1차로 ZipSecureFile.setMinInflateRatio 값을 낮춰 검사를 완화했다.

상세 정리

증상: 고객사 엑셀 업로드 기능에서 "Zip bomb detected! ... exceed the max ratio" 오류로 처리가 실패했다.
Zip Bomb 개념: 작게 압축돼 있지만 풀면 메모리·디스크를 폭증시켜 시스템을 마비시키는 공격 방식으로, 열기 전엔 예측이 어렵다.
엑셀=압축파일: unzip으로 풀면 xl, docProps, _rels 등 폴더와 XML이 나오고, POI는 이 ZIP을 풀며 각 항목의 압축비를 본다.
로그 해석: Uncompressed 406,416 bytes, compressed 4,059 bytes, Ratio 0.009987로, 시스템 한계 0.010000을 근소하게 넘겨 경고가 발생했다.
범인 파일: 문제 엔트리는 xl/styles.xml로, dxf(폰트·fill 등) 셀 스타일 정의가 반복돼 있었다.
왜 압축률이 튀나: ZIP/gzip은 반복 패턴을 짧은 코드로 치환하므로 같은 스타일 반복이 많을수록 압축률이 극단적으로 높아져 Zip Bomb으로 오인된다.
방어 방법 검토: (1) setMinInflateRatio로 최소 압축비 조정, (2) 각 엔트리 getSize 합으로 총 해제 크기 제한(MAX_ALLOWED_SIZE), (3) getDepth로 중첩 압축 레벨 제한.
최종 조치: 신뢰된 사용자 대상이라 판단해 압축비 검사 완화를 1차 적용하고, 근본적 보안 대책은 추후 마련하기로 했다.