You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello everyone!
I have noticed that extract-zip correctly checks for relative and absolute paths in a zip target filename to avoid an arbitrary file read and write like zip-slip.
Unfortunately there are some scenarios in which an attacker can obtain a similar result using a symlink contained in a zip archive, for example if the web server renders the original contents of the archive.
To avoid the disruption of what might be an expected functionality, it should be feasible to simply add a flag to state if the user wants to have symlinks extracted or not, like
--- a/index.js
+++ b/index.js
@@ -124,7 +124,9 @@ class Extractor {
debug('opening read stream', dest)
const readStream = await promisify(this.zipfile.openReadStream.bind(this.zipfile))(entry)
- if (symlink) {
+ if (symlink && this.opts.no_symlink) {
+ throw new Error(`Unallowed to decompress symlink: ${entry.filename}`)
+ } else if (symlink) {
The only issue I see is that it would require to change how user options are parsed, as at the moment only one argument is expected.
Would you be interested in such a feature?
The text was updated successfully, but these errors were encountered:
Hello everyone!
I have noticed that
extract-zip
correctly checks for relative and absolute paths in a zip target filename to avoid an arbitrary file read and write like zip-slip.Unfortunately there are some scenarios in which an attacker can obtain a similar result using a symlink contained in a zip archive, for example if the web server renders the original contents of the archive.
To avoid the disruption of what might be an expected functionality, it should be feasible to simply add a flag to state if the user wants to have symlinks extracted or not, like
The only issue I see is that it would require to change how user options are parsed, as at the moment only one argument is expected.
Would you be interested in such a feature?
The text was updated successfully, but these errors were encountered: