Security hole with ASP.NET URL rewriting?

From: Ulrich Margull (
Date: 10/08/02

From: "Ulrich Margull" <>
Date: Tue, 8 Oct 2002 09:55:17 +0200


we use .NET and the URL rewriting mechanism
for keeping the sessions. In the session, a user can log
in our application, and we store the login-information
in the session variable. Principally, no cookies involved.

BTW, its a propietary video/audio streaming portal,
where the player is an ActiveX object thats placed
inside a View.aspx page.

Now here is our problem: So people "steal" our web
Viewer (the View-aspx page), put it in a small or
hidden frame, and have a audio streaming without
our name appearing. This is bad, but our real
problem is the following:

Sometimes they "steal" the page with a session id, like
this: <iframe width=100 height=100
Then *every* user, that loads the above page, will be in the same
session ID (namely u3dz0n55ab3iddbrlhypys55). If one of
these users logs itself in, all others are logged in, too!
Now we sometimes use cookies to automatically log
people in, and if one of these people hits such a page,
all others are logged in under the same name.
We had strange identity problems for the last weeks, and
its caused by multiple-usage of URL session ids.

As far as I see it, its a flaw of the ASP.NET Session mechanism:
1. The ASP.NET creates a new session and a new session ID.
2. The Session times out / ends at some point. The Session ID is
    no longer used.
3. Now somebody comes with the *old* already abandoned
   session ID. ASP.NET happily starts a new session, and
  *re-uses the old session-ID*.
4. This means, if somebody puts up a link with the session ID,
   all users will end up in the session ID. If the link is obfuscated
   by frames, etc. all users end up in the same session, without
   knowing. Since a session might hold sensible data, these can
   be spied out easily.
5. A simple workaround would be the following:
    - when a new session starts, and an old session id is sent,
       the server *does not use* the old session id, but creates
       a new session id, as he does when no session id is provided.

Is this problem known? Is this a security flaw, as I outlined above?
What workaround can I use now?


Uli Margull

Bitte senden Sie Emails an "Nachname"@"Nachname".de
Please send emails to "my last name"@ "my last name".de

Relevant Pages