Is there a way to obtain a Session object other than the current one ?

S

SFX

If I have a session ID (string) can I somehow obtain the session object
associated to that ID (it exist of course) ?

I know this sounds wicked but I have a situation in which I have to make a
request from the client (IE) but for security reasons I can not access the
headers of the current request, so I can not make my new request contain the
same session ID cookie. So I was thinking that if I pass the session ID as a
parameter which I have retrieved in my aspx page, I could use this ID to
retrieve the session.

A better solution, would be to be able, from a Windows Form Control hosted
inside IE to obtain (in a managed way) the headers for the current request,
but this issue doesn't belong in this forum , I just mention it as
background information.
 
J

John Saunders

SFX said:
If I have a session ID (string) can I somehow obtain the session object
associated to that ID (it exist of course) ?

I know this sounds wicked but I have a situation in which I have to make a
request from the client (IE) but for security reasons I can not access the
headers of the current request, so I can not make my new request contain the
same session ID cookie. So I was thinking that if I pass the session ID as a
parameter which I have retrieved in my aspx page, I could use this ID to
retrieve the session.

If the session ID were not from the current request, then there would be a
security flaw.
 
D

Dale

You can create an application scope ArrayList with the Application_Start
method in the Global.asax. Then in the Session_Start add the session or
httpContext object to the ArrayList. Then the contexts of each current
request will be available to the server side code in the other sessions.

MS KB article 309018 might be a good starting point for you.

Dale Preston
MCAD, MCSE, MCDBA
 
J

John Saunders

Dale said:
You can create an application scope ArrayList with the Application_Start
method in the Global.asax. Then in the Session_Start add the session or
httpContext object to the ArrayList. Then the contexts of each current
request will be available to the server side code in the other sessions.

MS KB article 309018 might be a good starting point for you.

Note that the above KB article does _not_ talk about saving Session in
Application state.

When a page makes reference to Session, it is referring to an
HttpSessionContext object which is valid for the duration of the page
request. This object allows code in the current request to gain access to
the Session state stored for the current session. But "Session" is only an
object which gives access to the session state - it is not the session state
itself.

There is no reason to believe that storing the values of "Session" will
allow you to use those values to access the session state of multiple
sessions. It may just happen to work (more likely, it will appear to work),
but this is no guarantee that it won't break tomorrow.

Unless Microsoft provides a documented solution to this, I would stay away
from this idea like the plague.

Of course, it also has the same security problems I mentioned before, on top
of all else.
 
S

SFX

I kind of suspected that security will be an issue here but faking a session
id is not that hard, is it once I know the ID right ?

I mean one I know the ID I can create a request with the appropriate header:

Set-Cookie: ASP.NET_SessionId=<Session ID I Know>

So how will this be a security flaw ?

I can see how it can be a security flaw for a client component to get it (in
a low trust scenario) but not in the server where the code is mine.

I'm probably not seeing something obvious here, if so please enlighten me.
 
J

John Saunders

