RE: [ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread Charlie Arehart
Emile, if your site is running on IIS, another idea would be to use the .NET
framework to secure the directories. You can find discussions in various
.net articles/books/blogs. Here's one simplistic discussion from MS:
http://support.microsoft.com/kb/893662

 

People don't tend to think of this because they think "my code is in CF".
But the whole point of this discussion is that you're talking about
accessing non-CF files, and therefore can consider solutions that are not
CF-based. Shawn's idea of CFCONTENT is of course a way to bring it back to
CF's purview. It kind of all depends on what authentication mechanism you
want to use: one under CF's control, or one you'd be willing to let be
managed by something else (whether the CF, the web server or the .NET
framework managing it, and whether-in the latter 2-your're using windows
forms, passport, or windows authentication).

 

Hope that's helpful. I do realize it's WAY outside the box. :-)

 

/charlie

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Emile Melbourne
Sent: Thursday, December 18, 2008 12:01 PM
To: discussion@acfug.org
Subject: [ACFUG Discuss] Blocking a ColdFusion website's directory

 

Hey Everyone,

 

I am currently in the process of building my first secured site.  Most pages
of the site will be behind a login page.  I'm using ColdFusion's
Application.cfc onRequestStart function to check if a user is logged in or
not.  Thats pretty much boiler plate.

 

My concern is how to prevent an non authorized user from accessing or
hotlinking to non ColdFusion page. (i.e, images, pdfs, swfs, .txt etc).

 

Whats the best way to ensure a user can't link directly to these items but
instead be redirected to login.cfm instead?

 

Is there a way to lock down an entire directory?

 

Thank you for all your help

Emile

 


- 
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform 

For more info, see http://www.acfug.org/mailinglists 
Archive @ http://www.mail-archive.com/discussion%40acfug.org/ 
List hosted by FusionLink   
- 




-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-



