Web Application File Upload Vulnerabilities.pdf

(13267 KB) Pobierz
Interested in learning
more about security?
SANS Institute
InfoSec Reading Room
This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express written permission.
Web Application File Upload Vulnerabilities
Uploading files to a web application can be a key feature to many web applications. Without it cloud backup
services, photograph sharing and other functions would not be possible.
Copyright SANS Institute
Author Retains Full Rights
AD
Web Application File Upload
Vulnerabilities
GIAC (GWAPT) Gold Certification
Author: Matt Koch, Matt@AltitudeInfoSec.com
Advisor: Rob Vandenbrink
Accepted: 12/06/2015
Abstract
File upload vulnerabilities are a devastating category of web application vulnerabilities.
Without secure coding and configuration an attacker can quickly compromise an affected
system. This paper will discuss types of file upload vulnerabilities, how to discover,
exploit, and maintain persistence using upload vulnerabilities.
Matthew!Koch!
Web Application File Upload Vulnerabilities! 2
!
1. Introduction
Uploading files to a web application can be a key feature to many web applications.
Without it cloud backup services, photograph sharing and other functions would not be
possible. File upload functionality introduces a substantial risk to the web application
(Barnett, 2013) and requires unexpected additional validation and system configuration to
protect the web application.
In!the!WPScan!WordPress!Vulnerability!Database!alone!
there!are!approximately!240!file!upload!related!vulnerabilities!(The!WPScan!Team,!
2015).!Additionally!the!National!Vulnerability!Database!contains!approximately!541!
unique!CVE!entries!(Common!Vulnerabilities!and!Exposures)!for!file!upload!related!
vulnerabilities!(National!Institute!of!Standards!and!Technology,!2015).!!
1.1.
How HTTP File Upload Works
File!upload!capabilities!via!the!HTTP!protocol!are!primarily!defined!within!
several!Requests!for!Comment!(RFC)!by!the!Internet!Engineering!Task!Force!(IETF).!!
“Request!for!Comment”!or!RFC’s!are!general!guidelines!for!how!software!will!
function.!!There!are!several!methods!for!uploading!a!file!using!a!web!application.!
The!most!applicable!RFC’s!are!1867,!2388!and!7578.!In!order!to!upload!a!file,!the!
web!application!must!present!a!<form>!HTML!tag!including!a!“method”,!“action”!and!
“enctype”!(Nebel!&!Masinter,!1995).!A!simple!example!might!be:!!
!<form!method="post"!enctype="multipart/form7data"!><input!type=”file”!
name=”exampleupload”/>!</form>!
The form’s HTTP method would typically be a “POST” or “PUT” to submit data
to the web server. The most common encoding types are “text/plain”, “application/x-
www-form-urlencoded” “application/octet-stream”, “multi-part/mixed” and “multi-
part/form-data”. The encoding or Content-Type HTTP headers are MIME (Multi-Purpose
Internet Mail Extensions) media types. For example:
<form id="example"
enctype="multipart/form-data"
action=""
method="POST">
Matthew!Koch!
Web Application File Upload Vulnerabilities! 3
!
Figure 1: A Multipart/form-data request to upload a file named “Mountains.jpg” Shown via PortSwigger’s
BurpSuite
To summarize the relevant file upload RFC’s: All validation is the responsibility
of the application receiving the request. It may be the web server, run time interpreter or
web application itself responsible for the validation. For an application developer, this
additional application-side validation may be easily overlooked leaving the web
application vulnerable to attack.
1.2.
File Upload Vulnerability Taxonomy
Several distinct types of web application file upload vulnerabilities exist. The
Common Weakness Enumeration (CWE), offers an industry standard list of unique types
of software weaknesses (Mitre, 2015).
Matthew!Koch!
Web Application File Upload Vulnerabilities! 4
!
1.2.1. “Unrestricted file Upload with Dangerous type”
CWE-434 describes: “Unrestricted Upload of File with Dangerous Type” a
system with this weakness may authenticate the upload function but fail to verify or
restrict the file to the type intended by the software developer. For example uploading a
malware executable instead of a picture file to a photograph sharing website. Per RFC
7578, the receiving application should not rely on the Content-Type HTTP header
(MITRE, 2015). This requires the application developer to perform additional file type
checking after the file has been uploaded. As shown in
Figure!2
and
Figure!3
many
applications rely on the Content-Type header or the file extension allowing for dangerous
files to be uploaded. In this example by simply by changing the file extension from
evil.exe to evil.jpg allows the dangerous file to be uploaded.
!
Figure 2: WordPress rejecting “evil.exe” based on file extension containing “exe”
Matthew!Koch!

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin