Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have some good knowledge how sql injections work. I see that the Googling inurl upload.php will tell one about the upload paths in a website. My Question is that if a person finds a path by which he can upload images only, can he still perfrom sql injections? Please guide.

share|improve this question
    
All that tells you is that the server is running php, and that there is a script that accepts file uploads of some kind. The presence of an SQL daemon isn't suggested. –  lynks Jan 14 '13 at 18:34

5 Answers 5

Image Uploads aren't directly vulnerable to SQL injection, as long as you're verifying that the image is actually an image. By this, I mean not simply relying on the file name. It could be possible for someone to upload an "image" that isn't an image at all and contains SQL injection scripts. If the image contains SQL commands, then am image upload can put you at risk of SQL injection indirectly.

There are a whole host of other potential issues related to image uploads, including preventing users from uploading infected images (several image types can be infected with malware) and, if the website isn't crafted right, they may be able to use image gleaned from uploading images to figure out how to do a Directory Traversal attack. But these are very different from SQL Injection.

See: (Related attacks)

and finally, the one below mentions steps to ensure the item being uploaded is actually an image.

share|improve this answer
    
Try uploading a malicious.php.jpg or malicious.jpg.php - most filters just check the final extension/presence of .jpg, and many common apache configurations will still pass both files to the php engine when they are requested. –  lynks Jan 14 '13 at 18:35
    
@lynks - good point. I actually knew that, but spaced it. Thanks for keeping me honest. I edited the answer. –  David Stratton Jan 14 '13 at 18:37
    
The SO link is for PHP only. In .NET I do something similar using the System.Graphics library, and I'm sure other platforms have similar defenses. –  David Stratton Jan 14 '13 at 18:39

The image file by itself will not do SQL injection, but the image file does not come alone; it includes a file name. SQL injections are about server code carelessly including character strings within a request to a SQL database, where the included string comes from the potentially hostile remote user. The file name is a string which has been chosen by the remote user. Therefore...

share|improve this answer

Actually they can be malicious. One of the challenges of the CTF of 29C3 was actually to upload an image and perform SQLi with it.

How did it work? Well images have metadata, after you uploaded the image, the metadata was extracted and put into the database. So the trick to get the flag was to include SQL in the metadata. (the input was not correctly sanitized).

share|improve this answer

Yes and no.

Images are just data, and as such, they are no different from form fields, GET parameters, or any other kind of user-supplied data. There really isn't anything special about them, except that most other data you'll receive is textual, and that they typically don't contain anything that "could possibly resemble SQL". The latter is a false assumption though, since most image file formats cater for metadata, which makes it extremely easy to embed SQL in them, and even if they don't, crafting an image file that contains SQL as part of the binary data stream shouldn't be too hard.

Long story short: if you have your query parametrization in order (which you should anyway), then you have exactly as much to fear as with any other user-supplied data: as long as you pass the image blob as a parameter, and the database API's parametrization calls aren't vulnerable, you're good. If, however, you decide to concatenate things into your query that have been extracted from an uploaded file, you have a problem of exactly the same kind as if you had an SQLi vulnerability through a form field.

Another thing you need to look out for with file uploads is remote code execution. If you don't watch out, an attacker can upload a PHP file, disguised as an image, and trick your script into saving it in a location where it can be reached and executed through apache (or, worse, in a location where it gets picked up by a system-local process, in the worst case, one that runs as root). The defense here is to verify and whitelist a file's MIME type, make sure its extension matches the MIME type, sanitize (or just completely replace) the filename, and store it somewhere outside the docroot.

share|improve this answer

"Another thing you need to look out for with file uploads is remote code execution. If you don't watch out, an attacker can upload a PHP file, disguised as an image, and trick your script into saving it in a location where it can be reached and executed through apache"

Yep, this is very common. Many shell "providers" will actually advise it as a preferred/default upload method in the shell description.

Changing the file name is you best bet here (+1) and some content/file managers will do it out-of-the-box (i.e. K2 for Jommla).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.