It is a risk you're already taking, Mark. Remember that despite all the convenience factors the CF server is getting you, at its heart this transaction with the user is still just a browser sending a request via POST with a multipart form type. The POST data contains the file data already. By the time your CFML code is executing, the file they've uploaded is *already on the server* in a temp directory. By examining the mime-type, you aren't actually stopping the transaction before the file is on your server-- you're just doing stuff while it's in a temp location. I simply prefer to be more explicit and hands-on about it by the technique I advocated. Then you aren't trusting what the browser *claimed* about the file, you're examining *the file itself*. It isn't hard to make a bot emulate IE and upload an .exe or .cfm while deviously declaring "I'm uploading a mime-type of image/gif" -- so examining the file extension, not mime-type, is more secure.
On Thu, Jul 30, 2009 at 3:42 PM, Mark Davis <[email protected]>wrote: > agree on the mime type stuff Chris. I don't want to upload the file and > then check it out though. Seems like a much bigger security risk. > > Perhaps instead of looking at the mime type I can do a > ListLast(serverFileName, ".") to get the extension and just compare that way > instead of trusting the browser. > > > *Mark Davis **| Developer* > ** > > ** > ......................................................................................................................... > > Round Table Group, Inc. > > (281) 717-4575 > > [email protected] > > www.roundtablegroup.com > > > ......................................................................................................................... > > * * > [image: > https://www.roundtablegroup.com/secure/staff/emailSignature/RTG_logo.bmp]* > * > > *The Leading Authority in Expert Witness Search & **ReferralTM*** > > CONFIDENTIALITY NOTE: This e-mail, and any attachments thereto, is > intended only for use by the addressee(s) named in the message originated by > me and may contain legally privileged and/or confidential information. If > the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this email in > error, please notify me immediately by telephone and permanently delete the > original and any copy of the email, and any printout thereof. Thank you. > > > ------------------------------ > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Chris Champion > *Sent:* Thursday, July 30, 2009 3:23 PM > > *To:* [email protected] > *Subject:* [houcfug] Re: cfcatch question > > Well, remember that you're still at risk-- when working with mime-type > you're still trusting what the browser is telling you, and that's easy for a > hacker to spoof. (As is being done in a current exploit botnets are trying.) > > I actually prefer the roll-your-own security that Ajas and Mike are > suggesting. Use of a bit of file-shuffling gets around much of the danger > level Billy pointed out of allowing it on the server. > > 1. Upload destination should be somewhere well out of web tree -- > getTempDirectory is useful at these times. > 2. Explicitly check the extension of the uploaded file. Throw an error > if it isn't to your liking. > 3. If the file seems ok, use cffile to move it from temp directory to > its final location. > 4. Continue processing remainder of form data and throw errors as > appropriate. > > -CPC > > On Thu, Jul 30, 2009 at 3:04 PM, Mark Davis <[email protected]>wrote: > > >> exactly Billy. Want to keep the file off the server to start with >> >> Here is what I have working though. >> >> after investigating the cfcatch structure a bit, I noticed that if the >> error is thrown as a result of a filetype not listed in cffile accept="", >> cfcatch.mimetype is defined. Otherwise, its not. So for now, I have >> this... >> >> <cfcatch> >> >> <cfif >> isdefined("cfcatch.mimetype")> >> >> <!--- Log message ---> >> >> <cflog file="Public-Info-Messages" text="#cfcatch.message# >> #cfcatch.detail# #cfcatch.extendedInfo# Location: #errorLocation#" /> >> >> ...display some user message... >> >> <cfelse> >> >> <!--- log actual error ---> >> >> <cflog log="Application" text="#cfcatch.message# #cfcatch.detail# >> #cfcatch.extendedInfo# Location: #errorLocation#" /> >> >> ....display some user message... >> >> </cfif> >> </cfcatch> >> >> Will keep testing this. Thanks for the help guys. >> >> *Mark Davis **| Developer* >> ** >> >> ** >> ......................................................................................................................... >> >> Round Table Group, Inc. >> >> (281) 717-4575 >> >> [email protected] >> >> www.roundtablegroup.com >> >> >> ......................................................................................................................... >> >> ** >> [image: >> https://www.roundtablegroup.com/secure/staff/emailSignature/RTG_logo.bmp] >> ** >> >> *The Leading Authority in Expert Witness Search & **ReferralTM*** >> >> CONFIDENTIALITY NOTE: This e-mail, and any attachments thereto, is >> intended only for use by the addressee(s) named in the message originated by >> me and may contain legally privileged and/or confidential information. If >> the reader of this message is not the intended recipient, you are hereby >> notified that any dissemination, distribution or copying of this >> communication is strictly prohibited. If you have received this email in >> error, please notify me immediately by telephone and permanently delete the >> original and any copy of the email, and any printout thereof. Thank you. >> >> >> ------------------------------ >> *From:* [email protected] [mailto:[email protected]] *On >> Behalf Of *Billy Cravens *Sent:* Thursday, July 30, 2009 2:52 PM >> *To:* [email protected] >> *Subject:* [houcfug] Re: cfcatch question >> >> >> I doubt he wants to do that. Then he'd be letting the file onto the >> file system, which is what he's avoiding to begin with. By restricting the >> file type in the cffile tag, the file never gets saved to the file system, >> and the cffile structure is never set. -- >> Billy Cravens >> >> >> On Thu, Jul 30, 2009 at 2:28 PM, Mike G <[email protected]> wrote: >> >>> Are you trying to catch on upload, or catching as soon as you start >>> trying to process the uploaded file. >>> >>> If the latter, in the top of your cftry, evaluate cfile.serverfile >>> extension (don't have the docs in front of me for the exact var that >>> holds it) If it is not an allowable type, then use cfthrow and throw >>> a custom exception. Then in you cfcatch, trap for that custom >>> exception. pretty simple to do. >>> >>> On Thu, Jul 30, 2009 at 2:12 PM, Mark Davis<[email protected]> >>> wrote: >>> >>> > hey gang, > >>> > I have some pages where users upload photos and resumes. The mime >>> types >>> > allowed are limited to standard stuff. The page is wrapped in a >>> try/catch, >>> > that currently logs everything to one certain log file. We get a lot >>> of >>> > "errors" where the user is trying to upload an exe as a photo and crazy >>> > stuff like that. I want a specific cfcatch type="" to catch only those >>> > errors for mime type exceptions, handle those one way, then catch >>> everything >>> > else and handle a different way. I have the everything else, but I am >>> > having issues figuring out the mime type catch. anyone? thanks >>> > >>> > >>> > >>> > Mark Davis | Developer >>> > >>> > >>> ......................................................................................................................... >>> > >>> > Round Table Group, Inc. >>> > >>> > (281) 717-4575 >>> > >>> > [email protected] >>> > >>> > www.roundtablegroup.com >>> > >>> > >>> ......................................................................................................................... >>> > >>> > >>> > >>> >>> > The Leading Authority in Expert Witness Search & ReferralTM > >>> > CONFIDENTIALITY NOTE: This e-mail, and any attachments thereto, is >>> intended >>> > only for use by the addressee(s) named in the message originated by me >>> and >>> > may contain legally privileged and/or confidential information. If the >>> > reader of this message is not the intended recipient, you are hereby >>> > notified that any dissemination, distribution or copying of this >>> > communication is strictly prohibited. If you have received this email >>> in >>> > error, please notify me immediately by telephone and permanently delete >>> the >>> > original and any copy of the email, and any printout thereof. Thank >>> you. >>> > >>> > >>> > > >>> > >>> >>> >>> >>> >> >> >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Houston ColdFusion Users' Group" discussion list. To unsubscribe, send email to [email protected] For more options, visit http://groups.google.com/group/houcfug?hl=en -~----------~----~----~----~------~----~------~--~---
<<inline: image001.gif>>
<<inline: image001.gif>>
