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>>

Reply via email to