Mark, Good to know. I certainly understand about future threats, but I think this is sufficient to keep my current approach (with the modifications outlined) with only a relatively mild warning about putting files outside the web root (but a major one about white listing extensions).
Maybe I will even require an extensions attribute for files so that you have to specify extensions="" if you want to allow all extensions. That does potentially have a backward compatibility issue for existing code, but still probably worth it (if we have any open file uploads, I want to know anyway). As to why I am trying to stay with this approach, it comes down to easy installation and set-up. Neptune sites should be super-easy to set up and get going and should run in as wide a variety of platforms as possible (some hosts, for example, don't give you space outside of your own web root). Even where it can be done, it is an extra step (if only a small one). Everything about the framework is supposed to be brain-dead easy to use. Any place where I move away from "obvious and blindingly easy to use" I want to have a really compelling reason to do so. Even a small step away from this goal should have a compelling reason. In other news, this is just the sort of feedback I was hoping for. It has been really helpful and I appreciate you guys taking the time to help me out with this. If anyone has more thoughts or suggestions, I would love to hear them. Thanks! Steve >Steve, > >I'd say you've protected against conceivable threats with that approach - >but I still always store files outside the web root. My problem is that my >conceiver isn't always that great and ornery hackers have better conceivers >than I do. Can I ask what you are trying to save with this approach? What's >the point of doing it this way as opposed to outside of the web root? > >-Mark > >P.S. Thanks for the comments about my blog - always nice to hear! > > > >Mark, > >I actually remember reading that blog post when it came out (I always love >your blog, by the way). To be honest, I don't remember if I am doing that >validation in place or not. Certainly this does demonstrate that it >shouldn't be done in place - and I will address that if it is. > >I am curious, however, about the following scenario: > >- The files are temporarily uploaded to another location and then validated >and then moved to their final destination. >- Server side checking on both mime-type AND extension >- A black list of file extensions is maintained for file fields that do not >have a white list of extensions (with docs advising that all files should). >- Read/Write access but no execute access for upload folders >- Application.cfm in the root of the uploaded folders > >With all of that, how serious is the threat of having the default upload >location be inside the web root? > >Keeping in mind that the goal is dead-simple set up and development (though >security, of course, cannot be ignored). > >Thanks, > >Steve > >>Steve, >> >>This is one off, but this post explains how you can exploit the latency >>between storing the file and handling or deleting it IF you store your temp >>file in a web root accessible folder: >> >>http://www.coldfusionmuse.com/index.cfm/2009/9/18/script.insertion.attack.v >ector >> >>-Mark ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:340454 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