First, before I forget, you might be interested in Foiling Session Hijacking
Attempts
(http://msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/default.aspx),
which includes and explains an HTTPModule which adds a MAC code to the
session cookie and checks it on each request.
I kind of suspected that security will be an issue here but faking a session
id is not that hard, is it once I know the ID right ?

It's not _that_ hard, but keep in mind that session IDs aren't sequential
integers or something. It's not very trivial.
I mean one I know the ID I can create a request with the appropriate header:

Set-Cookie: ASP.NET_SessionId=<Session ID I Know>

So how will this be a security flaw ?

I can see how it can be a security flaw for a client component to get it (in
a low trust scenario) but not in the server where the code is mine.

This would only be the case if your code were perfect. I consider it a
security flaw if code running on behalf of one client can possibly damage
data belonging to a different client. You may not mean to do it, but it's
still possible.
I'm probably not seeing something obvious here, if so please enlighten me.

If your code does _not_ have access to other sessions state, then it's not
possible for your code to damage it.
 
S

SFX

Interesting article !
It's not _that_ hard, but keep in mind that session IDs aren't sequential
integers or something. It's not very trivial.

I wasn't talking about guessing a session ID. I was talking about once I
have the session ID, it is no big deal to send a request with it.

What I gather from your response is that this is not so much a security
issue as it is an encapsulation issue.

In other words, ASP.NET doesn't allow me to do this because I could misuse
it. Makes sense in a "perfect" world, but in the world I live in where I
can't do some of the things I need because there is still a lot of missing
functionality in the .NET framework (like in this case, the ability for a
Windows Form component running inside IE to make a request using the same
headers of the current page), this kind of "parental protection" , in my
opinion is not adequate as I now will have to come up with some workaround
that will be more prone to problems, but still, I'm going to be able to do
it (as a matter of fact I already did so it can't be a security issue, if it
was I already bypassed it, so what's the point ?). Why make me take the dirt
road ?
 
J

John Saunders

SFX said:
Interesting article !


I wasn't talking about guessing a session ID. I was talking about once I
have the session ID, it is no big deal to send a request with it.

What I gather from your response is that this is not so much a security
issue as it is an encapsulation issue.

In other words, ASP.NET doesn't allow me to do this because I could misuse
it. Makes sense in a "perfect" world, but in the world I live in where I
can't do some of the things I need because there is still a lot of missing
functionality in the .NET framework (like in this case, the ability for a
Windows Form component running inside IE to make a request using the same
headers of the current page), this kind of "parental protection" , in my
opinion is not adequate as I now will have to come up with some workaround
that will be more prone to problems, but still, I'm going to be able to do
it (as a matter of fact I already did so it can't be a security issue, if it
was I already bypassed it, so what's the point ?). Why make me take the dirt
road ?

Actually, I'm becoming concerned that you and I both are missing the obvious
by failing to learn what the problem is.

You say that you can't send using the "same headers of the current page".
But there is no such thing as the "headers of the current page". Pages don't
have headers, requests and responses do. In fact, it's likely that several
requests and responses are responsible for the objects on the page (images,
scripts, stylesheets, etc.)

Since you're talking about the Session ID, perhaps the "header" you're
referring to is the Cookies: header? That is, you'd like the Windows Forms
control to send a request using the same Cookies: header as the current
page? But there is no "Cookies: header" for the current page. It just
doesn't work that way.

So, maybe what you want is for the Windows Forms control to make a request
which would send the same cookies as those that the current page would send?
I take it that you've tried this, but the same cookies weren't sent? Well,
for one thing please tell us which cookies _were_ sent, as I don't recall it
from your earlier posts.

Second, a thought: maybe the Windows Forms control shouldn't be trying to
act like it's the page. That leaves you in the position of enumerating
everything it means to "act like the page" and hoping you find everything
that's relevant to your task, hoping to be able to get the control to act
that way, and then hoping that the task doesn't change so that you have to
change the control again (example: changing authentication requirements
might suddenly require that you access client certificates and not just
cookies). Instead, maybe you can get the page to "act like the page"?

Is it possible for a hosted Windows Forms control to raise events which are
handled in script in the same page? I know this is possible using ActiveX
controls. If so, then perhaps the event handler, in JavaScript, could do, in
the page, what you wanted the control to do, pretending to be the page.

Give it some thought. It's not too surprising that you have a problem trying
to get the control to act like the page, since it isn't actually the page.
Instead, perhaps you can get the page to be itself. Keeping the
functionality with the object to which it most naturally belongs is one
definition of encapsulation (of function).
 
D

Dale

You are correct. It talks about using application scope variables. As I
said, it was a starting place.

Dale Preston
 
S

SFX

You say that you can't send using the "same headers of the current page".
But there is no such thing as the "headers of the current page". Pages don't
have headers, requests and responses do. In fact, it's likely that several
requests and responses are responsible for the objects on the page (images,
scripts, stylesheets, etc.)

When I said "same headers of the current page" I should have said "the
headers that were sent to the server when the html page currently being
displayed inside the browser was requested". I just thought I could
abbreviate a little.
Give it some thought. It's not too surprising that you have a problem trying
to get the control to act like the page, since it isn't actually the page.
Instead, perhaps you can get the page to be itself. Keeping the
functionality with the object to which it most naturally belongs is one
definition of encapsulation (of function).


I have (given it a lot of thought !). I think you are assuming a little too
much based just in my posting, which I made as concrete as possible in hopes
of getting a concrete answer.

Let me try to explain the headers ordeal in more detail.

Imagine you have a page like this:

<BODY>
<img src="/MyImage.gif"/>
</BODY>

When a request for MyImage.gif is sent to the server, ALL OF THE RELEVANT
headers such as cookies, user, user agent, etc. are sent JUST as when the
page containing this image tag was requested (more or less, anyways, new
cookies could have been created in the current request, but that's too much
detail for this discussion).

This is all I want. I (the client control) want to be like the <img> tag.
The <img> is not the page an yet it makes the request the way I want to make
Is it possible for a hosted Windows Forms control to raise events which are
handled in script in the same page?

No. Not managed anyways, a call to explorer (to execute the script) is
considered un-managed. In an ActiveX control, there is absolutely no
problem, I can get a hold of the Browser interface and tell it to make the
request for me instead of doing it myself, this way I don't have to worry
about headers. Unfortunately, there is nothing similar in .NET. (I can do it
unmanaged but then my control would require full-trust which misses the
point of .NET controls).

Anyways, I did not intend to go into this discussion about headers and
client controls in this posting for two reasons:

1) I already know pretty much what can and can't be done.
2) This is an ASP.NET forum, not Windows Form.

I just fell compelled to explain the reason for my need.

My original question remains unanswered:

Can I get a session object for a session other than the current assuming I
have the id for such session.

If the answer is no, why ?

It was nice talking to you.
 
D

Dale

Go back to my first reply. I have done it that way successfully.

Dale Preston
MCAD, MCSE, MCDBA
 
J

John Saunders

I have (given it a lot of thought !). I think you are assuming a little too
much based just in my posting, which I made as concrete as possible in hopes
of getting a concrete answer.

Let me try to explain the headers ordeal in more detail.

Imagine you have a page like this:

<BODY>
<img src="/MyImage.gif"/>
</BODY>

When a request for MyImage.gif is sent to the server, ALL OF THE RELEVANT
headers such as cookies, user, user agent, etc. are sent JUST as when the
page containing this image tag was requested (more or less, anyways, new
cookies could have been created in the current request, but that's too much
detail for this discussion).

This turns out not to be the case, and is perhaps the basis of your
misunderstanding.

When the request for MyImage.gif is sent to the server, it is sent with
headers appropriate for MyImage.gif. These will typically be similar to
those sent when the page was requested, but there is no single rule which
says that they will be the same, or even similar.

Some potential differences are that the "current page" may have been sent as
the result of a POST, yet the image will be requested via a GET. Also, the
cookie headers may be different. Although "/MyImage.gif" is in the same
domain as the current page, it may not be in the same path, and path is one
of the things which determines whether a client sends a given cookie to the
server on a particular request. Also, some cookies may have expired since
the initial request.

I suggest that you go through the entire list of HTTP request headers and
determine which ones would definitely be the same between the page request
and the image request. That list will contain fewer headers than you might
think.
This is all I want. I (the client control) want to be like the <img> tag.
The <img> is not the page an yet it makes the request the way I want to make
it. So I'm not trying to be the page, if anything I'm trying to be an
tag. That's not too much to ask, is it ?

As above, yes, it is.

Another difference. The users browser (presumably) made the request for the
current page and will make the request for the image. Yet, you want your
control to make the request on its own. I suggest you find a way to have
your control ask the page to make a request on its behalf, thus making it
more like the image tag, which does not make the request on its own.

My original question remains unanswered:

Can I get a session object for a session other than the current assuming I
have the id for such session.

If the answer is no, why ?

The answer is, "no", and "because it's not made to solve that problem".

BTW, take a look at "Host Secure, Lightweight Client-Side Controls in
Microsoft Internet Explorer"
(http://msdn.microsoft.com/msdnmag/issues/02/01/UserCtrl/default.aspx),
which, among other things, shows how a hosted Windows Forms control can
raise events.
 
S

SFX

Thank you Dale, I understood your suggestion and I have it working that way
now (thanks to you), the rest of the thread was just "educational". I wanted
to know why I couldn't just get the Session object directly from the system.
 
S

SFX

Also, the
cookie headers may be different. Although "/MyImage.gif" is in the same
domain as the current page, it may not be in the same path, and path is one
of the things which determines whether a client sends a given cookie to the
server on a particular request. Also, some cookies may have expired since
the initial request.

I didn't think of these. I realize now that this can get very complicated.
I suggest you find a way to have
your control ask the page to make a request on its behalf, thus making it
more like the image tag, which does not make the request on its own.

This would actually be IDEAL ! This is what I do in the ActiveX world.
Maybe we can both lobby MS to include this feature. In Whidbey they have
included a managed interface to the browser, I know it has a Navigate method
(loads the url in the browser) but I don't think it has a download method, I
will check. Unfortunately my clients can't wait for Whidbey :-(
BTW, take a look at "Host Secure, Lightweight Client-Side Controls in
Microsoft Internet Explorer"
(http://msdn.microsoft.com/msdnmag/issues/02/01/UserCtrl/default.aspx),

Yes. I already do this to throw events. The only problem, again, Full-Trust
is required, when the .NEF Framework calls IE it does not distinguish it
from any other unmanaged assembly, there goes the "Secure" part (Jay
mentions this at the end of the Handling Events section). That's another one
in my "whish-list", but this one hasn't made it to Whidbey , yet.

I guess, for now, this is just something I'm going to have to live with,
I'll tell my users about the suggestion Dale gave me or to give full control
to my assembly (which I know is impossible for most of them) until better
support for IE hosted controls is provided by the framework. At least they
will have options.


Thanks for the brainstorm !
 
J

John Saunders

Yes. I already do this to throw events. The only problem, again, Full-Trust
is required, when the .NEF Framework calls IE it does not distinguish it
from any other unmanaged assembly, there goes the "Secure" part (Jay
mentions this at the end of the Handling Events section). That's another one
in my "whish-list", but this one hasn't made it to Whidbey , yet.

I guess, for now, this is just something I'm going to have to live with,
I'll tell my users about the suggestion Dale gave me or to give full control
to my assembly (which I know is impossible for most of them) until better
support for IE hosted controls is provided by the framework. At least they
will have options.

BTW, from the article it looks like you don't need full trust, only
"unmanaged code execution permissions", which can be given out to your
control alone.
 
S

SFX

For all practical purposes, "unmanaged code execution permissions" is full
trust, once a control can run unmanaged code, if it wanted to, it could
format your hard drive, read all your cookies and files, infect your
computer with a virus, etc.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top