Expanding archive files without controlling resource consumption is security-sensitive

[kevinhagel]

Describe the bug
See issue https://github.com/webforj/webforj/security/advisories/GHSA-qxgc-w4c2-c7mh
See sonar description: Expanding archive files without controlling resource consumption is security-sensitive java:S5042

As described in the security advisory issue, unchecked use of zip.getEntries() and unchecked opening of the expanded entry are a minor security issue, possible DOS issue, described as a zip bomb attack from a user uploading the 'right kind' of jar file.

Successful Zip Bomb attacks occur when an application expands untrusted archive files without controlling the size of the expanded data, which can lead to denial of service. A Zip bomb is usually a malicious archive file of a few kilobytes of compressed data but turned into gigabytes of uncompressed data. To achieve this extreme compression ratio, attackers will compress irrelevant data (eg: a long string of repeated bytes).

Expected behavior
The sonar issue describes a compliant solution for measuring the size of each file in the archive, the ratio of compression, and the number of file entries in the archive.

• Implement this solution. Create a processor that loads and validates zip entries, shared by the zip file entries in the application.
• Refactor WebforjInstaller and MavenBinaryInstaller to use the new validating zip file processor.

Software Versions (please complete the following information)

• Java Version: 17+
• Webforj version: [e.g 24.00]

Additional context
Add any other context about the problem here.