Groups | Blog | Home
all groups > iis security > september 2004 >

iis security : Cold Fusion SSO and File Access



Jeff Ebeling
9/7/2004 9:28:22 AM
Hi all,

I am a security engineer (new to the newsgroup) who just completed an Cold
Fusion application security assessment. I found that the "application" was
really a portal to multiple CF applications with single signon (SSO)
implemented in CF. The web server is obviously IIS.

The CF SSO implementation prevents access to (execution of) any files with
the .cfm extension without valid CF cookies that are established via a CF
login page. However, files used by, and linked from, the served pages
without the .cfm extension are served by IIS regardless of whether or not
the CF cookies associated with SSO are valid. All this is expected behavior,
but creates a serious security hole as any non-CF files can be accessed
without logging in as long as the client knows the URL of the resource.

I'm trying to find a good recommended solution that does not require
extensive rewriting of all of the application code or require the user to
authenticate more than once. I know that IIS can be set to protect
individual files and directories, but to do so would require that the user
authenticate to the windows server. I would much prefer a solution that only
required modification of the CF login script. Is there some way to have the
CF login script so the authentication and then set a non-persistent cookie
on the client that IIS will then use for client authorization prior to
serving files that are access contolled, without requesting that the user
manually authenticate? Alternatively, can IIS be setup to redirect to a Cold
Fusion script to serve pages with specific extensions or in specific
directories?

There has got to be some easy way to do this, but I have yet to discover a
solution. I would think that most CF apps running on IIS that use CF based
authentication for security have the same flaw.

My apologies, if this has been covered previously.

Thanks,

Jeff

Roger Abell
9/7/2004 7:57:17 PM
The basic problem with that design is that the CF based
SSO is private to the CF application, but they have not
contained all content within the CF app.
They could, I would think with modest redesign, make a
containment page, a cfm so that it is within the CF SSO
space, and this page is then used to display all of the
currently non-cfm pages, with the same being renamed
to some extension that IIS will not recognize/serve.
This approach has obvious problems if the non-cfm pages
are such as .asp, .doc, .pdf, etc..
As I see it, this is a fundemental app design error, and
the only real way to correct is where the error is.
--
Roger
[quoted text, click to view]

AddThis Social Bookmark Button