Anyone want to help me pen test my website
I have a file storage website that I created several months ago. I have already pen tested it several times and found no significant security flaws. However, I can't confirm that the site is 100% secure because I am the only one that has pen tested it so far.
So, I'll give you guys permission to pen test it. However… do not delete any of the files off the website. I do have backups, but it's really annoying to restore them.
I would rather not post the URL directly, so here's the TinyURL: http://tinyurl.com/n747fe. If you access the URL directly without the user:pass@site.com you'll see that it is protected with .htaccess, but the TinyURL contains all the information for it.
Alright, tell me if you find any security holes.
Thanks
KvK wrote: You should add to the list of prevented file types. I was personnel able to upload php2 and chtml files. Although you're security is plenty good considering the type of site it is, it doesn't hurt to be on the safe side.
:happy:
Thanks for the advice, but the problem is that it would be very annoying to keep on adding new restricted file extensions. Say if I move to a new host and it supports Python and Perl, then I would have to prevent files with the extensions .py and .pl from being uploaded. Or if the host also supports Ruby, then I would have to restrict those file extensions too.
I do have an alternative solution to my problem though. I'm considering implementing a feature that will automatically encrypt and change the file type of any uploaded file. For example, if a user uploads a file called shell.php:
-
Use is_uploaded_file() to check if the file is really an uploaded file. If it is, then proceed.
-
Use move_uploaded_file() to move the uploaded file to a .htaccess protected directory where users cannot access at all. So shell.php can be executed inside of that directory, but it can't happen because everyone is restricted from accessing anything within that directory.
-
Apply some simple encryption to the file contents (for example: base64_encode(strrev(file_get_contents($file))) but that would be kind of weak)
-
Save the encrypted file contents into a new non-executable file such as a zipped folder.
-
Move the zipped folder into the general directory (which is also .htaccess protected so no one can access it,)
-
When the file is downloaded, I will decrypt the file contents and send it to the output buffer (for example: strrev(base64_decode(readfile($file))) to decode it) and then use HTTP headers to perform a safe download.
Does that seem like a good and secure method?
Ntvu wrote: [quote]KvK wrote: You should add to the list of prevented file types. I was personnel able to upload php2 and chtml files. Although you're security is plenty good considering the type of site it is, it doesn't hurt to be on the safe side.
:happy:
Thanks for the advice, but the problem is that it would be very annoying to keep on adding new restricted file extensions. Say if I move to a new host and it supports Python and Perl, then I would have to prevent files with the extensions .py and .pl from being uploaded. Or if the host also supports Ruby, then I would have to restrict those file extensions too.
I do have an alternative solution to my problem though. I'm considering implementing a feature that will automatically encrypt and change the file type of any uploaded file. For example, if a user uploads a file called shell.php:
-
Use is_uploaded_file() to check if the file is really an uploaded file. If it is, then proceed.
-
Use move_uploaded_file() to move the uploaded file to a .htaccess protected directory where users cannot access at all. So shell.php can be executed inside of that directory, but it can't happen because everyone is restricted from accessing anything within that directory.
-
Apply some simple encryption to the file contents (for example: base64_encode(strrev(file_get_contents($file))) but that would be kind of weak)
-
Save the encrypted file contents into a new non-executable file such as a zipped folder.
-
Move the zipped folder into the general directory (which is also .htaccess protected so no one can access it,)
-
When the file is downloaded, I will decrypt the file contents and send it to the output buffer (for example: strrev(base64_decode(readfile($file))) to decode it) and then use HTTP headers to perform a safe download.
Does that seem like a good and secure method?[/quote]
If I remember there was an method in cpanel to change mimetypes. If you change those to a mime type like octet-stream which should make the system ignore it as executable and make the internet browser download it as if it was a executable file.
Alternative to that method would be using a .htaccess file using
markupAddType application/octet-stream TYPEHERE
Which should at least force the browser to ignore it(not sure about server for .htaccess method).
Not sure how well the method will work, and you could not use it on a php file. However, it is worth a shot so that you do not need to block so many file types.
(The method above is a method often used to mask php with a different file extension)
^ I use URL rewrites to mask the presence of PHP. Unfortunately I can't turn expose_php off so if you use the Tamper Data tool on Firefox you can see the X-Powered-By header which basically gives away that I'm using PHP. But that's a very trivial issue and shouldn't be a potential problem to worry about.
And as for that mime-type trick, it won't be necessary. I'll still use .php file extensions but I can mask it with a URL rewrite. Also I could use rewrites to rewrite .php to .html. For example:
RewriteRule ^([0-9a-zA-Z?-]+)\.html$ $1.php
And as for dealing with uploading shells, I'll just encrypt the file contents and write them to a new .zip file. And when the file's going to be downloaded I'll just have the script decrypt the contents of the zipped folder and then output the results to the output buffer.