sessionState cookieless = "true" Sicherheitslücke?

[Patrick Sack]

Hallo,
<br>
<br>- sessionState cookieless = "true" wurde eingestellt
<br>
<br>- Loginseite wird aufgerufen
<br>- die folgende URL erscheint in der Browser URL (Adress) Zeile:
https://www.test.com/test/(5fr35wm2xrmd1ze4oge2ev55)/login.aspx
<br>
<br>- Nun drückt man auf Favorit hinzufügen und diese Adresse wird gespeichert.
<br>
<br>- nun kann man über Favorit immer wieder die LoginSeite aufrufen, jedoch erhält man nie mehr eine andere ID als die im Link gespeicherte. D.H. der IIS verwendet eine ID und erstellt dazu eine neue Session, die zum einen schon beendet sein kann und somit gar nicht mehr existiert. Eigentlich sollte er doch immer eine neue ID kreieren.
<br>
<br>Wie kann man den IIS dazubringen nur ID'S zu akzeptieren, die er selbst erstellt hat und die nicht schon wieder beendet wurden?
<br>
<br>Verschiedenste versuche sind leider fehlgeschlagen. Auch ein redirect über eine andere Seite mit anschließendem abfragen der zuvor geladenen URL schlug auf dem produktiv system fehl, da hier die IIS Anforderungen über einen apache "geroutet" werden.
<br>
<br>Die Frage ist wie kann man aus ASP heraus oder direkt am IIS dem selbigen mitteilen, das von URLs gelieferte Session ID's nicht für eine neue Session benutzt werden können/dürfen?
<br>
<br>Vielen Dank!
<br>
<br>mfg
<br>PS

[André Schubert]

Das ist normal so, dass der IIS einen neue Session mit der SessionID aus der gespeicherten URL aufmacht.
Dagegen kann man nichts machen.

MfG

André

http://www.dotnetfriends.de - Das Forum für ASP.Net,C# und VB.NE

[Patrick Sack]

Hallo André,
<br>
<br>vielen Dank für die Antwort.
<br>
<br>>Dagegen kann man nichts machen.
<br>
<br>Das ist schlecht, wenn dem so ist, ist dies eine gravierende Sicherheitslücke, da jeder, der die SessionID aus dem Favorit gelesen hat, prinzipiell die Möglichkeit hat die Kennwort-Authorisierung aus zu tricksen.
<br>
<br>mfg
<br>P

[Steffen Hübner]

kannst du das genauer erklären? ich arbeite auch mit dem cookieless-urls...

steffe

[Patrick Sack]

Hallo Steffen,
<br>
<br>angenommen du hast wie oben beschrieben deine Anwendung zu den Favoriten gespeichert, und jemand mit krimineller Energie hat Zugriff zu deinen Favoriten erlangt und die folgende <br>Zeile erhalten:
<br>
<br>https://www.test.com/test/5fr35wm2xrmd1ze4oge2ev55)/login.aspx
<br>
<br>Nun muß dieser jemand lediglich alle 5 Minuten den folgenden Link aufrufen:
<br>https://www.test.com/test/5fr35wm2xrmd1ze4oge2ev55)/default.aspx
<br>
<br>In der Regel ist es so, wenn du nicht angemeldet bist über deinen Favorit, wird der gewisse jemand auf die Seite
<br>
<br>https://www.test.com/test/5fr35wm2xrmd1ze4oge2ev55)/login.aspx
<br>
<br>Verwiesen, da noch keine Session zu dieser ID Existiert.
<br>
<br>Aber sobald du dich erfolgreich über deinen Favoriten angemeldet hast wird die standard default.aspx angezeigt, da zu der ID im Link eine Session existiert.
<br>
<br>mfg
<br>P

[Steffen Hübner]

oha! das muss ich mal ausprobieren! danke für den hinweis!

steffe

[Steffen Hübner]

was ist, wenn ich beim start einer session mir in einer statischen hashtable die session-id merke und dazu die ip-adresse?
und bei jedem neuen seitenaufruf schaue ich, ob die id existiert und ob die ip stimmt? das kann ich ja machen...

aber
a) weiss ich nicht, wie gut man ip-nummern fälschen kann
b) was ist bei proxies? hab nix gefunden wie bei PHP mit forwarded-ip

steffe

[holster]

Der IIS legt die Session nicht aufgrund der Session-ID im URL-String an, sondern er mappt den Request auf eine Session, die im ASP.NET unter der ID besteht - wenn sie nicht inzwischen abgelaufen ist.

Genau das tut sie aber, wenn man ASP.NET richtig konfiguriert und die Session z.B. nach einer halbe Stunde beendet, sofern kein Request erfolgt ist. Dann erhält der Browser eine entsprechende Fehlermeldung. Der Mechanismus ist insoweit sicher.

Klau

[Steffen Hübner]

jo, das ist schon klar! die session muss noch existieren.

aber wenn ich zum beispiel jemanden meine url schicke (mit id) und dieser sich sofort einloggt, kommt er ohne login rein. nun kannst du mir sagen, selber schuld. und bei jemanden, dem ich die url schicke, habe ich wohl auch kein problem - aber nichts kann man leichter lesen als fremde emails...

steffe

[holster]

Die Session sagt bei ASP.NET nix über den Login-Status aus.

Wenn Forms-Authentication verwendet wird, dann befindet sich die Information darüber, ob ein Benutzer angemeldet ist, im Authentication-Cookie und wird (hoffentlich) beim Seitenaufbau mit Request.IsAuthenticated abgefragt. Selbst wenn jemand die Session-ID klaut, kommt er trotzdem nicht rein.

Ansonsten sollte man folgende Dinge machen:

- Die Session-ID nicht im URL-String übergeben sondern im Cookie speichern

- Die Session-Expiration relativ kurz einstellen

- Die Login-Expiration auf den kürzestmöglichen Zeitraum setzten, den die Benutzer eben noch ertragen :-)

- Beim Logout die Session-Variable mit Session.Clear löschen oder Sesion.Abandon beenden.

Klau

[Steffen Hübner]

jupp! da gebe ich dir recht!

allerding benutze ich keine cookies! ich habe eine cookieless authentication eingebaut - muss man zwar ein wenig basteln, weil MS das bei den web forms standardmässig nicht unterstützt, aber funzt gut.

steffe

[holster]

Wie erkennst Du denn, das der Request von einem authentifizierten Benutzer stammt? Irgendwo musst Du die Information ja speichern.

Klau

[Steffen Hübner]

die information hab ich in der session!

und in der global.asax hab ich einen ereignis-handler, der bei jedem request aufgerufen wird - dort checke ich, ob mein CustomPrincipal schon vorhanden ist...

steffe

[holster]

In dem Fall ist die vom Browser übertragene Session-ID gleichzeitig die Information darüber, dass dieser Request authentifiziert ist.

Anders ausgedrückt: Jeder Request von irgendeinem Browser, der sich auf diese ID bezieht, gilt in Deiner Anwendung automatisch als authentifiziert, solange vorher von einem beliebigen Browser aus eine Anmeldung erfolgreich war.

Wenn dann die Session-ID noch unverschlüsselt in der URL übertragen wird, dann ist das in der Tat ein massives Sicherheitsrisiko.

Klau

[Steffen Hübner]

jupp!

die frage ist nun: was tun, wenn man cookieless arbeiten will?

steffe