Forums
Thread
Oct 25, 2018
Can users send 'malicious images' to your website this way?
Hello hashnoders :)
I recently asked a question about website security. To quote a part of the answer by JasonKnight:
their uploads of client records and information were not verified to actually be valid image file formats
While I was working on a project, I decided to use a third-party media storage service like Cloudinary. After a user submits the form with all of the relative info and images, the (image) input value looks like this (see red circle in console):
The question now arises, would I still need to confirm that the url is in fact an image when I request the url from Cloudinary and spit it out on my webpage? (That is, even if services like Cloudinary already do some validation on their servers)
If yes, can you explain how a person could fake an image and send some malicious PHP code to Cloudinary instead?
P.S. I'm using the console for testing purposes only. The data and image urls will actually go to a MySQL DB.
Responses(2)
As a third party storage service, that's not hosted on the same server as your PHP or other SSI code, right? If so you're not at risk.
the problem in said client's case was they were storing the images in question in /images/avatars in the same filesystem tree / uri. As such the people injecting the code simply made it so that they could trick it into storing the users's template as:
"/images/avatars/userAvatarRandomHashHere.jpg?" making any further string addition pointless. So when the system did:
include('templates/' . $user['templateName'] . '/common.template.php');
It actually included the jpeg instead of the correct php file.
Mind you I'm paraphrasing here, it was a bit more complicated than that as I forget how they actually made the rest of the URI be ignored. It was more complex than I made it sound, but that's the gist of said attack vector. If you store user uploads in the same directory tree with the same access levels as the PHP running your logic, a minor elevation or hack could use those files to arbitrarily run code.
Same type of attack nabbed the SMF forum software some decade or so ago.
But since you can't include() code from off server, hosting your images on a third party service would in fact be more secure -- at least in terms of this type of attack vector.
It's why I've taken lately to on systems where it really matters setting up a second domain to handle static files separate from the normal security and operational logic. Since you can't include() across domains, it breaks that link. DOES get a bit complicated though and overhead heavy when you want to allow user uploads, but in modern browsers a hint of JavaScript helps alleviate that burden. I just do so in a manner that gracefully degrades scripting off -- sucking down the excess overhead in said cases.
j
stuff ;)
yes you can just set the right CSP headers + the right MIME headers and those images won't get executed. So the XSS part is at least covered.
In general to proxy images through a virus scanner makes sense.
Also you probably can't protect yourself against certain malicious images github.com/fuzzdb-project/fuzzdb/tree/master/atta…
you can add a virus scanner (clamAV) on the server to prevent certain viruses. we did this for one of our customers.
those are my initial thoughts :)