Contents
V5338. OWASP. Possible Zip Slip vulnerability. Potentially tainted data might be used to extract the file.
The analyzer detected that a file name obtained from an archive is used as a path to a file or directory without a prior check. If the file name contains "dot-dot-slash" sequences, operations with this file can lead to a Zip Slip vulnerability in the application.
This attack type is classified under specific risk categories in the OWASP Top 10 Application Security Risks.
To execute a Zip Slip attack, an attacker provides a malicious archive containing files with "dot-dot-slash" sequences in their names (../../evil.csx). By triggering the extraction of such an archive, an attacker can overwrite any files that the application has access to.
While most archiving tools and OSs have built-in restrictions that prevent creating files names of ../../evil.csx type, some tools allow this operation, making the Zip Slip attack possible.
The example:
public void extractArchive(String destinationDir, ZipFile zip) {
Enumeration<? extends ZipEntry> entries = zip.entries();
while (entries.hasMoreElements()) {
ZipEntry entry = entries.nextElement();
File file = new File(destinationDir, entry.getName());
InputStream input = zip.getInputStream(entry);
IOUtils.copy(input, new WriterOutputStream(new FileWriter(file)));
}
}This method takes an archive and extracts it into destinationDir. However, the path for the extracted file is created directly from the name in the archive, making this code vulnerable to Zip Slip. If a malicious archive gets into the application, it can be unpacked anywhere on the system that the application has access to.
To protect against Zip Slip, check whether the target path is located inside the source directory. In the scenario above, it is recommended to use the getCanonicalPath() method to convert the path to a standard form—a path without relative transitions .., . and redundant separators—followed by the check via startsWith(destinationDir). This prevents access to files outside the allowed directory, even if the path contains masked relative transitions, for example, ../../evil.csx.
The extraction process for any archive is expected to be secured. The diagnostic rule considers all archives to be external entities and potentially suspicious.
The fixed example:
public void extractArchive(String destinationDir, ZipFile zip) {
Enumeration<? extends ZipEntry> entries = zip.entries();
while (entries.hasMoreElements()) {
ZipEntry entry = entries.nextElement();
File file = new File(destinationDir, entry.getName());
if (file.getCanonicalPath().startsWith(destinationDir)) {
InputStream input = zip.getInputStream(entry);
IOUtils.copy(input, new WriterOutputStream(new FileWriter(file)));
}
}
}This diagnostic is classified as:
Was this page helpful?
