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).