XUpload - xupload security

Message
Author
watcha
Posts: 12
Joined: Oct 08, 2006 1:08 am

xupload security

#1 Postby watcha » Oct 08, 2006 1:14 am

I just installed the free version and it makes a quite good impression.

1.)
How should I chmod the cgi and pm files in the cgi-bin/xupload path?


2.)
I am just wondering about security issues.
Which possible leaks there are currently, which can be result in malicious usage by hackers etc.

I want to allow registered users of my portal to upload media files. But my portal users can be anyone like anonymous users.

Is Xuoad secure enough to use it for such project?
I need to make sure that the users can not hoodwink Xupload and load for example files into my directory which would allow them to hack my server.

Thank you very much in advance.
With kind regards

User avatar
PilgrimX182
Posts: 2186
Joined: Mar 22, 2006 1:39 pm

#2 Postby PilgrimX182 » Oct 09, 2006 1:19 pm

1) .cgi to 755, .pm to 744

2) When we created XUpload we were thinking about security too, so it's pretty safe(hackers won't be able to upload file to another folder except specified in config)

But you have to customize it to check for User cookie or session_id. So you need authorization inside upload.cgi script.

watcha
Posts: 12
Joined: Oct 08, 2006 1:08 am

#3 Postby watcha » Oct 09, 2006 2:56 pm

Thank you for your quick respond! XUpload makes still a very good impression. An belive me I spent already several days on testion upload engines. I have a few more questions before my final decision.


1. I have set my *.pm to 644 and it works.


2.
Could XUpload be utilized by hackers that way, that they upload a file with an allowed extension and rename the extension somehow to cgi extension to execute it than and to damage my webportal?


3.
Is it possible for hackers to download files from the upload folder (folder to which my portal users upload their files)? I do not want to allow download.

Because that way it would make sense for hackers to use my webserver as a storage for hacked uploads and downloads. But if they are only able to upload but not download the interest of doing so would not be as big.

Thank you very much in advance.

User avatar
PilgrimX182
Posts: 2186
Joined: Mar 22, 2006 1:39 pm

#4 Postby PilgrimX182 » Oct 10, 2006 5:16 am

1. Yes, 644 works too, I guess even 444 will work fine, but you won't be able to delete the file, only after chmod :) But you can use it to be hackerproof.

2. Don't think they will be able to do this.

3. It's up to you actually. Depends on where upload folder is. If it's in htdocs hackers will be able to download files. I reccomend to put upload dir to folder not available from browser(not htdocs), and send files to your users from PHP, there are tons of scripts(antileech scripts).

Thanks for choosing XUpload.

watcha
Posts: 12
Joined: Oct 08, 2006 1:08 am

#5 Postby watcha » Oct 10, 2006 11:39 am

Currently I am uploading the files to a folder which is in html/cgi-bin/uploadfinished.

Trying to access this folder, even when typing in the correct filename it just shows an error.

E.g. when trying to access the uploaded file via:
www.mytestsite.com/cgi-bin/uploadfinish/big-file.zip

The user gets:

The server encountered an internal error and was unable to complete your request.

Error message:
Premature end of script headers: big-file.zip


I think this is save enough. Please correct me if I am wrong.
Thank you very much in advance.

User avatar
PilgrimX182
Posts: 2186
Joined: Mar 22, 2006 1:39 pm

#6 Postby PilgrimX182 » Oct 11, 2006 6:10 am

That is correct. You can download files only from htdocs.

hanji
Posts: 36
Joined: Nov 10, 2006 3:33 am

#7 Postby hanji » Nov 10, 2006 3:49 am

watcha wrote: 2.
Could XUpload be utilized by hackers that way, that they upload a file with an allowed extension and rename the extension somehow to cgi extension to execute it than and to damage my webportal?
First off.. I think this program is awesome, but I do have some concerns with security. My question related to this.. is upload.cgi just looking at the extension or examining the file? I see there is a ext_allowed configuration... but how is it validating MIME type? We shouldn't be able to trust the 'type' passed from the browser. This might be a feature request, but a hook into `file` might be a good thing to determine MIME types, but this will limit where this product can be installed... ie: linux only,etc and with file installed.

Anyway.. just a thought.

hanji

User avatar
PilgrimX182
Posts: 2186
Joined: Mar 22, 2006 1:39 pm

#8 Postby PilgrimX182 » Nov 10, 2006 6:15 am

Thanks hanji,
I have this feature in mind and have module to do this using file headers. No need to install it, so everything will be fine. Look for it forward in next release.

hanji
Posts: 36
Joined: Nov 10, 2006 3:33 am

#9 Postby hanji » Nov 10, 2006 6:22 am

Nice.. I'm looking forward to it.

hanji