Session-Riding

[Marc]

Ich habe gerade davon gehört, aber das Thema war ein anderes und ich befürchte, da sieht es niemand...

Was genau passiert beim Session-Riding? Ich bin aus den Artikeln nicht ganz schlau geworden..

Soweit ich es verstanden habe, kann der Angreifer dabei alles in einer Webanwendung steueren, was auf per URL übergebenen Variablen beruht, oder?

[dummer Name]

Guten Abend!

Was genau passiert beim Session-Riding?

Als Session (Sitzung) bezeichnet man den Zeitraum zwischen zwei Ereignissen, bei dem eine Reihe mehr oder weniger zusammenhängender Aktionen durchgeführt werden. Die abgrenzenden Ereignisse können die An- (Login) und Abmeldung (Logout) bei einem Dienst sein, die zusammenhängenden Aktionen können das Aufrufen Deiner Kundendaten, das Ansehen einer Produktseite und das Aufrufen, Ausfüllen und Absenden der Bestellung sein.

Was genau passiert beim Session-Riding?

Stell' Dir vor, Du hast Dich gerade auf den Webseiten des Auktionshauses Müller mit Name und Passwort eingeloggt, weil Du die von Dir beobachteten Auktionen durchgucken wolltest.
Nachdem das erledigt ist, blätterst Du noch ein wenig durch das restliche Angebot und stößt dabei auf einer Seite über ein interessantes, nur leider zu kleines Foto mit dem Text "Zum Vergrößern anklicken". Machst Du natürlich, aber statt eine Vergrößerung zu öffnen, lautet die dahintersteckende URL "bieten.cgi?artikel=1234;hoehe=10000". bieten.cgi ist die Seite bzw. das Skript, das ein Gebot für einen Artikel annimmt und ohne weitere Nachfrage ausführt.

Weil Du nach wie vor eingeloggt bist, hat ein pöser Pube es in dieser Sekunde geschafft, Dir ein Gebot in Höhe von 10000 € für die gammelige Waschmaschine zu entlocken, die unter Artikelnummer 1234 angeboten wird.

Das ist Session-Riding. Andere Leute reiten auf Deiner Sitzung und nutzen sie als Vehikel für ihre Aktionen, indem sie Dir entsprechende URLs unterjubeln.

[Marc]

Ok, aber dann ist der Bereich, wo man damit etwas anrichten kann, relativ beschränkt:

-Der Angreifer muss selber etwas veröffetnlichen können und
-die URL-Struktur der Webanwendung kennen

[Martin Hölter]

Hi!

Ok, aber dann ist der Bereich, wo man damit etwas anrichten kann, relativ beschränkt:

Nö.

-Der Angreifer muss selber etwas veröffetnlichen können und

<a href="http://auktionshaus-deines-vertrauens.test/bieten.cgi?"> - das kann jeder.

-die URL-Struktur der Webanwendung kennen

Und wo ist _dabei_ jetzt bitte ein Problem?

Gruß aus Iserlohn

Martin

[Marc]

Und wo ist _dabei_ jetzt bitte ein Problem?

1. Dass meine Anwendung selbst programmiert ist und damit nicht unbedingt in so ein Schema passt

2. Kein Angreifer irgendwo so einen Link veröffentlichen könnte

:)

Und ich habe mir hier schon echt Sorgen gemacht...

[Axel Richter]

Hallo,

Ok, aber dann ist der Bereich, wo man damit etwas anrichten kann, relativ beschränkt:

-Der Angreifer muss selber etwas veröffetnlichen können und

Nein, er muss Deinem Browser nur einen Request unterjubeln. Das kann ein Link sein, auf den Du klickst (auch in einer E-Mail) oder auch nur ein Bild, welches Dein Browser via IMG-Element anfordert.

-die URL-Struktur der Webanwendung kennen

Nein. Man muss nur wissen, welche Reqests die Anwendung üblicherweise erwartet und wie sie diese verarbeitet.
Das kann man aus dem Quelltext der Anwendung, die man manipulieren will, und durch etwas Probieren herausbekommen.
_____________________________________________________________________
Session Riding funktioniert wenn:

Ein Nutzer in der selben Browsersitzung[1] an der Anwendung angemeldet war.
[1] Ich gehe davon aus, dass Session-Cookies verfallen, wenn der Browser geschlossen wird, also keine expliziten expires-Einstellungen haben. Hier ist auch eine Schutzmaßnahme, die der Nutzer ergreifen kann: Nach Arbeiten in sessiongesteuerten Anwendungen Browser schließen!

Die Anmeldung über Cookies(mit der SessionID) oder HTTP Authorization-Header[2] während dieser Browsersitzung automatisch verifiziert wird.
[2] Hier funktioniert es allerdings nur, wenn der Angriff von innerhalb der Seiten der Anwendung(dem geschützten realm) erfolgt. Das ist aber nicht weiter schwierig. Stell Dir eine Aktionsbörse vor, wo Nutzer sowohl bieten, als auch Angebote(mit Bildern und Links) einstellen können.

Dann reicht es, wenn der Angreifer es schafft, dass der Browser des Angegriffenen einen Request auf die anzugreifende Anwendung durchführt, in dem per GET- oder POST-Query gefälschte Parameter an die Anwendung übermittelt werden. Da das Session-Cookie oder der Authorization-Header automatisch mitgesendet werden, wenn sie noch nicht verfallen sind, hat die Anwendung keine Chance, diesen gefälschten Request von einem regulären Abschicken des Formulars zu unterscheiden.

_____________________________________________________________________
Nicht funktionieren kann es, wenn die SessionID im GET-Query der URL oder in einem hidden-Feld per POST-Query mitgesendet wird. Dann müsste der Angreifer eine noch gültige SessionID irgendwie abgelauscht haben und diese dann mit an seinen gefälschten Link anhängen oder in das Feld für POST einfügen.

viele Grüße

Axel