Regarding the upload exploit
In all honesty I actually managed to miss the whole conversation in this thread due to not scrolling back enough and I only get email notifications by this board for the very first new post, not every subsequent one.
That aside, uploading is always risky and not part of the parser core, but the upload_replay.php script I supply seems to handle filename injection well enough.
Its basic mode of operation when dealing with filenames is:
1. Get all characters following the last "." dot character from the uploaded filename.
2. If those characters equal "w3g" proceed with processing.
3. Create a unique ID for the file such as a timestamp in my case.
4. Prepare new filename which is uniqueID + extension -> 1350859626.w3g
5. Store file in /replays/1350859626.w3g
I don't see how you could wind up with a ".php" string in there, but I might be missing something.
A few bytes on allowing users to upload arbitrary files
1. Your upload folder should not be publicly accessible if at all possible. It should be located outside of your web root or properly chmoded.
2. If however it is, due to shared hosting or limitations of your hosting provider. You should use an .htacess file (or its equivalent for other servers) for the /replays folder which disallows any access.
DENY from all
3. That's the whole reason why there's a download.php
script packaged with this Frontend example. It's an example of safely serving files from your /replays directory without the need to allow actual directory access to your users. The download.php script reads and reouputs the file.
You could always use http://luka.zabkar.net/cdp_latest.zip
. a header check should suffice to check if a change was made?