Jaka,
Sorry for the lack of update. I have been very busy with some crypto-analysis stuff as of late.
There are a whole host of issues related to php file uploads.
From the very basics of checking the file extension and type against the $_FILES["file"]["type"] to validate a legit file ([1] remember the .php file disguised as a .gif file security breach... that was classic!) to making sure your file names are cleaned (all to easy to upload a file with a specific name that can break your php code and allow it to be moved to a root directory when you do move_uploaded_file() (think sql xss only on a php level).
Then there are the issues that present themselves simply because of the way the Dropbox folks designed their system to process files that on any other platform would never work the way they work here. It is no secret that you can upload certain types of files to dropbox and execute them right from the dropbox server. Think of the impact of what I could do if I uploaded a specific type of file that ran on the dropbox server, that when opened would execute itself on the dropbox server and purge every file in your dropbox folder - or worse. Now I have not tested to see what all dropbox does and does not process/run/load on their servers because that would be seen as reverse engineering their software and network - and where I live that is a Federal Crime. However, it stands to reason from what I have read on the forums that other people have reported they have gotten to process/run/load, given the right file, app, or code, it would be way to easy to do.
Now, let me also preface that last security issue with this: I realize that your little php upload script is not to blame for this reason. I could just as easily drop the program/applet/script/whatever into my computers dropbox folder and do the dirty work. That is why I previously recommended that this upload script NEVER been ran in the public environment and why it should ALWAYS be ran behind an .htaccess protected directory where only you and those you can trust have access to it. After all, why should you take the legal rap for something some idiot end-user decides to do maliciously from your website, just because you were not intelligent enough to CYA, eh.
Now, let me also say this... I spent about 45 minutes today thinking about exactly what it would take to gain access to the dropbox network (i.e.: the heart of dl-web) AND your own root network. The way your script presently works (because of the failure of already mentioned security issues your script does not check for) I know for a fact that I can gain root server access to any server this script runs on. (I know because I was able to accomplish it on my OWN server). The second step (which as I already mentioned I would not actually test because I enjoy being on this side of a federal prison) I *think* I was able to theorize. I could not think of any way to get into their root but it would not be all that hard to compromise their dl-web. Of course, what would that really do?? Beats me as there is no way to know 'whats there' without actually trying it. (or finding out from an insider what exists therein).
Now there is pretty much nothing that could be done to the AS3 server that I can think of, in regards to gaining access. I'm sure that IF such was possible, it would already have been done and published somewhere by somebody - and I've heard nothing in the public or underground or inner industry about such a breach of the AS3 service.
Anyway Jaka, as I already mentioned in previous posts...
First you need to address the issue of file validation. Sure the same file could be uploaded via a PC/MAC, but do your job as a responsible php developer and add basic/necessary security were it belongs. PHP already takes enough sh!t because newbie developers fail to take the time to learn php and/or properly secure their code... so the last thing the PHP community needs is a script like this making it into the public in an insecure manner.
Second, address the issue of file type validation and comparisons.
Thirdly, encourage people to place the file behind a protected directory. Fourthly, (and for the love of god, fix this!) TAMPER PROOF your $_POST data! Doing something like $uploader->upload($tmpFile, $_POST['dest']); is just about the newbiest thing you can do! Where is your security checks on $_POST['dest'] (!!) Goodness... not even a striptags!! Not even a stripslashes!!! Come on Jaka... show yourself to be a responsible developer and clean up your posted values! You should NEVER EVER EVER be using a $_POST inside of a function/class! Assign it a value name, clean the value, and THEN assign the value name inside your function/class.
Just think if I used a 'dest' value of something like this BASIC xss method: '/\/www/usr' (that's not a real example... to keep the stupid kiddy scripts away, but basic xss knowledge applies here).
With you using a straight freaking $_POST value inside of the $uploader->upload() I've just compromised your entire damn server!
What you SHOULD be doing is something like this:
$Dest = striptags( stripslashes( preg_replace('/[^a-z0-9]+/i', '', $_POST['dest']) ) );
$uploader->upload($tmpFile, $Dest);
Now that is just a BASIC example of what you need to be doing to secure your script here Jaka! Again it goes back to being a responsible software developer. As the old saying goes "NEVER trust the end user!". The instant you open yourself to allowing uncontrollable values directly into your source-code... that's the instant your script has become compromised.
Anyway, there are about 5-7 other examples of basic php security flaws in your script, most of which I have addressed within this message, some of them I have not.
I really admire what you have done here Jaka, as the script itself works flawlessly!
However, on a security level, it is about as bad as it gets in the php world. :(
It would not take much work to get this secure Jaka. Invest a few hours researching all of the different methods people use to attack servers via php file uploads. Implement them. Then think outside the box and come up with methods that YOU would use to target a server, and implement them into your code. Lastly, hunt down some good XSS methods[2] and see if you can break your script with them (I already tested many popular ones, and they will break things). And please, do not fall into the belief that so many other developers have that Cross-site scripting is only related to SQL... please please please don't! You obviously have a good sense of coding logic - apply that same logic to securing your script and you'll be set to go main-stream!
In closing... please do not take offense with any of this. 15-odd years ago I was a newbie php developer myself and got reamed more times then I could count by people who were now people like I am - a seasoned veteran php developer who has had to learn php the hard way (the way it should be learned). I only mean to educate you and help protect you and help protect those you are trying to help. As I said above, you have a good logic in the way you code, your code flows very well, and you did a great job putting this script together! Couple that with some LASP security knowledge and I expect you are going to become one hell of a good php developer!
Again, sorry it took me so long to get back to you.... we've been running reverse engineering tests on one of our security apps and I am the lucky guy who gets to review them block after block after block after block. (sigh) Considering the encryption is 7168-bit, I have about 1.76 billion more blocks to go through (weeee!)
[1]
http://us3.php.net/manual/en/features.file-upload.php#66377
[2]
http://ha.ckers.org/xss.html