Secure an ASPX page

[moondaddy]

using asp.net 2.0, I have an interesting requirement. I have an aspx page
which I need to prevent someone from opening by calling it's URL. Here's
the scenario:

I have an aspx page which is used to host html help documentation that was
generated from a help authoring tool. The information in this documentation
is sensitive and the only people allowed to see it are the users of the
application (a winforms 1.1 app). I replaced the main page of the help
documentation (which was a frames page) with this aspx page so I could
secure it.

Currently to secure this aspx frame page, the winforms app calls a web
service which generates a GUID and caches it on the server for 10 seconds
and returns the GUID to the winform client. The winform client calls the
aspx frame page via its URL and passes in the GUID as a parameter. On the
server side, if it can find the GUID, the page will open as expected. If it
doesn't find the GUID, it redirects to an error page. This way you can
never open the page by just entering its URL into a browser.

This works good for allowing only the winforms app to open the help
documentation. However, I have 2 problems.

1) the help documentation has tons of JavaScript that executes when the
main frame page is called up and passing in a GUID messes things up as it
expects No parameters, or special parameters (and not a GUID).

2) for some reason, this page pulls up incredibly slow from the remote
server which I have not figured out yet. It doesn't load with a lot of
overhead( pages, images, etc.). It loads fast on my local machine. If I
post the help documentation using a html main page and not the aspx page and
simply call it up via its URL (as normal) it loads fast. Therefore, I think
the problem has something to do with my code and or the JavaScript which
doesn't like the GUID.

My code is very minimal and using the same code in other scenarios runs
lightning fast.

so I was going to try: calling a blank page and pass in my GUID parameter.
if the server finds the GUID in cache, then do a redirect to the aspx frame
page which contains the help documentation. If I use this method, the page
is now left unsecured as you could now call it from a URL. is there a way
to force a page to only be called from a redirect?

Can anyone recommend a better way to secure this aspx frame page?

Thanks.

 

[Riki]

using asp.net 2.0, I have an interesting requirement. I have an aspx
page which I need to prevent someone from opening by calling it's
URL. Here's the scenario:

I have an aspx page which is used to host html help documentation
that was generated from a help authoring tool. The information in
this documentation is sensitive and the only people allowed to see it
are the users of the application (a winforms 1.1 app). I replaced
the main page of the help documentation (which was a frames page)
with this aspx page so I could secure it.

Currently to secure this aspx frame page, the winforms app calls a web
service which generates a GUID and caches it on the server for 10
seconds and returns the GUID to the winform client. The winform
client calls the aspx frame page via its URL and passes in the GUID
as a parameter. On the server side, if it can find the GUID, the
page will open as expected. If it doesn't find the GUID, it
redirects to an error page. This way you can never open the page by
just entering its URL into a browser.
This works good for allowing only the winforms app to open the help
documentation. However, I have 2 problems.

1) the help documentation has tons of JavaScript that executes when
the main frame page is called up and passing in a GUID messes things
up as it expects No parameters, or special parameters (and not a
GUID).
2) for some reason, this page pulls up incredibly slow from the
remote server which I have not figured out yet. It doesn't load with
a lot of overhead( pages, images, etc.). It loads fast on my local
machine. If I post the help documentation using a html main page and
not the aspx page and simply call it up via its URL (as normal) it
loads fast. Therefore, I think the problem has something to do with
my code and or the JavaScript which doesn't like the GUID.

My code is very minimal and using the same code in other scenarios
runs lightning fast.

so I was going to try: calling a blank page and pass in my GUID
parameter. if the server finds the GUID in cache, then do a redirect
to the aspx frame page which contains the help documentation. If I
use this method, the page is now left unsecured as you could now call
it from a URL. is there a way to force a page to only be called from
a redirect?

There is.
Put the entire content of the help page in a panel, and only make it
visible like this (VB.NET):
If (Request.UrlReferrer.RawUrl = "url of first page here") Then
pnlContent.Visible = True
Else
pnlContent.Visible = False
End If

 

[Jesse Houwing]

* moondaddy wrote, On 14-7-2007 1:25:

using asp.net 2.0, I have an interesting requirement. I have an aspx page
which I need to prevent someone from opening by calling it's URL. Here's
the scenario:

I have an aspx page which is used to host html help documentation that was
generated from a help authoring tool. The information in this documentation
is sensitive and the only people allowed to see it are the users of the
application (a winforms 1.1 app). I replaced the main page of the help
documentation (which was a frames page) with this aspx page so I could
secure it.

Currently to secure this aspx frame page, the winforms app calls a web
service which generates a GUID and caches it on the server for 10 seconds
and returns the GUID to the winform client. The winform client calls the
aspx frame page via its URL and passes in the GUID as a parameter. On the
server side, if it can find the GUID, the page will open as expected. If it
doesn't find the GUID, it redirects to an error page. This way you can
never open the page by just entering its URL into a browser.

This works good for allowing only the winforms app to open the help
documentation. However, I have 2 problems.

1) the help documentation has tons of JavaScript that executes when the
main frame page is called up and passing in a GUID messes things up as it
expects No parameters, or special parameters (and not a GUID).

2) for some reason, this page pulls up incredibly slow from the remote
server which I have not figured out yet. It doesn't load with a lot of
overhead( pages, images, etc.). It loads fast on my local machine. If I
post the help documentation using a html main page and not the aspx page and
simply call it up via its URL (as normal) it loads fast. Therefore, I think
the problem has something to do with my code and or the JavaScript which
doesn't like the GUID.

My code is very minimal and using the same code in other scenarios runs
lightning fast.

so I was going to try: calling a blank page and pass in my GUID parameter.
if the server finds the GUID in cache, then do a redirect to the aspx frame
page which contains the help documentation. If I use this method, the page
is now left unsecured as you could now call it from a URL. is there a way
to force a page to only be called from a redirect?

Can anyone recommend a better way to secure this aspx frame page?

Thanks.

There's one option that comes to mind other than password protecting the
folder and/or using a SSL Client Certificate.

You could write a httpmodule/httphandler which handles all requests to
all types. Register that in the web.config. Now when the first request
comes in verify the GUID and set a boolean flag in the session to allow
this session. On every request that comes in with no guid in the url,
check the session for that same boolean. If it's true, let it pass, if
it's false throw a security exeption or send your own Access Denied
error. You need to configure IIS to forward all requests through ASP.NET
for this to work.

You could potentionally do this from the Global.asax as well after
setting up IIS correctly, but the module or handler approach is the
official way to go about these kind of issues.

Jesse

 

[Steven Cheng[MSFT]]

Hi Moondaddy,

I think Riki and Jesse's suggestion are reasonble.

As Riki has mentioned, the "Request.UrlReferrer" property can give you the
information on previous page's url(which redirect the request to current
page), it is a standard http header.

And as Jesse has suggested, you can also consider implement the cached
ticket/identity in session state, thus, in your main document page, you can
check session state to verify whether the client user has ever first been
to the entry page(the blank page). How do you think?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[timmy123 via DotNetMonster.com]

Hi,

The Global.asax file checks the path of each request made to the site. The
Global.asax file handles the BeginRequest that is raised whenever someone
requests a page from the site.When appropriate, we can use the RewritePath
method is used to redirect a page request to some page.
As other people said, creating a HTTP module is better solution. An HTTP
module is a class that is executed whenever a request is made for an ASP.net
page.

HTTP handlers perform many of the same functions in the ASP.net framework as
ISAPI extensions performed in traditional Active Server Pages programming.

Books for programmers in Visual basic 2005 and Csharp 2005
http://www.vkinfotek.com