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.
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
I need to protect my videos to be downlouded using "Internet Download Manager - IDM/IDMan"
i used
1. rtmp stream
2. signed URL
3. expiration date of signed URL (60seconds)
4. i set player(jwplayer)to *autostar*
AND i need to set signed url outdated if it used one time
using this solution IDM will get an url that is already used then blocked
Is there any way to configure cloudfront to use signed url just one time;
Or any solution that can protect videos to be uploaded and used in other web sites.
Please can you help?
Thanks in advance
Cloudfront does not support the ability to only play a url once and they never will. The reason is that the only way to do this will be for all their edge servers to share the information - they currently do not share state which means scaling is much easier and performance is much better.
Unfortunately, if you're looking for fine grained control over how your videos are played, you're going to need more fine grained code, which you can't do in cloudfront - you'll need to host content directly on your server.
Idea 1: Limit by count
You can implement the idea that you have - once the url has been used once, you no longer serve up that file.
Idea 2: Limit by referrer
You can look at the referrer header and if it's from your website, then allow the content to be downloaded. Otherwise, reject it. Note: this can be spoofed and a user can set the referrer header manually.
Preventing a video from being downloaded and later uploaded is technically impossible. By letting them display the video, there really isn't any way to do that without them being able to record those bits and replay them later. There are probably things, like preventing right clicks or using an odd proprietary format or something else but I'm not familiar with DRM techniques.
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.
I've got an image generation servlet that generates an image text from a querystring and I use like this:
<img src="myimage.jpg.jsp?text=hello%20world">
These below are my security measures:
Urlencoding of querystring parameter
Domain whitelist
Querystring parameter length check
My questions:
Any security measure I'm forgetting there?
How does the above increase DOS attack risks compared to a standard:
<img src="myimage.jpg">
Thanks for helping.
Things to check would be,
Use HTTP Referer header to verify that requests are originated from your pages. This is only relevant if you are only going to use these images on pages of your site. You can verify that these images are loaded from your page and are not being directly included in page on some other site or the image URL is not directly accessed. This can easily be forged for performing a DOS attack though.
Check the underlying library you are using to generate the images. What parameters you are passing it for generating the image and check which parameters can potentially be controlled by user which can affect the size of image or processing time for the image. I am not sure how the font, font size are provided to the image, if they are hardcoded, or if they are derived through the information from the user.
Since this URL pattern generates an image, I am assuming every call is CPU intensive as well as includes some data transfer for the actual image. You may want to control the rate at which these URLs are fired, if you are really worried about DOS.
As I already mentioned in my comment, the URL can only be 1024 characters long, so there is inherent limit on number of characters that the text field can have. You can enforce a even smaller limit by providing an additional check.
For DoS prevention rate limit how many requests can be received per IP per X number of seconds.
So to implement this, before doing any processing log the remote IP address of each request and then count the number of previous requests in the last e.g. 30 seconds. If the number from that IP address is greater than say 15 then reject the request with a "HTTP 500.13 Web Server Too Busy".
This is on the assumption that your database logging and lookup are less processor intensive than your image generation code. This will not protect against a large scale DDoS attack but it will reduce the risks considerably.
Domain whitelist
I assume this is on the "referer" header? Yes, this would stop your image from being directly included in other websites but it could be circumvented by proxying the request via the other site's server. The DoS protection above would help alleviate this though.
Querystring parameter length check
Yes that would help reduce the amount of processing that a single image request could do.
My questions:
Any security measure I'm forgetting there?
Probably. As a start I would verify you are not at risk to the OWASP Top 10.
How does the above increase DOS attack risks compared to a standard
A standard image request would simply request the static image off your server and the only real overhead would be IO. Processing though your JSP means that it is possible to overload your server by executing multiple requests at the same time as the CPU is doing a more work.
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.