M
Martin
Hi,
I have a requirement for an ASP.Net application with both secure and
insecure pages. I want to have ASP.Net sessions used/shared by both types
of page.
The current implementation has used 2 ASP.Net applications one secure and
one insecure, to avoid the insecure session ID (cookie based) being hijacked
and used to access secure https pages. This creates a number of headaches
for normal application development, and I can't believe that with a
technology as mature as http(s) sessions, that there isn't a more elegant
solution.
In an ideal world I want the application to also handle the cookie less
scenario.
In both cookie and cookie less scenarios, I would imagine a solution that
works something like the following (but I can't see any hint this has been
implemented in ASP.Net).
There should be 2 session IDs, one for insecure sessions and one for secure
sessions.
The insecure session ID is passed to both secure and insecure pages
The secure session ID is passed only to secure pages
(So far, I know cookies are capable of this behaviour with the secure cookie
property)
Now, ASP.Net should expose a unified Session object as a set of properties,
some properties associated with the secure session, and some associated with
the insecure session.
Which properties belong to which session?
When a new property is set, it should be associated with the secure session
if it is set in a secure page, and associated with the insecure session if
set in an insecure page.
On secure pages, both secure and insecure properties are accessible. (The
accessor should not have to care which type of property they are accessing)
On insecure pages, only insecure properties should be accessible.
Obviously a careless programmer might set a sensitive property on an
insecure page, thus making that data open to a hack attack, but it is always
possible to write buggy code.
This is just an outline of my thoughts/expecations on this. Am I living in
a dream world, or does this actually exist? What is the design pattern for
secure/insecure ASP.Net applications, that avoids sessionID hijacking.
Thanks in advance.
Martin
I have a requirement for an ASP.Net application with both secure and
insecure pages. I want to have ASP.Net sessions used/shared by both types
of page.
The current implementation has used 2 ASP.Net applications one secure and
one insecure, to avoid the insecure session ID (cookie based) being hijacked
and used to access secure https pages. This creates a number of headaches
for normal application development, and I can't believe that with a
technology as mature as http(s) sessions, that there isn't a more elegant
solution.
In an ideal world I want the application to also handle the cookie less
scenario.
In both cookie and cookie less scenarios, I would imagine a solution that
works something like the following (but I can't see any hint this has been
implemented in ASP.Net).
There should be 2 session IDs, one for insecure sessions and one for secure
sessions.
The insecure session ID is passed to both secure and insecure pages
The secure session ID is passed only to secure pages
(So far, I know cookies are capable of this behaviour with the secure cookie
property)
Now, ASP.Net should expose a unified Session object as a set of properties,
some properties associated with the secure session, and some associated with
the insecure session.
Which properties belong to which session?
When a new property is set, it should be associated with the secure session
if it is set in a secure page, and associated with the insecure session if
set in an insecure page.
On secure pages, both secure and insecure properties are accessible. (The
accessor should not have to care which type of property they are accessing)
On insecure pages, only insecure properties should be accessible.
Obviously a careless programmer might set a sensitive property on an
insecure page, thus making that data open to a hack attack, but it is always
possible to write buggy code.
This is just an outline of my thoughts/expecations on this. Am I living in
a dream world, or does this actually exist? What is the design pattern for
secure/insecure ASP.Net applications, that avoids sessionID hijacking.
Thanks in advance.
Martin