server transfer to another site

[barryfz]

I need to be able to move from one web app on my server to another on the
same server and preserve the session state. I have played with
server.transfer but I get an error saying I can't do this. How can I
accomplish this. I don't think redirects with session state being passed in
the url makes any sense from a security standpoint.

 

[Raymond]

How about a secure form post then to a page in the
other web app, carring session info and re-establishing
it?

 

[Terry Burns]

Server.Transfer does not affect the Session state as far as I know. Is
session what you meant ?. You can set a session var in one form, transfer to
form 2 and the variable will still be there in session.

--
Terry Burns
http://TrainingOn.net

How about a secure form post then to a page in the
other web app, carring session info and re-establishing
it?

 

[Guest]

What you are trying to do is unnatural. The main reason separate
applications exist is so they can maintain separate application state.

That said, there are ways to do it but they are not simple if you're dealing
with very much data. Its a very manual process to pass data between
applications. You can pass data via querystring or a common backend
database, etc.

 

[barryfz]

Terrry

I need to transfer to a page in a different site. I am getting an error
saying I can't do that in server.transfer. Maybe I am doing something wrong.

Barry

Server.Transfer does not affect the Session state as far as I know. Is
session what you meant ?. You can set a session var in one form, transfer
to form 2 and the variable will still be there in session.

 

[Raymond]

Probably not if the domain is different. There may be
other ways to do it, but the simplest way is to redirect
via a form post and re-establish session using form post
data.

 

[Guest]

Barry,
As Steve and others may have pointed out, Server.Transfer only is designed
to work within the current IIS application.

What you would need to do if you do not want to pass session information on
the querystring or as hidden formfields is to set up a custom database or
other persistent storage mechanism to store and then retrieve by
"customSessionId" the information you need once the redirect lands on the new
site.
Peter

 

[barryfz]

Raymond,

I am not sure what you mean by domain? While these are different apps they
are on the same server, just different sites.

If I pass this a part of post don't I then allow someone to hijack the data
being posted and use it to gain access?

Barry

 

[barryfz]

Steve,

I really just need to pass the authentication.

Barry

 

[Terry Burns]

Sorry, I misread you. This is correct, you cannot use server transfer to a
different site. Applications are isolated from each other and so a session
in one does not relate to a session in another. One way is to preserve the
session valriables in an SQL database but you need to serialie them for
storage and de-serialize them on retreival.

 

[Terry Burns]

If Authentication is all you need to worry about, then consider using
Windows Integrated Security, this way you wont need a username and password.
This is no use of course if the site is an internet site.

 

[Adrian Parker]

You could always pass an encrypted string across.

-Adrian

 

[Raymond]

Default Sessions objects use cookies, which
are associated by URL domains, not server, on the client.
And each site on a server works in a different appdomain, so
the session objects aren't normally visible across those
appdomains even if you somehow figured out the client side
association.

If you pass session state info via a secure form post
then it's very secure. You're going to have to pass some
sort of associating data anyway, either by URL or form post.
There is no escaping that.

 

[barryfz]

Raymond,

Thanks for the feedbackon this. Can you clarify what you mean by a ":secure
post"?

Barry

 

[Raymond]

Form post via https. Passing all the session data that way
is the easiest. If SSL is not available, then consider passing
encrypted values using http form post and then decrypting on the
other end before re-creating the same session.

 

[barryfz]

That sounds feasible. What is "customSessionID"?

 

[Steven Cheng[MSFT]]

Hi Barry,

As for Server.Transfer, it can only work within a single ASP.NET
application but not across mutiple application or server bounary. Also,
session State is also not able to share between multiple applications. In
ASP.NET 2.0, there does provides interfaces for us to create customized
session storage provider(customzied session state httpmodule), however
that'll require quite complex work:

#Implementing a Session-State Store Provider
http://msdn2.microsoft.com/en-us/library(d=robot)/ms178587.aspx

BTW, if your applications are using ASP.NET forms Authentication and want
to share the forms authentication's autentication ticket(cookie based)
across multiple applications, you can have a look at the following
reference:

#How To Share Authentication Cookies across ASP.NET V1.1 and ASP.NET V2.0
Applications
http://weblogs.asp.net/scottgu/archive/2005/12/10/432851.aspx

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[barryfz]

Thanks Raymond,

I can do that, but couldn't someone grab the post and resend it from their
own brower and thus hijack the session?

Barry

 

[barryfz]

Thanks Steven,

I think this is what I am looking for.

Barry

 

[Raymond]

Well, what's to prevent them from doing that now
with the sessions you have going now from the same
site? The transfer as I outlined doesn't add any new
vulnerability. If a hijaking vulnarability already exists
for the sessions on the same site, it'll also exist for the
cross-site transfer.