PK :PP⟿ VULNERABILITIES.mdnu ٘ # List of fixed vulnerabilities
## Contents
- [Potential vulnerabilities with PHP+ImageMagick](#potential-vulnerabilities-with-phpimagemagick)
- [Remote code execution vulnerability in the PHP component](#remote-code-execution-vulnerability-in-the-php-component)
- [Open redirect vulnerability in the GAE components](#open-redirect-vulnerability-in-the-gae-components)
- [Cross-site scripting vulnerability in the Iframe Transport](#cross-site-scripting-vulnerability-in-the-iframe-transport)
## Potential vulnerabilities with PHP+ImageMagick
> Mitigated: 2018-10-25 (GMT)
The sample [PHP upload handler](server/php/UploadHandler.php) before
[v9.25.1](https://github.com/blueimp/jQuery-File-Upload/releases/tag/v9.25.1)
did not validate file signatures before invoking
[ImageMagick](https://www.imagemagick.org/) (via
[Imagick](https://php.net/manual/en/book.imagick.php)).
Verifying those
[magic bytes](https://en.wikipedia.org/wiki/List_of_file_signatures) mitigates
potential vulnerabilities when handling input files other than `GIF/JPEG/PNG`.
Please also configure ImageMagick to only enable the coders required for
`GIF/JPEG/PNG` processing, e.g. with the sample
[ImageMagick config](SECURITY.md#imagemagick-config).
**Further information:**
- Commit containing the mitigation:
[fe44d34](https://github.com/blueimp/jQuery-File-Upload/commit/fe44d34be43be32c6b8d507932f318dababb25dd)
- [ImageTragick](https://imagetragick.com/)
- [CERT Vulnerability Note VU#332928](https://www.kb.cert.org/vuls/id/332928)
- [ImageMagick CVE entries](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=imagemagick)
## Remote code execution vulnerability in the PHP component
> Fixed: 2018-10-23 (GMT)
The sample [PHP upload handler](server/php/UploadHandler.php) before
[v9.24.1](https://github.com/blueimp/jQuery-File-Upload/releases/tag/v9.24.1)
allowed to upload all file types by default.
This opens up a remote code execution vulnerability, unless the server is
configured to not execute (PHP) files in the upload directory
(`server/php/files`).
The provided [.htaccess](server/php/files/.htaccess) file includes instructions
for Apache to disable script execution, however
[.htaccess support](https://httpd.apache.org/docs/current/howto/htaccess.html)
is disabled by default since Apache `v2.3.9` via
[AllowOverride Directive](https://httpd.apache.org/docs/current/mod/core.html#allowoverride).
**You are affected if you:**
1. A) Uploaded jQuery File Upload < `v9.24.1` on a Webserver that executes files
with `.php` as part of the file extension (e.g. "example.php.png"), e.g.
Apache with `mod_php` enabled and the following directive (_not a recommended
configuration_):
```ApacheConf
AddHandler php5-script .php
```
B) Uploaded jQuery File Upload < `v9.22.1` on a Webserver that executes files
with the file extension `.php`, e.g. Apache with `mod_php` enabled and the
following directive:
```ApacheConf
SetHandler application/x-httpd-php
```
2. Did not actively configure your Webserver to not execute files in the upload
directory (`server/php/files`).
3. Are running Apache `v2.3.9+` with the default `AllowOverride` Directive set
to `None` or another Webserver with no `.htaccess` support.
**How to fix it:**
1. Upgrade to the latest version of jQuery File Upload.
2. Configure your Webserver to not execute files in the upload directory, e.g.
with the [sample Apache configuration](SECURITY.md#apache-config)
**Further information:**
- Commits containing the security fix:
[aeb47e5](https://github.com/blueimp/jQuery-File-Upload/commit/aeb47e51c67df8a504b7726595576c1c66b5dc2f),
[ad4aefd](https://github.com/blueimp/jQuery-File-Upload/commit/ad4aefd96e4056deab6fea2690f0d8cf56bb2d7d)
- [Full disclosure post on Hacker News](https://news.ycombinator.com/item?id=18267309).
- [CVE-2018-9206](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9206)
- [OWASP - Unrestricted File Upload](https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload)
## Open redirect vulnerability in the GAE components
> Fixed: 2015-06-12 (GMT)
The sample Google App Engine upload handlers before
v[9.10.1](https://github.com/blueimp/jQuery-File-Upload/releases/tag/9.10.1)
accepted any URL as redirect target, making it possible to use the Webserver's
domain for phishing attacks.
**Further information:**
- Commit containing the security fix:
[f74d2a8](https://github.com/blueimp/jQuery-File-Upload/commit/f74d2a8c3e3b1e8e336678d2899facd5bcdb589f)
- [OWASP - Unvalidated Redirects and Forwards Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html)
## Cross-site scripting vulnerability in the Iframe Transport
> Fixed: 2012-08-09 (GMT)
The [redirect page](cors/result.html) for the
[Iframe Transport](js/jquery.iframe-transport.js) before commit
[4175032](https://github.com/blueimp/jQuery-File-Upload/commit/41750323a464e848856dc4c5c940663498beb74a)
(_fixed in all tagged releases_) allowed executing arbitrary JavaScript in the
context of the Webserver.
**Further information:**
- Commit containing the security fix:
[4175032](https://github.com/blueimp/jQuery-File-Upload/commit/41750323a464e848856dc4c5c940663498beb74a)
- [OWASP - Cross-site Scripting (XSS)](https://owasp.org/www-community/attacks/xss/)
PK :PP˯ SECURITY.mdnu ٘ # File Upload Security
## Contents
- [Introduction](#introduction)
- [Purpose of this project](#purpose-of-this-project)
- [Mitigations against file upload risks](#mitigations-against-file-upload-risks)
- [Prevent code execution on the server](#prevent-code-execution-on-the-server)
- [Prevent code execution in the browser](#prevent-code-execution-in-the-browser)
- [Prevent distribution of malware](#prevent-distribution-of-malware)
- [Secure file upload serving configurations](#secure-file-upload-serving-configurations)
- [Apache config](#apache-config)
- [NGINX config](#nginx-config)
- [Secure image processing configurations](#secure-image-processing-configurations)
- [ImageMagick config](#imagemagick-config)
## Introduction
For an in-depth understanding of the potential security risks of providing file
uploads and possible mitigations, please refer to the
[OWASP - Unrestricted File Upload](https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload)
documentation.
To securely setup the project to serve uploaded files, please refer to the
sample
[Secure file upload serving configurations](#secure-file-upload-serving-configurations).
To mitigate potential vulnerabilities in image processing libraries, please
refer to the
[Secure image processing configurations](#secure-image-processing-configurations).
By default, all sample upload handlers allow only upload of image files, which
mitigates some attack vectors, but should not be relied on as the only
protection.
Please also have a look at the
[list of fixed vulnerabilities](VULNERABILITIES.md) in jQuery File Upload, which
relates mostly to the sample server-side upload handlers and how they have been
configured.
## Purpose of this project
Please note that this project is not a complete file management product, but
foremost a client-side file upload library for [jQuery](https://jquery.com/).
The server-side sample upload handlers are just examples to demonstrate the
client-side file upload functionality.
To make this very clear, there is **no user authentication** by default:
- **everyone can upload files**
- **everyone can delete uploaded files**
In some cases this can be acceptable, but for most projects you will want to
extend the sample upload handlers to integrate user authentication, or implement
your own.
It is also up to you to configure your Webserver to securely serve the uploaded
files, e.g. using the
[sample server configurations](#secure-file-upload-serving-configurations).
## Mitigations against file upload risks
### Prevent code execution on the server
To prevent execution of scripts or binaries on server-side, the upload directory
must be configured to not execute files in the upload directory (e.g.
`server/php/files` as the default for the PHP upload handler) and only treat
uploaded files as static content.
The recommended way to do this is to configure the upload directory path to
point outside of the web application root.
Then the Webserver can be configured to serve files from the upload directory
with their default static files handler only.
Limiting file uploads to a whitelist of safe file types (e.g. image files) also
mitigates this issue, but should not be the only protection.
### Prevent code execution in the browser
To prevent execution of scripts on client-side, the following headers must be
sent when delivering generic uploaded files to the client:
```
Content-Type: application/octet-stream
X-Content-Type-Options: nosniff
```
The `Content-Type: application/octet-stream` header instructs browsers to
display a download dialog instead of parsing it and possibly executing script
content e.g. in HTML files.
The `X-Content-Type-Options: nosniff` header prevents browsers to try to detect
the file mime type despite the given content-type header.
For known safe files, the content-type header can be adjusted using a
**whitelist**, e.g. sending `Content-Type: image/png` for PNG files.
### Prevent distribution of malware
To prevent attackers from uploading and distributing malware (e.g. computer
viruses), it is recommended to limit file uploads only to a whitelist of safe
file types.
Please note that the detection of file types in the sample file upload handlers
is based on the file extension and not the actual file content. This makes it
still possible for attackers to upload malware by giving their files an image
file extension, but should prevent automatic execution on client computers when
opening those files.
It does not protect at all from exploiting vulnerabilities in image display
programs, nor from users renaming file extensions to inadvertently execute the
contained malicious code.
## Secure file upload serving configurations
The following configurations serve uploaded files as static files with the
proper headers as
[mitigation against file upload risks](#mitigations-against-file-upload-risks).
Please do not simply copy&paste these configurations, but make sure you
understand what they are doing and that you have implemented them correctly.
> Always test your own setup and make sure that it is secure!
e.g. try uploading PHP scripts (as "example.php", "example.php.png" and
"example.png") to see if they get executed by your Webserver.
### Apache config
Add the following directive to the Apache config, replacing the directory path
with the absolute path to the upload directory:
```ApacheConf
# To enable the Headers module, execute the following command and reload Apache:
# sudo a2enmod headers
# The following directives prevent the execution of script files
# in the context of the website.
# They also force the content-type application/octet-stream and
# force browsers to display a download dialog for non-image files.
SetHandler default-handler
ForceType application/octet-stream
Header set Content-Disposition attachment
# The following unsets the forced type and Content-Disposition headers
# for known image files:
ForceType none
Header unset Content-Disposition
# The following directive prevents browsers from MIME-sniffing the content-type.
# This is an important complement to the ForceType directive above:
Header set X-Content-Type-Options nosniff
```
### NGINX config
Add the following directive to the NGINX config, replacing the directory path
with the absolute path to the upload directory:
```Nginx
location ^~ /path/to/project/server/php/files {
root html;
default_type application/octet-stream;
types {
image/gif gif;
image/jpeg jpg;
image/png png;
}
add_header X-Content-Type-Options 'nosniff';
if ($request_filename ~ /(((?!\.(jpg)|(png)|(gif)$)[^/])+$)) {
add_header Content-Disposition 'attachment; filename="$1"';
# Add X-Content-Type-Options again, as using add_header in a new context
# dismisses all previous add_header calls:
add_header X-Content-Type-Options 'nosniff';
}
}
```
## Secure image processing configurations
The following configuration mitigates
[potential image processing vulnerabilities with ImageMagick](VULNERABILITIES.md#potential-vulnerabilities-with-php-imagemagick)
by limiting the attack vectors to a small subset of image types
(`GIF/JPEG/PNG`).
Please also consider using alternative, safer image processing libraries like
[libvips](https://github.com/libvips/libvips) or
[imageflow](https://github.com/imazen/imageflow).
## ImageMagick config
It is recommended to disable all non-required ImageMagick coders via
[policy.xml](https://wiki.debian.org/imagemagick/security).
To do so, locate the ImageMagick `policy.xml` configuration file and add the
following policies:
```xml
```
PK :PPqTm m wdio/.eslintrc.jsnu ٘ 'use strict'
module.exports = {
env: {
node: true
},
parserOptions: {
ecmaVersion: 2019
}
}
PK :PP/0 wdio/reports/.gitignorenu ٘ *
!/.gitignore
PK :PPP wdio/hooks/index.jsnu ٘ 'use strict'
/* global browser, Promise */
const cmds = require('wdio-screen-commands')
/* eslint-disable jsdoc/valid-types */
/** @type WebdriverIO.HookFunctions */
const config = {
before: async () => {
browser.addCommand('saveScreenshotByName', cmds.saveScreenshotByName)
browser.addCommand('saveAndDiffScreenshot', cmds.saveAndDiffScreenshot)
if (browser.config.maximizeWindow) await browser.maximizeWindow()
},
beforeTest: async test => {
await cmds.startScreenRecording(test)
},
afterTest: async (test, context, result) => {
await Promise.all([
cmds.stopScreenRecording(test, result),
cmds.saveScreenshotByTest(test, result)
])
}
}
module.exports = config
PK :PP ! wdio/assets/black+white-60x40.gifnu ٘ GIF89a<