i've been Googling on how to get the ContentType of a file to be uploaded but to no avail. I need to get this done using Classic ASP. What i always see from Google is
response.ContentType = something
My main objective is to validate an image before uploading it. Only valid images are .jpg, .gif and .png. Thus, the valid ContentTypes are "image/jpeg", "image/gif" and "image/png".
I do not want to just rely in the file extension as a hacker can simply change the extension say .exe to .jpg.
Please help, thank you!
ADDED:
I am simply using this html control:
<input type="file" name="inputfile" />
Browsers may upload a filetype in the Content-Type header of the multipart/form-data subpart for the field.
Classic ASP does not natively support file uploads - what are you using to receive them? There are many libraries/controls that implement this and any mechanism to retrieve that subpart header will be dependent on what that code is.
Howewver, the point is largely moot because:
(a) the file upload Content-Type header is massively unreliable. Browsers can and will send wrong values at a whim, and there's typically little a user can do to correct the issue. (For example on Windows the applications that are installed can easily hijack MIME type associations away from the defaults, and even on a clean install IE will typically send the wrong type for JPEGs.)
(b) an attacker can spoof a Content-Type just as easily as they can spoof a file extension.
There is rarely a good reason to pay attention to the submitted Content-Type. At best you can use it as a convenience default value for something the user can manually override.
What is your purpose in checking the type of a file?
if you are trying to prevent injection onto the filesystem of directly executable files (eg xxx.asp), the right thing to check is the file extension, and generally place very strong restrictions on what can be in the filename at all (because typically servers decide what files to execute server-side based on name and location). This is actually quite hard to get 100% right, so it is generally best not to use user input as a basis for local filenames at all (instead use a generated filename like 123.jpeg for an object stored in the database as primary key 123).
if you are trying to prevent uploading broken images or unsupported image formats, you should check the content of the file to see if it's a valid image, using an image loading library.
if you are trying to prevent people uploading HTML or plugin content to do cross-site-scripting attacks, there is very little you can do about that by checking the file, its name, or its conetnt. It's possible to create ‘chameleon’ files are valid images whilst at the same time also containing content that a browser might interpret as script under some circumstances. If you have to allow general file uploads from untrusted users then the best thing to do is serve them off a different domain, so that cross-site-scripting into it doesn't give up anything valuable.
Related
Need to test file upload feature for security. Purpose is to avoid/stop any type of malicious files from being uploaded.
Thanks !!
There are multiple vulnerabilities that usually come up around file uploads/downloads.
Malware in uploaded files
Any uploaded file should be virus-checked. As #CandiedOrange responded, you can use the EICAR test for that purpose.
Path injection
The filename for an uploaded file is te same type of user input as any other field in the request, an attacker can freely choose the filename. As a tester, you can send something like "../filename" to try and save it to unintended locations or to overwrite other files.
Filetypes
If the filetype restriction is only on the client, that's obviously useless for security. But even if the file extension is restricted on the server side, say only .pdf is allowed, you can still try to upload something.pdf.php or something.pdf.exe or similar to get around the filter. It's best if the application uses some real content discovery to find out if the uploaded file is actually an allowed filetype.
Content sniffing
Some browsers have this awesome (not) feature that when a file is downloaded, the browser looks into its content and displays it according to the content, regardless of the content type header received from the server. This means even if uploads are restricted to say .pdf, an attacker might upload an html file with javascript, in a file named "something.pdf" and when somebody else downloads that file, the browser may run the javascript, thus making the application vulnerable to XSS. To prevent this, the application should send the X-Content-Type-Options: nosniff response header.
Uploaded file size
If an attacker can upload too many or too big files, he may be able to achieve denial of service by filling up the space on the server.
Download without restriction (direct object reference)
An application might save uploaded files to a location directly accessible to the webserver. In such a case, download links would look similar to /uploads/file.pdf. This is only suitable for public files, access control cannot be enforced that way, anybody that has the link can download the file.
Lack of access control
If files are not available to all logged on users, the application must perform authorization to decide whether the user that's logged in can actually download the file he is requesting. Too many times this authorization step is missing or flawed, resulting in the application being able to serve the wrong files to users cleverly modifying requests.
So the bottom line is, file upload/download vulnerabilities are much more than just virus checking uploaded files.
If you're security is signature based consider uploading an EICAR test file. It should trigger your protection and if it doesn't, and is somehow executed, all it will do is print "EICAR-STANDARD-ANTIVIRUS-TEST-FILE!" and stop.
Well you can activate malware protection on your network firewall. Snort is good option for protecting websites.
You can also add input filters to your application code so it checks if the uploaded file has malware
We are considering using ImageResizer in our commercial application and have some questions related to security. The application will allow user upload of images for subsequent display on web pages.
We want to know how we can use ImageResizer to protect against attacks such as compression bomb, JAR content, payload, exif exposures, and malformed image data.
I think I know how to address these in general, but I'd like to know what specific tools ImageResizer offers.
Most ImageResizer data adapters offer an "untrustedData=true" configuration setting.
This setting in turn sets &process=always in the request querystring during the ImageResizer.Configuration.Config.Current.Pipeline.PostRewrite event.
If you wish, you can set it for all image requests. Keep in mind, this will cause requests for original images to be re-encoded at a potential quality loss and/or size increase.
When process=always is set, all images are re-encoded and stripped of exif data to prevent potentially malicious images from reaching the browser. This means the client will get a 500 error instead of a malformed image.
How an image is interpreted, however, is just as important. If you permit user uploads to preserve their original file name or just extension (instead of picking from a whitelist), you open yourself to easy attack vectors. In the same way, if an image is set to the browser with a javascript mime-type, the client may interpret it as javascript and get XSS'd. ImageResizer's pipeline works with whitelists to prevent this from happening.
Also, if you intend to re-encode all uploads, it may be easier to do it during the upload stage instead of on every request. However, this relies on the security of your data store and being sure that no 'as-is' uploads can succeed.
A user recently reported to me that they could exploit the BBCode tag [img] that was available to them through the forums.
[img=http://url.to.external.file.ext][img]
Of course, it would show up as a broken image, however the browser would retrieve the file over there. I tested it myself and sure enough it was legit.
I'm not sure how to prevent this type of XSS injection other than downloading the image and checking if it is a legitimate image through PHP. This easily could be abused with a insanely huge file.
Are there any other solutions to this?
You could request the headers and check if the file is actually an image.
Edit:
Sorry that I couldn't answer in more depth; I was enjoying dinner.
There are two ways I see it:
You check to see if the supplied address is actually a image when the post is submitted or viewed, you could accomplish this by checking the headers (making sure it's actually an image) or by using file extension. This isn't fool-proof and has some obvious issues (changing the image on the fly, etc.).
Secure your site that even if there is a compromise with the [img] tag there is no real problem, for example: the malicious code can't use stolen cookies.
Use a script that requests an external image and modifies the headers.
A basic way to check the remote files content type:
$Headers = get_headers('http://url.to.external.file.ext');
if($Headers[8] == 'text/html') {
echo 'Wrong content type.';
exit;
}
There's only two solutions to this problem. Either download the image and serve from your webserver, or only allow a white-list of url patterns for the images.
Some gotchas if you decide to download the images -
Make sure you have a validation for the maximum file size. There are ways to stop the download if the file exceeds a certain size, but these are language specific.
Check that the file is actually an image.
If you store it on the hard-disk, be sure to rename it. You shouldn't allow the user to control the file name on the system.
When you serve the images, use a throw-away domain, or use naked ip address to serve the images. If the browser is ever tricked in thinking the image is executable code, the same-origin policy will prevent further damage.
We're providing a web form whereby users fill in their personal information; some of it is sensitive information (SSN, Birthday, etc). Upon user submission, the data is prefilled into a PDF which is then made available via a link.
We are creating the PDF in a folder that has write access on the website.
How can we safely create and add PDFs in this folder, with whatever naming scheme (use a GUID?), such that another user cannot guess/spoof the PDF file location, type this in the URL and access another person's PDF?
Maybe the PDF folder has rights only specific to the user, but that may be a different question on how that is accomplished. (The number of users is unknown, as this will be open to public).
Any thoughts on this? In a nut shell, we need to allow the user to view a PDF of the data they just entered while preventing more-savvy users to figure out the location of PDF files, allowing access to other files.
Thanks!
trying to obfuscate the path to a file isn't really making it secure. I would find a way to email or another way to fetch it for the user instead of allowing access to an open directory.
Make the web app fetch the file for the user instead of relying on web server open folder permissions.
just keep in mind obfuscation isn't really security.
If it's really just for the moment, create a completely random file (20384058532045850.pdf) in a temporary directory, serve that to the user immediately and remove it after a certain period of time.
Whether your web app has write rights on that directory or not (I assume you are talking about chmod user rights) is not important, it can't be breached trough the web server and I don't see a problem in revealing the directory path per se - you have to reveal something in giving the user a URL to download. If your PDF names are random enough, there is practically no risk of somebody being able to guess the name of another PDF file in the same directory.
As the PDF contains sensitive data: Don't forget to turn off caching to prevent a local copy of the PDF being saved on the client's browser cache.
I don't know for sure whether turning off caching through the appropriate headers is enough to prevent local caching in all browsers. You might have to look into that.
For the purpose of pdf's, would it not be better (I know I will get flamed for this) to store the actual pdf into the database as a BLOB, which would be on the back-end of the website in question?
There will be no reference to the URL anywhere nor will there be a specific path highlighted in any links on that form.
Hope this helps,
Best regards,
Tom.
The simplest way is to proxy the file through your application (fpassthru() in php for example), this allows you to use what ever access control/identification system you already use for the dynamic content.
If you don't have any means of identifying your users and restricting access, and assuming your platform has a secure session mechanism, you can protect the file by storing the filename in the user's session and then returning that file (and only that file) to the user when requested. This should mean that an attacker would have to spoof a session to access the file so this should be as secure as your session mechanism is.
I have a rich-text editor on my site that I'm trying to protect against XSS attacks. I think I have pretty much everything handled, but I'm still unsure about what to do with images. Right now I'm using the following regex to validate image URLs, which I'm assuming will block inline javascript XSS attacks:
"https?://[-A-Za-z0-9+&##/%?=~_|!:,.;]+"
What I'm not sure of is how open this leaves me to XSS attacks from the remote image. Is linking to an external image a serious security threat?
The only thing I can think of is that the URL entered references a resource that returns "text/javascript" as its MIME type instead of some sort of image, and that javascript is then executed.
Is that possible? Is there any other security threat I should consider?
Another thing to worry about is that you can easily embed PHP code inside an image and upload that most of the time. The only thing an attack would then have to be able to do is find a way to include the image. (Only the PHP code will get executed, the rest is just echoed). Check the MIME-type won't help you with this because the attacker can easily just upload an image with the correct first few bytes, followed by arbitrary PHP code. (The same is somewhat true for HTML and Javascript code).
If the end-viewer is in a password protected area and your app contains Urls that initiate actions based on GET requests, you can make a request on the user's behalf.
Examples:
src="http://yoursite.com/deleteuser.xxx?userid=1234"
src="http://yoursite.com/user/delete/1234"
src="http://yoursite.com/dosomethingdangerous"
In that case, look at the context around it: do users only supply a URL? In that case it's fine to just validate the URLs semantics and MIME-type. If the user also gets to input tags of some sort you'll have to make sure that they are not manipulatable to do anything other then display images.