I have form for file uploading in my website that i check mime-type of uploaded file to allow or refuse uploading it. It worked well until I've upgraded my firefox to 3.6.11 (in ubuntu). But now uploading Doc files is not possible. I checked the mime-type of file but it was 'application/x-php' instead of 'application/vnd.ms-word' or other msword mime-types.
I use
echo $_FILES[$fileName]['type'];
to see the mime-type. I upload the same file from firefox 8 and firefox 3.6 and the output of above code was:
FireFox 8: application/vnd.ms-word
FireFox 3.6: application/x-php
Is it a bug of firefox or I have to change my codes?
I use PHP.
$_FILES[...]['type'] is just arbitrary, user supplied, best-guess, unreliable (as you see) information supplied by the client which may or may not have anything to do with the actual file. Never use it.
Try to detect the MIME type yourself on the server. For example techniques, see How to get the content-type of a file in PHP?.
Related
I'm building a web app with PHP that uses Excel Writer (XML) for PHP to create an Excel file that the user can download. I've taken a look at the source code for the library, and all it does is echo the generated XML to standard output. Although the file being generated is an XML file, I specifically give it a name with a ".xls" extension so that after it's been downloaded the end-user can double-click it and it will launch Excel on their system and open the file successfully.
This works correctly when downloading the file with Firefox, Chrome and IE, but not with Safari. For example, if I set the name of the file to be 'File.xls', this is the name of the file that gets downloaded. But with Safari the name of the file ends up being 'File.xls.xml'.
The server is running Apache on Mac OS X. I thought that might matter as I'm guessing that the problem has to do with MIME types on the server, but I'm not at all sure. Perhaps I can do something with the link that appears on the page, or perhaps I need to edit a configuration file for Apache? Any help is appreciated.
You might be right, it could just be the MIME type that needs setting.
Try putting
header("Content-Type: application/vnd.ms-excel");
before the output code, that should force the browser to see the data as an Excel file.
If the code is setting Content-Type already and it's conflicting, then search the script for "Content-Type" and try changing it.
Also, if it's an XLSX file, then there's a different MIME type - application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
In my site, I give an option to upload images with .jpg and .JPG extension. They both work and I can see both on the server itself.
When I try to see in the browser the photos with the .jpg extension by calling them name.jpg, they work. When I call to the othername.JPG (which is called that way on the server) it does not work and does not show it. othername.jpg does not work too.
I suppose your web server is not configured to send the Content-Type: image/jpeg HTTP header for such files. It's possible that some browsers refuse to display them as pictures if the MIME type does not match. If you happen to be using Apache, you can fix it yourself in an .htaccess file:
AddType image/jpeg .JPG
You should also consider that you cannot count of URLs being case-insensitive: FOO can equal foo... or not. Use always the exact case and save yourself future problems.
Edit:
Before misconfiguring random stuff, you can follow this checklist and see what fails exactly:
Is the URL valid? Foo.jpg is not the same as foo.jpg.
Does the browser receive the file? Firebug should tell you.
What's the HTTP response code? Firebug should tell you.
What's the Content-Type header? Firebug should tell you.
Common status codes:
404: the file could not be found. Most likely, your URL is wrong.
403: you are not authorised to see the file. It can be a permissions issue.
500: generic server error code. You should open your hosting service control panel and have a look at the error log.
Your using linux/apache right? make the filenames lowercase. its the default for them to be accessed on linux.
try to check the contents of that file, maybe your script is messing up JPG uploaded files.
if that doesn't work maybe it's from your system .. an .htaccess
Look in error logs for anything that is related to this file.
My ad server has been hacked over the weekend.
It seems to be a widespread problem, according to this article.
There is something in there that got me thinking...
Attackers used one attack to get login
rights to his server, and then
uploaded a maliciously encoded image
that contained a PHP script hidden
inside it, he said. By viewing the
image, attackers forced the script to
execute on the server
How is this possible? Does it rely on the image being opened with GD or similar? Do they upload a script posing as an image, and somehow include it?
It can be as simple as uploading a file like
GIF89a<?php
echo 'hi';
If your upload script tests the content type via fileinfo or mime_content_type() it is recognized as "GIF image data, version 89a" since GIF89a is the only pattern/magic number that is required to identify a file as gif.
And the OpenX upload script apparently kept the proposed filename, i.e. it was possible to save this "image" as foo.php on the server. Now, if you requested that file via http://hostname/uploaddir/foo.php the script was executed as a php script because webservers usually/often determine the content type only by the filename extension, e.g. via
<FilesMatch "\.php$">
SetHandler application/x-httpd-php
</FilesMatch>
php then echoes the leading GIF89a and executes the <?php ...code... block.
Putting the <?php block into a gif comment is slightly more sophisticated but basically the same thing.
Your server is parsing that file for w/e reason. The attackers are putting the PHP into the image comment.
How are you validating the file is an image? If you do it solely on mime type, then I believe they can fake the image header and include whatever they want after that. VolkerK has a practical example
In the perfect world, I wouldn't serve any public facing images via PHP for fear of such an issue.
Serve the image directly using the server; A good suggestion is to save those images to a directory where they can be served without PHP.
I think that's the gist of it, someone correct me if I'm wrong.
The only possibility I see for a server compromise is the image being included instead of read through e.g. readfile and other stream functions.
I'm seeing some strange behavior from some dynamically generated PDFs using the TCPDF library in PHP.
Standard lamp stack-- however, if you try to open the PDF from Windows with Acrobat Reader, it gives an error that the "file is damaged and could not be repaired". From Mac, Linux, etc. the file works fine, and opens fine. It also opens fine in Google Docs-- so clearly the PDF itself is ok.
Is it possible that the mime type (application/pdf) is causing problems in Windows?
Thanks
What browser on Windows? All? Or just one? My initial gut instict, is that the Windows browser is ignoring the encoding IF the content is being gzipped (Ignoring the Content-Encoding header). That's if you're even sending that header.
Open the file you downloaded in some text editor (Notepad, etc). The first few characters of the file should be %PDF-1. with another number after it. If it's not at the beginning, check to see if the file is gzipped (rename the file to blah.gz, and then run it through gzip to try to decode it). If that worked, then your problem is the browser ignoring the encoding.
IF it is ignoring the encoding, you need to not gzip the output of that PHP file. How you do that will depend on your server configuration.
Oh, and the application/pdf is the proper mime type. And the mime type is not your problem, since Acrobat is at least trying to open the file...
I am using php's imagejpeg to save a GD image resource to a file, doing this:
imagejpeg($im, '../images/' . $image_id . '.jpg');
It works fine, but according to my browser, it tries to read the file as text/plain:
Resource interpreted as image but transferred with MIME type text/plain.
Is there a step before saving the file that I am supposed to do to make sure it's using the right mine-type?
I am using windows (XAMPP), could it be a Windows issue?
EDIT: nope. I just tested in a linux server.
As far as the actual displaying, it's just plain html .
My upload code is supposed to saves= the file as a plain jpeg in the server. It's just not saving it with the right mime type.
Thanks
AFAIK, the Apache server - in standard out of the box configuration - should sent content-type headers purely based upon file extension. Apache shouldn't even even be looking at the contents or how it was originally generated/stored.
On my out-of-the-box Apache2, the file conf/mime.types contains the line:
image/jpeg jpeg jpg jpe
which ought to do it, right?
Can you post a test-case, say, a simple html page with two img tags: one for your generated image, and one for a standard image that seems to work fine?
One last thought: Does it occur in all browsers? Maybe it's a browser issue, not a server one?
It sounds like you're dumping the contents of the file to the browser and not actually telling the browser what type of file it is. Try adding a Content-type header before you output your image to the browser:
header('Content-type: image/jpeg');
Are you sure you aren't using the wrong file-extension name?
Otherwise, just put an normal image in the server and make sure the mime-types are properly configured.
It could also be that your image data from the manipulation is corrupted.