Security patch for uploader.php
David Makalsky
dmakalsky at gmail.com
Fri Feb 20 03:07:44 UTC 2009
Hi Blake,
Good catch on the security hole. Here's what I will do for the Friday
release:
1. Rewrite the output
2. Disable the print_r
I agree that authentication is the way to go. I will make it a top priority
for the next iteration.
Regards,
David
On Thu, Feb 19, 2009 at 4:59 PM, electBlake <electblake at gmail.com> wrote:
> Hey Hey.
> that looks *alot* better. simple fixes that really plug some big holes.
>
> I do have a few comments.
>
> *1. Do we want to be printing out plain phrases like that?*
> How will your application know if it worked or not? Error testing against a
> string like "ok, it worked." seems a little weird.
> - Ideally we would want a SIMPLE xml output (which can be as simple as echo
> "<response><result>1</result></response>";)
> - If not, I think a simple boolean, and/or error code response would be
> good as well.
>
> *2. print_r($_FILES);*
> I am not sure this is required. Showing a user this information can lead to
> people access our files w/out our permission and can give away
> information about our file/server path structure which we really don't need
> to give away.
>
> *3. We we feel that we need more security?*
> I think we can consider those 2 points above, and after we've moved past
> them, we can look at some other authorization process.
> - Overall I am just scared that anyone with half a mind for toying with a
> site can upload files.
> - - example: I could upload 100MB files over and over again (with unlimited
> threads) until php and/or apache and/or the hard-disk fails. I could do this
> from the command line or even from php, which means I could setup a 5 dollar
> hostgator site and have it doing it 24 hours a day.
>
> so...what do we think? overkill? required? phase 2?
> There are many ways to stop this sort of thing, and many of them simple, I
> just want a feeling of our concern.
>
> - Blake
>
> On 19-Feb-09, at 4:01 PM, David Makalsky wrote:
>
>
>
> Hi Blake,
>
> I added some security after our tech discussion today to filter out
> potentially problematic file extensions and rachet down the permission level
> for the files and directories.
>
> Can you please have a look at it here:
>
> http://issues.fluidproject.org/secure/ManageAttachments.jspa?id=12488
>
> --
> David Makalsky
>
>
>
>
> --
> David Makalsky
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work
>
>
>
--
David Makalsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090219/3feb9d73/attachment.html>