Java provides the java.util.zip package for zip-compatible data compression. It provides classes that allow you to read, create, and modify ZIP and GZIP file formats.
There are a number of security concerns when extracting file entries from a ZIP file using Be careful when extracting entries from java.util.zip.ZipInputStream. Two particular issues to avoid are entry file names that canonicalize to a path File names may contain path traversal information so that they are extracted outside of the target intended directory, frequently with the purpose of overwriting existing system files. Directory traversal or path equivalence vulnerabilities can be eliminated by canonicalizing the path name per IDS02-J. Canonicalize path names before validating them) and then validating the location before extraction.
A second issue is that the extraction and entries that cause excessive consumption of excessive system resources. In the former case, an attacker can write arbitrary data from the zip file into any directories accessible to the user. In the latter case, This may result in a denial of service can occur attack when resource usage is disproportionately large in comparison to the input data that causes the resource usage. The nature of the zip algorithm permits the existence of zip bombs in which a small file, such as ZIPs, GIFs, and gzip-encoded HTTP content, consumes excessive resources when uncompressed because of extreme compression.The zip algorithm can produce very large compression ratios [Mahmoud 2002]. For example, a file consisting of alternating lines of a characters and b characters can achieve a compression ratio of more than 200 to 1. Even higher compression ratios can be easily obtained using input data that is targeted to the compression algorithm, or using more input data (that is untargeted), or using other compression methods. Any entry targeting a file not within the directory intended by the client program (after file name canonicalization, as per IDS02-J. Canonicalize path names before validating them), must not be extracted or must be extracted to a safe location. Any entry in a zip file whose uncompressed file size is beyond a certain limit must not be uncompressed. The actual limit is dependent This permits the existence of zip bombs in which a small file ZIP and GZIP file consumes excessive resources when uncompressed because of extreme compression. Another example of a zip bomb is the file 42.zip which is a zip file consisting of 42 kilobytes of compressed data, containing five layers of nested zip files in sets of 16, each bottom layer archive containing a 4.3 gigabyte (4 294 967 295 bytes; ~ 3.99 GiB) file for a total of 4.5 petabytes (4 503 599 626 321 920 bytes; ~ 3.99 PiB) of uncompressed data. Zip bombs often rely on repetition of identical files to achieve their extreme compression ratios. Programs must either limit the traversal of such files or refuse to extract data beyond a certain limit. The actual limit depends on the capabilities of the platform and expected usage.
Noncompliant Code Example
...