RE: re[2]: [ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread Charlie Arehart
Emile, the sandbox features are for protecting what files/dirs a CFML app
can access. It's intended to be used on a server where different developers
of different apps (on the same box) should not be able to access each
other's files, or files outside their purview. BTW, it's called Sandbox
Security in Enterprise, but it's called Resource Security on CF Standard.
I've done a pair of articles on the topic in the Adobe DevCenter (from  the
CFMX timeframe, but it's still applicable):

 

http://www.adobe.com/devnet/security/articles/sandbox_01.html

http://www.adobe.com/devnet/security/articles/sandbox_02.html

 

Hope that helps.

 

/charlie

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Emile Melbourne
Sent: Thursday, December 18, 2008 5:24 PM
To: discussion@acfug.org
Subject: Re: re[2]: [ACFUG Discuss] Blocking a ColdFusion website's
directory

 



 

Shawn, what is the purpose of the files and directory settings in the
Sandbox? I suppose this should go into a separate thread.

 

 

Emile 




-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-



Re: re[2]: [ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread Dean H. Saxe

Emile,

I'll send you my Adobe Max presentation on this very topic  
(authorization), specifically addressing the different attack patterns  
and high level solutions appropriate for any language, though the  
examples are CF-specific.  It may take me a day or so until I get back  
to work and can forward it.  If anyone else wishes a copy drop me a  
line at dean.saxe [at] foundstone.com.


Thanks,
-dhs


Dean H. Saxe, CISSP, CEH
d...@fullfrontalnerdity.com
"What difference does it make to the dead,  the orphans, and the  
homeless, whether the  mad destruction is wrought under the name of  
totalitarianism or the holy name of  liberty and democracy? "

--Gandhi



On Dec 18, 2008, at 5:24 PM, Emile Melbourne wrote:


Hey Teddy,
That is by far great advice on how to tackle scalability, it make  
sense.


There maybe situations where this may not be a good tatic such as  
when a one to one connection between a pdf and the user account that  
owns it is required.


However, I'd admit I would have overlooked that scalabilty solution  
you brought up.  Glad you've mentioned how to manage it.


Shawn, what is the purpose of the files and directory settings in  
the Sandbox? I suppose this should go into a separate thread.

Also, I'm testing you script now.


Emile
On Thu, Dec 18, 2008 at 3:11 PM, Teddy R. Payne  
 wrote:

Emile,
You are correct.  If you have authenticated users, you will  
eventually have to approach how to programmatically change the  
behavior of your PDF files.


Advice that I can give you would be to avoid a scalable pitfall of  
assigning users to a particular file.  Instead, assign a role to a  
file and then assign a role to a user.  This way, you are not adding  
1000 users to one file.  You may add 1000 users to a role, but that  
never changes your implementation of the role associated to a file.   
Does that make sense?



Teddy R. Payne, ACCFD
Google Talk - teddyrpa...@gmail.com



On Thu, Dec 18, 2008 at 3:03 PM, shawn gorrell   
wrote:

That isn't the function of sandboxes.

Here is a code sample of my previously described approach. It is  
primitive, but solves what you're trying to solve. Whatever  
directory your asset files live in should be set to no web access.  
CF will be able to get the files, but a web browser could not.












































There was a problem retrieving your file.



From: Emile Melbourne 
To: discussion@acfug.org
Sent: Thursday, December 18, 2008 2:55:33 PM
Subject: Re: re[2]: [ACFUG Discuss] Blocking a ColdFusion website's  
directory


Thanks guys for all your responces.

Only users who have logged in/authenticated should be should be  
authorized to view these secured pdf files and images.  In the  
future, I imagine specific pdfs will be viewable to specific  
authenticated users which I suppose would be the authorization topic  
Teddy is getting at. Am I right about this?


I'm going to test putting the files meant to be secure outside of  
the site root folder and getting it to work that way.


I've also come accross settings found in the ADOBE COLDFUSION  
ADMINISTRATOR meant to let users enable and disable access to  
specific files and directories
   Security > Resource Security > CHECK "Enable ColdFusion Sandbox  
Security"


Do you guys know if this is also a solution to this particular  
problem?


Thanks Again
Emile


On Thu, Dec 18, 2008 at 1:43 PM, Teddy R. Payne  
 wrote:

Mischa,
Yes, but as you can see from Shawn's comment that Shawn was  
approaching the topic from the point of authorization.  From the  
response by Troy, this leads to authentication.


So, his usage of diction or use of the word is indeed correct, but  
not everyone interpreted it that way as it still provided some  
confusion regardless.


The solution may very well use both concepts to achieve his desired  
result.


A use that I have witnessed has to deal with Shawn's suggestion of  
putting the files in a non-webroot accessible directory or network  
source.  Then a controller mechanism would have to understand how to  
"serve once" either through a mechanism of of being an authenticated  
user with an authorized role of being able to see a document.  Or,  
the the site does not have authentication and the mechanism must  
have a more introspective ability to discern a user through their  
token, IP or whatever.  The public approach would suggest a tracking  
process to see if a particular requestor has asked for the document  
before or not.


This also brings up the question, how do you determine who has the  
authorization to request a particular artifact multiple times?


This may be over complicating his initial scope of the application,  
but these are questions that I would ask whenever someone would task  
me with a File serving application on potentially limited released  
documents.


I

Re: re[2]: [ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread Emile Melbourne
Hey Teddy,
That is by far great advice on how to tackle scalability, it make sense.

There maybe situations where this may not be a good tatic such as when a one
to one connection between a pdf and the user account that owns it is
required.

However, I'd admit I would have overlooked that scalabilty solution you
brought up.  Glad you've mentioned how to manage it.

Shawn, what is the purpose of the files and directory settings in the
Sandbox? I suppose this should go into a separate thread.
Also, I'm testing you script now.


Emile
On Thu, Dec 18, 2008 at 3:11 PM, Teddy R. Payne wrote:

> Emile,
> You are correct.  If you have authenticated users, you will eventually have
> to approach how to programmatically change the behavior of your PDF files.
>
> Advice that I can give you would be to avoid a scalable pitfall of
> assigning users to a particular file.  Instead, assign a role to a file and
> then assign a role to a user.  This way, you are not adding 1000 users to
> one file.  You may add 1000 users to a role, but that never changes your
> implementation of the role associated to a file.  Does that make sense?
>
> Teddy R. Payne, ACCFD
> Google Talk - teddyrpa...@gmail.com
>
>
>
>   On Thu, Dec 18, 2008 at 3:03 PM, shawn gorrell wrote:
>
>>  That isn't the function of sandboxes.
>>
>> Here is a code sample of my previously described approach. It is
>> primitive, but solves what you're trying to solve. Whatever directory your
>> asset files live in should be set to no web access. CF will be able to get
>> the files, but a web browser could not.
>>
>> 
>> 
>> 
>> 
>>
>> 
>> 
>> 
>> 
>> 
>> 
>>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>
>> 
>> 
>> 
>>
>> 
>> There was a problem retrieving your file.
>> 
>> 
>>
>>  --
>> *From:* Emile Melbourne 
>> *To:* discussion@acfug.org
>> *Sent:* Thursday, December 18, 2008 2:55:33 PM
>> *Subject:* Re: re[2]: [ACFUG Discuss] Blocking a ColdFusion website's
>> directory
>>
>> Thanks guys for all your responces.
>>
>> Only users who have logged in/authenticated should be should be authorized
>> to view these secured pdf files and images.  In the future, I imagine
>> specific pdfs will be viewable to specific authenticated users which I
>> suppose would be the authorization topic Teddy is getting at. Am I right
>> about this?
>>
>> I'm going to test putting the files meant to be secure outside of the site
>> root folder and getting it to work that way.
>>
>> I've also come accross settings found in the ADOBE COLDFUSION
>> ADMINISTRATOR meant to let users enable and disable access to specific files
>> and directories
>>Security > Resource Security > CHECK "Enable ColdFusion Sandbox
>> Security"
>>
>> Do you guys know if this is also a solution to this particular problem?
>>
>> Thanks Again
>> Emile
>>
>>
>> On Thu, Dec 18, 2008 at 1:43 PM, Teddy R. Payne wrote:
>>
>>> Mischa,
>>> Yes, but as you can see from Shawn's comment that Shawn was approaching
>>> the topic from the point of authorization.  From the response by Troy, this
>>> leads to authentication.
>>>
>>> So, his usage of diction or use of the word is indeed correct, but not
>>> everyone interpreted it that way as it still provided some confusion
>>> regardless.
>>>
>>> The solution may very well use both concepts to achieve his desired
>>> result.
>>>
>>> A use that I have witnessed has to deal with Shawn's suggestion of
>>> putting the files in a non-webroot accessible directory or network source.
>>> Then a controller mechanism would have to understand how to "serve once"
>>> either through a mechanism of of being an authenticated user with an
>>> authorized role of being able to see a document.  Or, the the site does not
>>> have authentication and the mechanism must have a more introspective ability
>>> to discern a user through their token, IP or whatever.  The public approach
>>> would suggest a tracking process to see if a particular requestor has asked
>>> for the document before or not.
>>>
>>> This also brings up the question, how do you determine who has the
>>> authorization to request a particular artifact multiple times?
>>>
>>> This may be over complicating his initial scope of the application, but
>>> these are questions that I would ask whenever someone would task me with a
>>> File serving application on potentially limited released documents.
>>>
>>> In any event, I was not criticizing Emile.  I was asking for more detail
>>> before offering generic advice/guidance.
>>>
>>> Teddy R. Payne, ACCFD
>>> Google Talk - teddyrpa...@gmail.com
>>>
>>>
>>>
>>>   On Thu, Dec 18, 2008 at 1:32 PM, Mischa Uppelschoten ext 10 <
>>> mischa.uppelscho...@bankersx.com> wrote:
>>>
 OP never used the word "authentication". From wikipedia: "authorization
 is the concept of allowing acc

Re: re[2]: [ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread Teddy R. Payne
Emile,
You are correct.  If you have authenticated users, you will eventually have
to approach how to programmatically change the behavior of your PDF files.

Advice that I can give you would be to avoid a scalable pitfall of assigning
users to a particular file.  Instead, assign a role to a file and then
assign a role to a user.  This way, you are not adding 1000 users to one
file.  You may add 1000 users to a role, but that never changes your
implementation of the role associated to a file.  Does that make sense?

Teddy R. Payne, ACCFD
Google Talk - teddyrpa...@gmail.com



On Thu, Dec 18, 2008 at 3:03 PM, shawn gorrell  wrote:

> That isn't the function of sandboxes.
>
> Here is a code sample of my previously described approach. It is primitive,
> but solves what you're trying to solve. Whatever directory your asset files
> live in should be set to no web access. CF will be able to get the files,
> but a web browser could not.
>
> 
> 
> 
> 
>
> 
> 
> 
> 
> 
> 
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> 
> 
> 
>
> 
> There was a problem retrieving your file.
> 
> 
>
> --
> *From:* Emile Melbourne 
> *To:* discussion@acfug.org
> *Sent:* Thursday, December 18, 2008 2:55:33 PM
> *Subject:* Re: re[2]: [ACFUG Discuss] Blocking a ColdFusion website's
> directory
>
> Thanks guys for all your responces.
>
> Only users who have logged in/authenticated should be should be authorized
> to view these secured pdf files and images.  In the future, I imagine
> specific pdfs will be viewable to specific authenticated users which I
> suppose would be the authorization topic Teddy is getting at. Am I right
> about this?
>
> I'm going to test putting the files meant to be secure outside of the site
> root folder and getting it to work that way.
>
> I've also come accross settings found in the ADOBE COLDFUSION ADMINISTRATOR
> meant to let users enable and disable access to specific files and
> directories
>Security > Resource Security > CHECK "Enable ColdFusion Sandbox
> Security"
>
> Do you guys know if this is also a solution to this particular problem?
>
> Thanks Again
> Emile
>
>
> On Thu, Dec 18, 2008 at 1:43 PM, Teddy R. Payne wrote:
>
>> Mischa,
>> Yes, but as you can see from Shawn's comment that Shawn was approaching
>> the topic from the point of authorization.  From the response by Troy, this
>> leads to authentication.
>>
>> So, his usage of diction or use of the word is indeed correct, but not
>> everyone interpreted it that way as it still provided some confusion
>> regardless.
>>
>> The solution may very well use both concepts to achieve his desired
>> result.
>>
>> A use that I have witnessed has to deal with Shawn's suggestion of putting
>> the files in a non-webroot accessible directory or network source.  Then a
>> controller mechanism would have to understand how to "serve once" either
>> through a mechanism of of being an authenticated user with an authorized
>> role of being able to see a document.  Or, the the site does not have
>> authentication and the mechanism must have a more introspective ability to
>> discern a user through their token, IP or whatever.  The public approach
>> would suggest a tracking process to see if a particular requestor has asked
>> for the document before or not.
>>
>> This also brings up the question, how do you determine who has the
>> authorization to request a particular artifact multiple times?
>>
>> This may be over complicating his initial scope of the application, but
>> these are questions that I would ask whenever someone would task me with a
>> File serving application on potentially limited released documents.
>>
>> In any event, I was not criticizing Emile.  I was asking for more detail
>> before offering generic advice/guidance.
>>
>> Teddy R. Payne, ACCFD
>> Google Talk - teddyrpa...@gmail.com
>>
>>
>>
>>   On Thu, Dec 18, 2008 at 1:32 PM, Mischa Uppelschoten ext 10 <
>> mischa.uppelscho...@bankersx.com> wrote:
>>
>>> OP never used the word "authentication". From wikipedia: "authorization
>>> is the concept of allowing access to resources only to those permitted to
>>> use them." Seems to me he used the term properly.
>>> /m
>>>
>>>
>>>
>>> : Emile,
>>>  : From your description, you really need to define what "authorized"
>>> and "not
>>> :  authorized" means.
>>>
>>> : This will help clarify to the people assisting you as to the approach
>>> they can
>>> :  suggest.
>>>
>>> : As "authorization" and "authentication" often times are used
>>> interchangeably
>>> :  by developers when in fact they represent two distinctly different
>>> topics.
>>>
>>> : Teddy R. Payne, ACCFD
>>> : Google Talk - teddyrpa...@gmail.com
>>>
>>>
>>>
>>>
>>> : On Thu, Dec 18, 2008 at 12:00 PM, Emile Melbourne <
>>> emile.melbou...@gmail.com>
>>> :  wrote:
>>>
>>>
>>> : Hey Everyo

Re: re[2]: [ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread shawn gorrell
That isn't the function of sandboxes.

Here is a code sample of my previously described approach. It is primitive, but 
solves what you're trying to solve. Whatever directory your asset files live in 
should be set to no web access. CF will be able to get the files, but a web 
browser could not.










































There was a problem retrieving your file.







From: Emile Melbourne 
To: discussion@acfug.org
Sent: Thursday, December 18, 2008 2:55:33 PM
Subject: Re: re[2]: [ACFUG Discuss] Blocking a ColdFusion website's directory


Thanks guys for all your responces. 
 
Only users who have logged in/authenticated should be should be authorized to 
view these secured pdf files and images.  In the future, I imagine specific 
pdfs will be viewable to specific authenticated users which I suppose would be 
the authorization topic Teddy is getting at. Am I right about this?
 
I'm going to test putting the files meant to be secure outside of the site root 
folder and getting it to work that way. 
 
I've also come accross settings found in the ADOBE COLDFUSION ADMINISTRATOR 
meant to let users enable and disable access to specific files and directories
   Security > Resource Security > CHECK "Enable ColdFusion Sandbox Security"
 
Do you guys know if this is also a solution to this particular problem?
 
Thanks Again
Emile

 
On Thu, Dec 18, 2008 at 1:43 PM, Teddy R. Payne  wrote:

Mischa,
Yes, but as you can see from Shawn's comment that Shawn was approaching the 
topic from the point of authorization.  From the response by Troy, this leads 
to authentication.

So, his usage of diction or use of the word is indeed correct, but not everyone 
interpreted it that way as it still provided some confusion regardless.

The solution may very well use both concepts to achieve his desired result.  

A use that I have witnessed has to deal with Shawn's suggestion of putting the 
files in a non-webroot accessible directory or network source.  Then a 
controller mechanism would have to understand how to "serve once" either 
through a mechanism of of being an authenticated user with an authorized role 
of being able to see a document.  Or, the the site does not have authentication 
and the mechanism must have a more introspective ability to discern a user 
through their token, IP or whatever.  The public approach would suggest a 
tracking process to see if a particular requestor has asked for the document 
before or not.

This also brings up the question, how do you determine who has the 
authorization to request a particular artifact multiple times?

This may be over complicating his initial scope of the application, but these 
are questions that I would ask whenever someone would task me with a File 
serving application on potentially limited released documents.

In any event, I was not criticizing Emile.  I was asking for more detail before 
offering generic advice/guidance. 


Teddy R. Payne, ACCFD
Google Talk - teddyrpa...@gmail.com




On Thu, Dec 18, 2008 at 1:32 PM, Mischa Uppelschoten ext 10 
 wrote:

OP never used the word "authentication". From wikipedia: "authorization is the 
concept of allowing access to resources only to those permitted to use them." 
Seems to me he used the term properly.
/m



: Emile,

: From your description, you really need to define what "authorized" and "not
:  authorized" means.

: This will help clarify to the people assisting you as to the approach they can
:  suggest.

: As "authorization" and "authentication" often times are used interchangeably
:  by developers when in fact they represent two distinctly different topics.

: Teddy R. Payne, ACCFD
: Google Talk - teddyrpa...@gmail.com




: On Thu, Dec 18, 2008 at 12:00 PM, Emile Melbourne 
:  wrote:


: Hey Everyone,
:
: I am currently in the process of building my first secured site.  Most 
pages
:  of the site will be behind a login page.  I'm using ColdFusion's
:  Application.cfc onRequestStart function to check if a user is logged in or
:  not.  Thats pretty much boiler plate.
:
: My concern is how to prevent an non authorized user from accessing or
:  hotlinking to non ColdFusion page. (i.e, images, pdfs, swfs, .txt etc).
:
: Whats the best way to ensure a user can't link directly to these items but
:  instead be redirected to login.cfm instead?
:
: Is there a way to lock down an entire directory?
:
: Thank you for all your help
: Emile
:

: -
: To unsubscribe from this list, manage your profile @
: http://www.acfug.org?fa=login.edituserform
:
: For more info, see http://www.acfug.org/mailinglists
: Archive @ http://www.mail-archive.com/discussion%40acfug.org/
: List hosted by FusionLink 
: 

Re: re[2]: [ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread Emile Melbourne
Thanks guys for all your responces.

Only users who have logged in/authenticated should be should be authorized
to view these secured pdf files and images.  In the future, I imagine
specific pdfs will be viewable to specific authenticated users which I
suppose would be the authorization topic Teddy is getting at. Am I right
about this?

I'm going to test putting the files meant to be secure outside of the site
root folder and getting it to work that way.

I've also come accross settings found in the ADOBE COLDFUSION ADMINISTRATOR
meant to let users enable and disable access to specific files and
directories
   Security > Resource Security > CHECK "Enable ColdFusion Sandbox Security"

Do you guys know if this is also a solution to this particular problem?

Thanks Again
Emile


On Thu, Dec 18, 2008 at 1:43 PM, Teddy R. Payne wrote:

> Mischa,
> Yes, but as you can see from Shawn's comment that Shawn was approaching the
> topic from the point of authorization.  From the response by Troy, this
> leads to authentication.
>
> So, his usage of diction or use of the word is indeed correct, but not
> everyone interpreted it that way as it still provided some confusion
> regardless.
>
> The solution may very well use both concepts to achieve his desired
> result.
>
> A use that I have witnessed has to deal with Shawn's suggestion of putting
> the files in a non-webroot accessible directory or network source.  Then a
> controller mechanism would have to understand how to "serve once" either
> through a mechanism of of being an authenticated user with an authorized
> role of being able to see a document.  Or, the the site does not have
> authentication and the mechanism must have a more introspective ability to
> discern a user through their token, IP or whatever.  The public approach
> would suggest a tracking process to see if a particular requestor has asked
> for the document before or not.
>
> This also brings up the question, how do you determine who has the
> authorization to request a particular artifact multiple times?
>
> This may be over complicating his initial scope of the application, but
> these are questions that I would ask whenever someone would task me with a
> File serving application on potentially limited released documents.
>
> In any event, I was not criticizing Emile.  I was asking for more detail
> before offering generic advice/guidance.
>
> Teddy R. Payne, ACCFD
> Google Talk - teddyrpa...@gmail.com
>
>
>
>   On Thu, Dec 18, 2008 at 1:32 PM, Mischa Uppelschoten ext 10 <
> mischa.uppelscho...@bankersx.com> wrote:
>
>> OP never used the word "authentication". From wikipedia: "authorization is
>> the concept of allowing access to resources only to those permitted to use
>> them." Seems to me he used the term properly.
>> /m
>>
>>
>>
>> : Emile,
>>  : From your description, you really need to define what "authorized" and
>> "not
>> :  authorized" means.
>>
>> : This will help clarify to the people assisting you as to the approach
>> they can
>> :  suggest.
>>
>> : As "authorization" and "authentication" often times are used
>> interchangeably
>> :  by developers when in fact they represent two distinctly different
>> topics.
>>
>> : Teddy R. Payne, ACCFD
>> : Google Talk - teddyrpa...@gmail.com
>>
>>
>>
>>
>> : On Thu, Dec 18, 2008 at 12:00 PM, Emile Melbourne <
>> emile.melbou...@gmail.com>
>> :  wrote:
>>
>>
>> : Hey Everyone,
>> :
>> : I am currently in the process of building my first secured site.
>>  Most pages
>> :  of the site will be behind a login page.  I'm using ColdFusion's
>> :  Application.cfc onRequestStart function to check if a user is logged in
>> or
>> :  not.  Thats pretty much boiler plate.
>> :
>> : My concern is how to prevent an non authorized user from accessing
>> or
>> :  hotlinking to non ColdFusion page. (i.e, images, pdfs, swfs, .txt etc).
>> :
>> : Whats the best way to ensure a user can't link directly to these
>> items but
>> :  instead be redirected to login.cfm instead?
>> :
>> : Is there a way to lock down an entire directory?
>> :
>> : Thank you for all your help
>> : Emile
>> :
>>
>> : -
>> : To unsubscribe from this list, manage your profile @
>> : 
>> http://www.acfug.org?fa=login.edituserform
>> :
>> : For more info, see http://www.acfug.org/mailinglists
>> : Archive @ http://www.mail-archive.com/discussion%40acfug.org/
>> : List hosted by FusionLink 
>> : -
>>
>>
>>
>> : -
>> : To unsubscribe from this list, manage your profile @
>> : 
>> http://www.acfug.org?fa=login.edituserform
>>
>> : For more info, see http://www.acfug.org/mailinglists
>> : Archive @ http://www.mail-archive.com/discussion%40acfug.org/

Re: re[2]: [ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread Teddy R. Payne
Mischa,
Yes, but as you can see from Shawn's comment that Shawn was approaching the
topic from the point of authorization.  From the response by Troy, this
leads to authentication.

So, his usage of diction or use of the word is indeed correct, but not
everyone interpreted it that way as it still provided some confusion
regardless.

The solution may very well use both concepts to achieve his desired result.


A use that I have witnessed has to deal with Shawn's suggestion of putting
the files in a non-webroot accessible directory or network source.  Then a
controller mechanism would have to understand how to "serve once" either
through a mechanism of of being an authenticated user with an authorized
role of being able to see a document.  Or, the the site does not have
authentication and the mechanism must have a more introspective ability to
discern a user through their token, IP or whatever.  The public approach
would suggest a tracking process to see if a particular requestor has asked
for the document before or not.

This also brings up the question, how do you determine who has the
authorization to request a particular artifact multiple times?

This may be over complicating his initial scope of the application, but
these are questions that I would ask whenever someone would task me with a
File serving application on potentially limited released documents.

In any event, I was not criticizing Emile.  I was asking for more detail
before offering generic advice/guidance.

Teddy R. Payne, ACCFD
Google Talk - teddyrpa...@gmail.com



On Thu, Dec 18, 2008 at 1:32 PM, Mischa Uppelschoten ext 10 <
mischa.uppelscho...@bankersx.com> wrote:

> OP never used the word "authentication". From wikipedia: "authorization is
> the concept of allowing access to resources only to those permitted to use
> them." Seems to me he used the term properly.
> /m
>
>
>
> : Emile,
> : From your description, you really need to define what "authorized" and
> "not
> :  authorized" means.
>
> : This will help clarify to the people assisting you as to the approach
> they can
> :  suggest.
>
> : As "authorization" and "authentication" often times are used
> interchangeably
> :  by developers when in fact they represent two distinctly different
> topics.
>
> : Teddy R. Payne, ACCFD
> : Google Talk - teddyrpa...@gmail.com
>
>
>
>
> : On Thu, Dec 18, 2008 at 12:00 PM, Emile Melbourne <
> emile.melbou...@gmail.com>
> :  wrote:
>
>
> : Hey Everyone,
> :
> : I am currently in the process of building my first secured site.
>  Most pages
> :  of the site will be behind a login page.  I'm using ColdFusion's
> :  Application.cfc onRequestStart function to check if a user is logged in
> or
> :  not.  Thats pretty much boiler plate.
> :
> : My concern is how to prevent an non authorized user from accessing or
> :  hotlinking to non ColdFusion page. (i.e, images, pdfs, swfs, .txt etc).
> :
> : Whats the best way to ensure a user can't link directly to these
> items but
> :  instead be redirected to login.cfm instead?
> :
> : Is there a way to lock down an entire directory?
> :
> : Thank you for all your help
> : Emile
> :
>
> : -
> : To unsubscribe from this list, manage your profile @
> : http://www.acfug.org?fa=login.edituserform
> :
> : For more info, see http://www.acfug.org/mailinglists
> : Archive @ http://www.mail-archive.com/discussion%40acfug.org/
> : List hosted by FusionLink 
> : -
>
>
>
> : -
> : To unsubscribe from this list, manage your profile @
> : http://www.acfug.org?fa=login.edituserform
>
> : For more info, see http://www.acfug.org/mailinglists
> : Archive @ http://www.mail-archive.com/discussion%40acfug.org/
> : List hosted by FusionLink 
> : -
>
>
>
>
>
>
> -- Original Message --
>
> FROM:  "Teddy R. Payne" 
> TO:
> DATE:  Thu, 18 Dec 2008 13:25:15 -0500
>
> SUBJECT:   Re: [ACFUG Discuss] Blocking a ColdFusion website's directory
>
> Emile,
> From your description, you really need to define what "authorized" and "not
> authorized" means.
>
> This will help clarify to the people assisting you as to the approach they
> can suggest.
>
> As "authorization" and "authentication" often times are used
> interchangeably by developers when in fact they represent two distinctly
> different topics.
>
> Teddy R. Payne, ACCFD
> Google Talk - teddyrpa...@gmail.com
>
>
>
>
> On Thu, Dec 18, 2008 at 12:00 PM, Emile Melbourne <
> emile.melbou...@gmail.com> wrote:
>
>
>Hey Everyone,
>
>I am currently in the process of building my first secured site.  Most
> pages of the site will be behind a login page.  I'm using ColdFusion's
> Application.cfc onRequestStart functi

re[2]: [ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread Mischa Uppelschoten ext 10
OP never used the word "authentication". From wikipedia: "authorization is the 
concept of allowing access to resources only to those permitted to use them." 
Seems to me he used the term properly.
/m



: Emile,
: From your description, you really need to define what "authorized" and "not
:  authorized" means.

: This will help clarify to the people assisting you as to the approach they can
:  suggest.

: As "authorization" and "authentication" often times are used interchangeably
:  by developers when in fact they represent two distinctly different topics.

: Teddy R. Payne, ACCFD
: Google Talk - teddyrpa...@gmail.com




: On Thu, Dec 18, 2008 at 12:00 PM, Emile Melbourne 
:  wrote:


: Hey Everyone,
:  
: I am currently in the process of building my first secured site.  Most 
pages
:  of the site will be behind a login page.  I'm using ColdFusion's
:  Application.cfc onRequestStart function to check if a user is logged in or
:  not.  Thats pretty much boiler plate.
:  
: My concern is how to prevent an non authorized user from accessing or
:  hotlinking to non ColdFusion page. (i.e, images, pdfs, swfs, .txt etc).
:  
: Whats the best way to ensure a user can't link directly to these items but
:  instead be redirected to login.cfm instead?
:  
: Is there a way to lock down an entire directory?
:  
: Thank you for all your help
: Emile
:  

: - 
: To unsubscribe from this list, manage your profile @ 
: http://www.acfug.org?fa=login.edituserform 
: 
: For more info, see http://www.acfug.org/mailinglists 
: Archive @ http://www.mail-archive.com/discussion%40acfug.org/ 
: List hosted by FusionLink   
: - 



: - 
: To unsubscribe from this list, manage your profile @ 
: http://www.acfug.org?fa=login.edituserform 

: For more info, see http://www.acfug.org/mailinglists 
: Archive @ http://www.mail-archive.com/discussion%40acfug.org/ 
: List hosted by FusionLink   
: - 






-- Original Message --

FROM:  "Teddy R. Payne" 
TO:
DATE:  Thu, 18 Dec 2008 13:25:15 -0500

SUBJECT:   Re: [ACFUG Discuss] Blocking a ColdFusion website's directory

Emile,
>From your description, you really need to define what "authorized" and "not 
>authorized" means.

This will help clarify to the people assisting you as to the approach they can 
suggest.

As "authorization" and "authentication" often times are used interchangeably by 
developers when in fact they represent two distinctly different topics.

Teddy R. Payne, ACCFD
Google Talk - teddyrpa...@gmail.com




On Thu, Dec 18, 2008 at 12:00 PM, Emile Melbourne  
wrote:


Hey Everyone,
 
I am currently in the process of building my first secured site.  Most 
pages of the site will be behind a login page.  I'm using ColdFusion's 
Application.cfc onRequestStart function to check if a user is logged in or not. 
 Thats pretty much boiler plate.
 
My concern is how to prevent an non authorized user from accessing or 
hotlinking to non ColdFusion page. (i.e, images, pdfs, swfs, .txt etc).
 
Whats the best way to ensure a user can't link directly to these items but 
instead be redirected to login.cfm instead?
 
Is there a way to lock down an entire directory?
 
Thank you for all your help
Emile
 

- 
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform 

For more info, see http://www.acfug.org/mailinglists 
Archive @ http://www.mail-archive.com/discussion%40acfug.org/ 
List hosted by FusionLink   
- 



- 
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform 

For more info, see http://www.acfug.org/mailinglists 
Archive @ http://www.mail-archive.com/discussion%40acfug.org/ 
List hosted by FusionLink   
- 


-
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-





Re: [ACFUG Discuss] Cross Site Forgery Question

2008-12-18 Thread Gerry Gurevich
On Thu, Dec 18, 2008 at 10:18 AM, shawn gorrell  wrote:
> Something to understand is that "action" pages are not the only pages that
> can be exploited or part of an exploit.

Frinstance?

Suppose I have a page that lists all of my users.
http://somehost/myapp/index.cfm?event=showusers

On this page, I execute a select query and display the results.  If
someone else tricks me into loading that page on my own machine using
http://somehost/myapp/index.cfm?event=showusers>, then what
is the risk?

I definitely understand the problem of not protecting the page
http://somehost/myapp/index.cfm?event=deleteuser or
http://somehost/myapp/index.cfm?event=deleteuser&userid=1.

If I'm missing something, please let me know.


-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-





Re: [ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread Teddy R. Payne
Emile,
>From your description, you really need to define what "authorized" and "not
authorized" means.

This will help clarify to the people assisting you as to the approach they
can suggest.

As "authorization" and "authentication" often times are used interchangeably
by developers when in fact they represent two distinctly different topics.

Teddy R. Payne, ACCFD
Google Talk - teddyrpa...@gmail.com



On Thu, Dec 18, 2008 at 12:00 PM, Emile Melbourne  wrote:

> Hey Everyone,
>
> I am currently in the process of building my first secured site.  Most
> pages of the site will be behind a login page.  I'm using ColdFusion's
> Application.cfc onRequestStart function to check if a user is logged in or
> not.  Thats pretty much boiler plate.
>
> My concern is how to prevent an non authorized user from accessing or
> hotlinking to non ColdFusion page. (i.e, images, pdfs, swfs, .txt etc).
>
> Whats the best way to ensure a user can't link directly to these items but
> instead be redirected to login.cfm instead?
>
> Is there a way to lock down an entire directory?
>
> Thank you for all your help
> Emile
>
>
> -
> To unsubscribe from this list, manage your profile @
> http://www.acfug.org?fa=login.edituserform
>
> For more info, see http://www.acfug.org/mailinglists
> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
> List hosted by FusionLink 
> -



-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-



Re: [ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread shawn gorrell
How does that work when you are serving a direct like to a PDF or a DOC? CF has 
nothing to do with that. 

From the original email:

My concern is how to prevent an non authorized user from
accessing or hotlinking to non ColdFusion page. (i.e, images, pdfs, swfs, .txt
etc).





From: Troy Jones 
To: discussion@acfug.org
Sent: Thursday, December 18, 2008 12:19:28 PM
Subject: RE: [ACFUG Discuss] Blocking a ColdFusion website's directory

 
Emile,
 
You can create a session variable that exists only when a user
is logged in and test for that when a call comes in to your page. For example,
in some include file or function, you could use a statement similar to this:
 



 
If the existence of variable “loggedIn” is not
present, the user will be redirected to the location you determine.
 
As far as removing anonymous access to your content, there are a
number of ways to do that. I will defer to some of the more experienced minds
on the list for that one.
 
Hope this helps,
 
Troy
Jones
Dynapp Support Team
678-528-2952
 
 
From:ad...@acfug.org
[mailto:ad...@acfug.org] On Behalf Of Emile Melbourne
Sent: Thursday, December 18, 2008 12:01 PM
To: discussion@acfug.org
Subject: [ACFUG Discuss] Blocking a ColdFusion website's directory
 
Hey Everyone,
 
I am currently in the process of building my first secured
site.  Most pages of the site will be behind a login page.  I'm using
ColdFusion's Application.cfc onRequestStart function to check if a user is
logged in or not.  Thats pretty much boiler plate.
 
My concern is how to prevent an non authorized user from
accessing or hotlinking to non ColdFusion page. (i.e, images, pdfs, swfs, .txt
etc).
 
Whats the best way to ensure a user can't link directly to
these items but instead be redirected to login.cfm instead?
 
Is there a way to lock down an entire directory?
 
Thank you for all your help
Emile
 

- 
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform 

For more info, see http://www.acfug.org/mailinglists 
Archive @ http://www.mail-archive.com/discussion%40acfug.org/ 
List hosted by FusionLink 
- 
- 
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform 

For more info, see http://www.acfug.org/mailinglists 
Archive @ http://www.mail-archive.com/discussion%40acfug.org/ 
List hosted by FusionLink 
-


-

To unsubscribe from this list, manage your profile @ 

http://www.acfug.org?fa=login.edituserform



For more info, see http://www.acfug.org/mailinglists

Archive @ http://www.mail-archive.com/discussion%40acfug.org/

List hosted by http://www.fusionlink.com

-




Re: [ACFUG Discuss] Quick MAX recap

2008-12-18 Thread Douglas Knudsen
Interesting and good to hear from you Teddy!  I run Eclipse 3.4 Ganymede
(JEE package) these days and had no issue with the update.  Have to be
careful updating the SDKs I found though.  Since FB introduced multiple SDK
support, its a good idea to keep a separate install of each SDK release.
You can put them anywhere, then just point FB to them in your preferences.
Later in your project you can switch SDKs at will in case you need to.

Something to note is that during the install, just say no to installing
FlashPlayer provided you have the latest content debugger versions
installed.

One more thing, if you updated to AIR 1.5, you have to change the 1.0 to 1.5
in the decriptor file for your application or you will get a weird
suprisingly non-indicative error. :)


peas!


Douglas Knudsen
http://www.cubicleman.com
this is my signature, like it?


On Wed, Dec 17, 2008 at 2:30 PM, Teddy R. Payne wrote:

> In reference to:
> Flex SDK 3.2 was announced
> http://www.adobe.com/devnet/flex/articles/sdk32_fb302.html
> Flex Builder 3.0.2 was announced
> http://www.adobe.com/devnet/flex/articles/sdk32_fb302.html
>
> I find that the 3.0.2 Flex Builder stand alone worked as intended.  The
> Eclipse release version for the stand alone is 3.3.1.  However, I found that
> Eclipse 3.3.1.1 had some issues with the Flex Builder 3.0.2 plug-in
> installation.  It would give compiler errors even on empty, new flex
> projects.
>
> If you are trying to upgrade and are in a pickle creating a new environment
> or you mistakenly went down the upgrade path without checking for upgrade
> issues, I recommend using the standalone Flex Builder or use the 3.3.1 build
> of the base Eclipse platform.  3.3.1 can be found at:
>
>
> http://archive.eclipse.org/eclipse/downloads/drops/R-3.3.1-200709211145/index.php
>
> I am in the process of testing 3.3.1, with the Flex Builder plug-in for
> 3.0.2.
>
> Teddy R. Payne, ACCFD
> Google Talk - teddyrpa...@gmail.com
>
>
>
> On Wed, Dec 17, 2008 at 1:18 PM, Douglas Knudsen  > wrote:
>
>>
>> Thought I'd pass along a quick list of some announcements made at MAX 2008
>> NA.  Sorry if you got duped on this, x-posted to get two groups.
>>
>> Along with the list is something new this year.  Adobe is releasing video
>> for all the sessions over time.  Check out this announcement form Ted
>> Patrick:
>> http://onflash.org/ted/2008/12/max-sessions-launched-on-adobetv.php
>>
>> MAX 2009 is to be in LA
>> Tour de Flex:  A Air app full of example Flex code http://flex.org/tour
>> AIR 1.5 was announced
>> Flex SDK 3.2 was announced
>> http://www.adobe.com/devnet/flex/articles/sdk32_fb302.html
>> Flex Builder 3.0.2 was announced
>> http://www.adobe.com/devnet/flex/articles/sdk32_fb302.html
>> Thermo was renamed to Flash Catalyst and demoed quite a bit
>> http://www.adobe.com/devnet/flex/articles/sdk32_fb302.html
>> Alchemy was announced and preview release code is available.  This enables
>> the use of C and C++ libraries in your the AVM2.  The pre-release is
>> targeting AIR for now. http://labs.adobe.com/technologies/alchemy/
>> Bolt a new ColdFusion IDE was announced.  From what little I saw I can saw
>> WOW!  http://labs.adobe.com/wiki/index.php/Bolt
>> Durango announced.  A way for end-users to customize AIR based apps
>> http://labs.adobe.com/technologies/durango/
>> Server side action script announced.  Destined to be a even bigger hit
>> then server side JavaScript was. :)
>> Flex Builder 4 'Gumbo' http://labs.adobe.com/technologies/gumbo/
>> Cocomo announced.  Build your own COnnect based apps...sounds kewl
>> http://labs.adobe.com/technologies/cocomo/
>> 64-bit Flash Player for Linux.  For those early adopter folks. :)
>> http://labs.adobe.com/technologies/flashplayer10/
>> Configurator for PhotoShop customization.
>> http://labs.adobe.com/technologies/configurator/
>> PatchPanel a way to use CS4 and Flex together
>> http://labs.adobe.com/wiki/index.php/PatchPanel
>> Wave for desktop notification type tools
>> http://labs.adobe.com/wiki/index.php/Adobe_Wave
>> More on Centaur http://labs.adobe.com/wiki/index.php/Centaur
>> Genesis knowledge-to-business-app-management
>> http://labs.adobe.com/wiki/index.php/Genesis
>> Stratus communication between Flash Player endpoints.  sounds like P2P
>> http://labs.adobe.com/wiki/index.php/Stratus
>>
>> peas!
>>
>> Douglas Knudsen
>> http://www.cubicleman.com
>> this is my signature, like it?
>>
>> -
>> To unsubscribe from this list, manage your profile @
>> http://www.acfug.org?fa=login.edituserform
>>
>> For more info, see http://www.acfug.org/mailinglists
>> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
>> List hosted by FusionLink 
>> -
>
>
>
> -
> To unsubscribe from this list, manage your profile @
> http://www.acfug.org?fa=login.edituserform
>
>

Re: [ACFUG Discuss] Quick MAX recap

2008-12-18 Thread Douglas Knudsen
so, Bolt the codename and later the official name is HomeSite with element
Hs  ???   hehe


Douglas Knudsen
http://www.cubicleman.com
this is my signature, like it?


On Thu, Dec 18, 2008 at 9:10 AM, Steve Ross  wrote:

> heh I wonder if the bolt codename is a throwback to the old allaire CF
> logo... since adobe is going crazy with the whole "elements" thing maybe
> they will bring back the lightning bolt.
>
>
> On Wed, Dec 17, 2008 at 1:18 PM, Douglas Knudsen  > wrote:
>
>>
>> Thought I'd pass along a quick list of some announcements made at MAX 2008
>> NA.  Sorry if you got duped on this, x-posted to get two groups.
>>
>> Along with the list is something new this year.  Adobe is releasing video
>> for all the sessions over time.  Check out this announcement form Ted
>> Patrick:
>> http://onflash.org/ted/2008/12/max-sessions-launched-on-adobetv.php
>>
>> MAX 2009 is to be in LA
>> Tour de Flex:  A Air app full of example Flex code http://flex.org/tour
>> AIR 1.5 was announced
>> Flex SDK 3.2 was announced
>> http://www.adobe.com/devnet/flex/articles/sdk32_fb302.html
>> Flex Builder 3.0.2 was announced
>> http://www.adobe.com/devnet/flex/articles/sdk32_fb302.html
>> Thermo was renamed to Flash Catalyst and demoed quite a bit
>> http://www.adobe.com/devnet/flex/articles/sdk32_fb302.html
>> Alchemy was announced and preview release code is available.  This enables
>> the use of C and C++ libraries in your the AVM2.  The pre-release is
>> targeting AIR for now. http://labs.adobe.com/technologies/alchemy/
>> Bolt a new ColdFusion IDE was announced.  From what little I saw I can saw
>> WOW!  http://labs.adobe.com/wiki/index.php/Bolt
>> Durango announced.  A way for end-users to customize AIR based apps
>> http://labs.adobe.com/technologies/durango/
>> Server side action script announced.  Destined to be a even bigger hit
>> then server side JavaScript was. :)
>> Flex Builder 4 'Gumbo' http://labs.adobe.com/technologies/gumbo/
>> Cocomo announced.  Build your own COnnect based apps...sounds kewl
>> http://labs.adobe.com/technologies/cocomo/
>> 64-bit Flash Player for Linux.  For those early adopter folks. :)
>> http://labs.adobe.com/technologies/flashplayer10/
>> Configurator for PhotoShop customization.
>> http://labs.adobe.com/technologies/configurator/
>> PatchPanel a way to use CS4 and Flex together
>> http://labs.adobe.com/wiki/index.php/PatchPanel
>> Wave for desktop notification type tools
>> http://labs.adobe.com/wiki/index.php/Adobe_Wave
>> More on Centaur http://labs.adobe.com/wiki/index.php/Centaur
>> Genesis knowledge-to-business-app-management
>> http://labs.adobe.com/wiki/index.php/Genesis
>> Stratus communication between Flash Player endpoints.  sounds like P2P
>> http://labs.adobe.com/wiki/index.php/Stratus
>>
>> peas!
>>
>> Douglas Knudsen
>> http://www.cubicleman.com
>> this is my signature, like it?
>>
>> -
>> To unsubscribe from this list, manage your profile @
>> http://www.acfug.org?fa=login.edituserform
>>
>> For more info, see http://www.acfug.org/mailinglists
>> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
>> List hosted by FusionLink 
>> -
>>
>
>
>
> --
> Steve Ross
> web application & interface developer
> http://blog.stevensross.com
> [mobile] (912) 344-8113 [fax] (404) 592-6885
> [ AIM / Yahoo! : zeriumsteven ] [googleTalk : nowhiding ]
>
>
> -
> To unsubscribe from this list, manage your profile @
> http://www.acfug.org?fa=login.edituserform
>
> For more info, see http://www.acfug.org/mailinglists
> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
> List hosted by FusionLink 
> -
>



-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-



RE: [ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread Troy Jones
Emile,

 

You can create a session variable that exists only when a user is logged
in and test for that when a call comes in to your page. For example, in
some include file or function, you could use a statement similar to
this:

 







 

If the existence of variable "loggedIn" is not present, the user will be
redirected to the location you determine.

 

As far as removing anonymous access to your content, there are a number
of ways to do that. I will defer to some of the more experienced minds
on the list for that one.

 

Hope this helps,

 

Troy Jones

Dynapp Support Team

678-528-2952

 

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Emile
Melbourne
Sent: Thursday, December 18, 2008 12:01 PM
To: discussion@acfug.org
Subject: [ACFUG Discuss] Blocking a ColdFusion website's directory

 

Hey Everyone,

 

I am currently in the process of building my first secured site.  Most
pages of the site will be behind a login page.  I'm using ColdFusion's
Application.cfc onRequestStart function to check if a user is logged in
or not.  Thats pretty much boiler plate.

 

My concern is how to prevent an non authorized user from accessing or
hotlinking to non ColdFusion page. (i.e, images, pdfs, swfs, .txt etc).

 

Whats the best way to ensure a user can't link directly to these items
but instead be redirected to login.cfm instead?

 

Is there a way to lock down an entire directory?

 

Thank you for all your help

Emile

 


- 
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform 

For more info, see http://www.acfug.org/mailinglists 
Archive @ http://www.mail-archive.com/discussion%40acfug.org/ 
List hosted by FusionLink   
- 




-

To unsubscribe from this list, manage your profile @ 

http://www.acfug.org?fa=login.edituserform



For more info, see http://www.acfug.org/mailinglists

Archive @ http://www.mail-archive.com/discussion%40acfug.org/

List hosted by http://www.fusionlink.com

-




Re: [ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread shawn gorrell
For things like that I normally store them outside the webroot and then serve 
them via a cfcontent in a cfm script. Instead of a link like 
http://mysite/mypdf.pdf it would be http://mysite/getfile.cfm?var=myfile.pdf.

That is very oversimplified, but captures the approach. 





From: Emile Melbourne 
To: discussion@acfug.org
Sent: Thursday, December 18, 2008 12:00:42 PM
Subject: [ACFUG Discuss] Blocking a ColdFusion website's directory


Hey Everyone,
 
I am currently in the process of building my first secured site.  Most pages of 
the site will be behind a login page.  I'm using ColdFusion's Application.cfc 
onRequestStart function to check if a user is logged in or not.  Thats pretty 
much boiler plate.
 
My concern is how to prevent an non authorized user from accessing or 
hotlinking to non ColdFusion page. (i.e, images, pdfs, swfs, .txt etc).
 
Whats the best way to ensure a user can't link directly to these items but 
instead be redirected to login.cfm instead?
 
Is there a way to lock down an entire directory?
 
Thank you for all your help
Emile
 
- 
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform 

For more info, see http://www.acfug.org/mailinglists 
Archive @ http://www.mail-archive.com/discussion%40acfug.org/ 
List hosted by FusionLink 
- 


-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-



[ACFUG Discuss] Blocking a ColdFusion website's directory

2008-12-18 Thread Emile Melbourne
Hey Everyone,

I am currently in the process of building my first secured site.  Most pages
of the site will be behind a login page.  I'm using ColdFusion's
Application.cfc onRequestStart function to check if a user is logged in or
not.  Thats pretty much boiler plate.

My concern is how to prevent an non authorized user from accessing or
hotlinking to non ColdFusion page. (i.e, images, pdfs, swfs, .txt etc).

Whats the best way to ensure a user can't link directly to these items but
instead be redirected to login.cfm instead?

Is there a way to lock down an entire directory?

Thank you for all your help
Emile



-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-



Re: [ACFUG Discuss] Cross Site Forgery Question

2008-12-18 Thread shawn gorrell
Something to understand is that "action" pages are not the only pages that can 
be exploited or part of an exploit. 





From: Gerry Gurevich 
To: discussion@acfug.org
Sent: Thursday, December 18, 2008 8:39:21 AM
Subject: Re: [ACFUG Discuss] Cross Site Forgery Question

Thanks for the info Shawn.  We've got someone looking at your
solution.  I just realized that I hadn't posted the link to the
solution that we were looking at in my original post.  here it is:
http://www.12robots.com/index.cfm/2008/8/25/Request-Forgeries-and-ColdFusion--Security-Series-9

I assume you are doing something similar.

FWIW, I'm looking into this for a colleague and what he is telling me
is that the security goons are scanning his site and labeling it
vulnerable even though the pages that they are hitting with this
vulnerability are not action pages.  Doesn't seem like a real problem
in that case to me.

On Wed, Dec 17, 2008 at 4:08 PM, shawn gorrell  wrote:
> There are ways to do it for forms and urls. In fact, I have a fully baked
> implementation of a mitigation in my Tardis framework. The approach is
> simple, have each page request a token (nonce) from a security component and
> add it as a hidden to your form, or append it to any url inside your app and
> then check on the next request to make sure that the token was passed, and
> that it has never been used before. This also prevents double-submits. Let
> me know if you'd like a go-to for the code...
>
> 
> From: Gerry Gurevich 
> To: discussion@acfug.org
> Sent: Wednesday, December 17, 2008 3:59:50 PM
> Subject: [ACFUG Discuss] Cross Site Forgery Question
>
> Sorry, I posted to the wrong list initially.  Here is my question for
> the discussion list:
>
>
> I've been asked to investigate this by someone at my company.  They
> found this link as a CF solution.  Do you all have any thoughts or
> opinions on the value of this approach?  It seems to only work for
> form submit actions.  What would you do if you had a link to an
> action page?  How would you mitigate against this type of attack?
>
> Your thoughts are appreciated.
>
>
> -
> To unsubscribe from this list, manage your profile @
> http://www.acfug.org?fa=login.edituserform
>
> For more info, see http://www.acfug.org/mailinglists
> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
> List hosted by http://www.fusionlink.com
> -
>
>
>
>
> -
> To unsubscribe from this list, manage your profile @
> http://www.acfug.org?fa=login.edituserform
>
> For more info, see http://www.acfug.org/mailinglists
> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
> List hosted by FusionLink
> -


-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-


-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-



Re: [ACFUG Discuss] Quick MAX recap

2008-12-18 Thread Steve Ross
heh I wonder if the bolt codename is a throwback to the old allaire CF
logo... since adobe is going crazy with the whole "elements" thing maybe
they will bring back the lightning bolt.


On Wed, Dec 17, 2008 at 1:18 PM, Douglas Knudsen
wrote:

>
> Thought I'd pass along a quick list of some announcements made at MAX 2008
> NA.  Sorry if you got duped on this, x-posted to get two groups.
>
> Along with the list is something new this year.  Adobe is releasing video
> for all the sessions over time.  Check out this announcement form Ted
> Patrick:
> http://onflash.org/ted/2008/12/max-sessions-launched-on-adobetv.php
>
> MAX 2009 is to be in LA
> Tour de Flex:  A Air app full of example Flex code http://flex.org/tour
> AIR 1.5 was announced
> Flex SDK 3.2 was announced
> http://www.adobe.com/devnet/flex/articles/sdk32_fb302.html
> Flex Builder 3.0.2 was announced
> http://www.adobe.com/devnet/flex/articles/sdk32_fb302.html
> Thermo was renamed to Flash Catalyst and demoed quite a bit
> http://www.adobe.com/devnet/flex/articles/sdk32_fb302.html
> Alchemy was announced and preview release code is available.  This enables
> the use of C and C++ libraries in your the AVM2.  The pre-release is
> targeting AIR for now. http://labs.adobe.com/technologies/alchemy/
> Bolt a new ColdFusion IDE was announced.  From what little I saw I can saw
> WOW!  http://labs.adobe.com/wiki/index.php/Bolt
> Durango announced.  A way for end-users to customize AIR based apps
> http://labs.adobe.com/technologies/durango/
> Server side action script announced.  Destined to be a even bigger hit then
> server side JavaScript was. :)
> Flex Builder 4 'Gumbo' http://labs.adobe.com/technologies/gumbo/
> Cocomo announced.  Build your own COnnect based apps...sounds kewl
> http://labs.adobe.com/technologies/cocomo/
> 64-bit Flash Player for Linux.  For those early adopter folks. :)
> http://labs.adobe.com/technologies/flashplayer10/
> Configurator for PhotoShop customization.
> http://labs.adobe.com/technologies/configurator/
> PatchPanel a way to use CS4 and Flex together
> http://labs.adobe.com/wiki/index.php/PatchPanel
> Wave for desktop notification type tools
> http://labs.adobe.com/wiki/index.php/Adobe_Wave
> More on Centaur http://labs.adobe.com/wiki/index.php/Centaur
> Genesis knowledge-to-business-app-management
> http://labs.adobe.com/wiki/index.php/Genesis
> Stratus communication between Flash Player endpoints.  sounds like P2P
> http://labs.adobe.com/wiki/index.php/Stratus
>
> peas!
>
> Douglas Knudsen
> http://www.cubicleman.com
> this is my signature, like it?
>
> -
> To unsubscribe from this list, manage your profile @
> http://www.acfug.org?fa=login.edituserform
>
> For more info, see http://www.acfug.org/mailinglists
> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
> List hosted by FusionLink 
> -




-- 
Steve Ross
web application & interface developer
http://blog.stevensross.com
[mobile] (912) 344-8113 [fax] (404) 592-6885
[ AIM / Yahoo! : zeriumsteven ] [googleTalk : nowhiding ]



-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-



Re: [ACFUG Discuss] Cross Site Forgery Question

2008-12-18 Thread Gerry Gurevich
Should have put a smiley on my use of "security goons".  :-)

I appreciate the value of security.  However, in this case, I believe
that they really are false positives.

BTW, I would love to have a copy of your preso.  Please send it
off-list (or post a link).  Many thanks.

On Thu, Dec 18, 2008 at 8:51 AM, Dean H. Saxe
 wrote:
> They may be doing automated scanning resulting in false positives. Have a
> manual review completed to rule out false positives.  This is a serious
> concern, however, and should be addressed in all development projects. If
> you wish I can sendiut a copy of my MAX preso where I address CSRF. Also see
> CSRFGuard from OWASP for an implementation in Java which you can reference.
>
> And us "security goons" are trying to protect those "clueless developers"
> from themselves.  ;-)
>
> -dhs
>
>
> On Dec 18, 2008, at 8:39 AM, "Gerry Gurevich" 
> wrote:
>
>> Thanks for the info Shawn.  We've got someone looking at your
>> solution.  I just realized that I hadn't posted the link to the
>> solution that we were looking at in my original post.  here it is:
>>
>> http://www.12robots.com/index.cfm/2008/8/25/Request-Forgeries-and-ColdFusion--Security-Series-9
>>
>> I assume you are doing something similar.
>>
>> FWIW, I'm looking into this for a colleague and what he is telling me
>> is that the security goons are scanning his site and labeling it
>> vulnerable even though the pages that they are hitting with this
>> vulnerability are not action pages.  Doesn't seem like a real problem
>> in that case to me.
>>
>> On Wed, Dec 17, 2008 at 4:08 PM, shawn gorrell  wrote:
>>>
>>> There are ways to do it for forms and urls. In fact, I have a fully baked
>>> implementation of a mitigation in my Tardis framework. The approach is
>>> simple, have each page request a token (nonce) from a security component
>>> and
>>> add it as a hidden to your form, or append it to any url inside your app
>>> and
>>> then check on the next request to make sure that the token was passed,
>>> and
>>> that it has never been used before. This also prevents double-submits.
>>> Let
>>> me know if you'd like a go-to for the code...
>>>
>>> 
>>> From: Gerry Gurevich 
>>> To: discussion@acfug.org
>>> Sent: Wednesday, December 17, 2008 3:59:50 PM
>>> Subject: [ACFUG Discuss] Cross Site Forgery Question
>>>
>>> Sorry, I posted to the wrong list initially.  Here is my question for
>>> the discussion list:
>>>
>>>
>>> I've been asked to investigate this by someone at my company.  They
>>> found this link as a CF solution.  Do you all have any thoughts or
>>> opinions on the value of this approach?  It seems to only work for
>>> form submit actions.  What would you do if you had a link to an
>>> action page?  How would you mitigate against this type of attack?
>>>
>>> Your thoughts are appreciated.
>>>
>>>
>>> -
>>> To unsubscribe from this list, manage your profile @
>>> http://www.acfug.org?fa=login.edituserform
>>>
>>> For more info, see http://www.acfug.org/mailinglists
>>> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
>>> List hosted by http://www.fusionlink.com
>>> -
>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe from this list, manage your profile @
>>> http://www.acfug.org?fa=login.edituserform
>>>
>>> For more info, see http://www.acfug.org/mailinglists
>>> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
>>> List hosted by FusionLink
>>> -
>>
>>
>> -
>> To unsubscribe from this list, manage your profile @
>> http://www.acfug.org?fa=login.edituserform
>>
>> For more info, see http://www.acfug.org/mailinglists
>> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
>> List hosted by http://www.fusionlink.com
>> -
>>
>>
>>
>
>
> -
> To unsubscribe from this list, manage your profile
> @http://www.acfug.org?fa=login.edituserform
>
> For more info, see http://www.acfug.org/mailinglists
> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
> List hosted by http://www.fusionlink.com
> -
>
>
>
>


-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-





Re: [ACFUG Discuss] Cross Site Forgery Question

2008-12-18 Thread Dean H. Saxe
They may be doing automated scanning resulting in false positives.  
Have a manual review completed to rule out false positives.  This is a  
serious concern, however, and should be addressed in all development  
projects. If you wish I can sendiut a copy of my MAX preso where I  
address CSRF. Also see CSRFGuard from OWASP for an implementation in  
Java which you can reference.


And us "security goons" are trying to protect those "clueless  
developers" from themselves.  ;-)


-dhs


On Dec 18, 2008, at 8:39 AM, "Gerry Gurevich"  
 wrote:



Thanks for the info Shawn.  We've got someone looking at your
solution.  I just realized that I hadn't posted the link to the
solution that we were looking at in my original post.  here it is:
http://www.12robots.com/index.cfm/2008/8/25/Request-Forgeries-and-ColdFusion--Security-Series-9

I assume you are doing something similar.

FWIW, I'm looking into this for a colleague and what he is telling me
is that the security goons are scanning his site and labeling it
vulnerable even though the pages that they are hitting with this
vulnerability are not action pages.  Doesn't seem like a real problem
in that case to me.

On Wed, Dec 17, 2008 at 4:08 PM, shawn gorrell   
wrote:
There are ways to do it for forms and urls. In fact, I have a fully  
baked
implementation of a mitigation in my Tardis framework. The approach  
is
simple, have each page request a token (nonce) from a security  
component and
add it as a hidden to your form, or append it to any url inside  
your app and
then check on the next request to make sure that the token was  
passed, and
that it has never been used before. This also prevents double- 
submits. Let

me know if you'd like a go-to for the code...


From: Gerry Gurevich 
To: discussion@acfug.org
Sent: Wednesday, December 17, 2008 3:59:50 PM
Subject: [ACFUG Discuss] Cross Site Forgery Question

Sorry, I posted to the wrong list initially.  Here is my question for
the discussion list:


I've been asked to investigate this by someone at my company.  They
found this link as a CF solution.  Do you all have any thoughts or
opinions on the value of this approach?  It seems to only work for
form submit actions.  What would you do if you had a link to an
action page?  How would you mitigate against this type of attack?

Your thoughts are appreciated.


-
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-




-
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-



-
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-






-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform


For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-





Re: [ACFUG Discuss] Cross Site Forgery Question

2008-12-18 Thread Gerry Gurevich
Thanks for the info Shawn.  We've got someone looking at your
solution.  I just realized that I hadn't posted the link to the
solution that we were looking at in my original post.  here it is:
http://www.12robots.com/index.cfm/2008/8/25/Request-Forgeries-and-ColdFusion--Security-Series-9

I assume you are doing something similar.

FWIW, I'm looking into this for a colleague and what he is telling me
is that the security goons are scanning his site and labeling it
vulnerable even though the pages that they are hitting with this
vulnerability are not action pages.  Doesn't seem like a real problem
in that case to me.

On Wed, Dec 17, 2008 at 4:08 PM, shawn gorrell  wrote:
> There are ways to do it for forms and urls. In fact, I have a fully baked
> implementation of a mitigation in my Tardis framework. The approach is
> simple, have each page request a token (nonce) from a security component and
> add it as a hidden to your form, or append it to any url inside your app and
> then check on the next request to make sure that the token was passed, and
> that it has never been used before. This also prevents double-submits. Let
> me know if you'd like a go-to for the code...
>
> 
> From: Gerry Gurevich 
> To: discussion@acfug.org
> Sent: Wednesday, December 17, 2008 3:59:50 PM
> Subject: [ACFUG Discuss] Cross Site Forgery Question
>
> Sorry, I posted to the wrong list initially.  Here is my question for
> the discussion list:
>
>
> I've been asked to investigate this by someone at my company.  They
> found this link as a CF solution.  Do you all have any thoughts or
> opinions on the value of this approach?  It seems to only work for
> form submit actions.  What would you do if you had a link to an
> action page?  How would you mitigate against this type of attack?
>
> Your thoughts are appreciated.
>
>
> -
> To unsubscribe from this list, manage your profile @
> http://www.acfug.org?fa=login.edituserform
>
> For more info, see http://www.acfug.org/mailinglists
> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
> List hosted by http://www.fusionlink.com
> -
>
>
>
>
> -
> To unsubscribe from this list, manage your profile @
> http://www.acfug.org?fa=login.edituserform
>
> For more info, see http://www.acfug.org/mailinglists
> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
> List hosted by FusionLink
> -


-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-