SID-Übergabe per URL verbieten - Vor und Nachteile

[Bobby]

Moin

Ist es sinnvoll für Session-Sitzungen die Übergabe der SID per URL zu verbieten und nur per Cookie zu erlauben?

Ich hatte mich mal informiert, das dies vor fremder Übernahme der Session  schützt(natürlich in Verbindung weiterer Maßnahmen wie SID neu aufbaun, SANITY_KEY usw)

Was sind die Vor- und Nachteile? Was würdet ihr empfehlen?

Gruß Bobby

[suit]

Ist es sinnvoll für Session-Sitzungen die Übergabe der SID per URL zu verbieten und nur per Cookie zu erlauben?

Nein.

Ich hatte mich mal informiert, das dies vor fremder Übernahme der Session  schützt(natürlich in Verbindung weiterer Maßnahmen wie SID neu aufbaun, SANITY_KEY usw)

Was würdet ihr empfehlen?

Wenn kein Cookie vorhanden ist, die Session-ID in die Adresszeile Packen, das ist das PHP-Standardverhalten.

Die Session-ID kann sich während der Session problemlos bei jedem Request ändern, session_regenerate_id() eignet sich hierfür z.B.

Es ist ein Irrglaube, dass die Session-ID immer gleiche bleiben muss.

[Bobby]

Moin

Wenn kein Cookie vorhanden ist, die Session-ID in die Adresszeile Packen, das ist das PHP-Standardverhalten.

Dann kann doch die Session aber übernommen werden von einem Angreifer. Nicht?

  
ini_set('session.use_cookies'     ,1);  
ini_set('session.use_only_cookies',1);  
ini_set('session.use_trans_sid'   ,0);  

mit dem Verbot der Übergabe der SID per URL umgehe ich dieses Sicherheitsproblem doch aber. Oder?

Die Session-ID kann sich während der Session problemlos bei jedem Request ändern, session_regenerate_id() eignet sich hierfür z.B.

Siehe meinen Post. Mit "SID neu aufbaun" war genau diese Funktionalität gemeint.

Gruß Bobby

[suit]

Wenn kein Cookie vorhanden ist, die Session-ID in die Adresszeile Packen, das ist das PHP-Standardverhalten.

Dann kann doch die Session aber übernommen werden von einem Angreifer. Nicht?

Ja kann sie, aber wenn sich mit jedem Request die ID ändert, hat er dazu genau 1x die Chance - bis sie sich wieder ändert.

Zusätzlich kannst du natürlich auch Prüfen ob sich der HTTP_USER_AGENT ändert oder ob die REMOTE_ADDR des Benutzers dieselbe ist wie beim Request zuvor.

Wenn nicht, wird die Session zerstört.

Einen 100%igen Schutz gibt es aber nicht - da musst du schon zu anderen Methoden greifen. Verschlüsselte oder getunnelte Verbindungen z.B.

mit dem Verbot der Übergabe der SID per URL umgehe ich dieses Sicherheitsproblem doch aber. Oder?

Nein, wieso? Was hindert einen Angreifer, dein Cookie zu klauen?

Siehe meinen Post. Mit "SID neu aufbaun" war genau diese Funktionalität gemeint.

Und ich habe dir die dafür zuständige funktion genannt.

[Bobby]

Moin

Nein, wieso? Was hindert einen Angreifer, dein Cookie zu klauen?

http://www.web-tuts.de/php-session-sicherheit-session-fixation.html

wird was anderes gesagt. :D Also, was stimmt nun?

Gruß Bobby

[Bobby]

Moin

OK, hat sich erledigt. Hast nat. recht.

Gruß Bobby

[Der Martin]

Hallo,

Wenn kein Cookie vorhanden ist, die Session-ID in die Adresszeile Packen, das ist das PHP-Standardverhalten.
Dann kann doch die Session aber übernommen werden von einem Angreifer. Nicht?

das kommt drauf an, wen du als Angreifer betrachten willst.

Den unbedarften Nutzer vor dem Bildschirm? Der wird nicht seine eigene Session entführen - wozu?
Einen Nutzer, der kurze Zeit später den Platz vor dem Rechner übernimmt und in der Browser-Chronik noch URLs mit Session-ID findet? Wenn der "echte" Nutzer sich ordnungsgemäß abgemeldet hat und dessen Session damit serverseitig für ungültig erklärt wurde, hilft das nicht.
Sobald du aber jemanden meinst, der irgendwo auf der Übertragungsstrecke mithört, ist es egal. Für so einen Lauscher sind beide Varianten (URL-Parameter und Cookie) gleichermaßen leicht erkennbar, beide stehen mehr oder weniger offensichtlich im HTTP-Header.

So long,
 Martin

[Bobby]

Moin

Danke, das war erklärend. Welche eineindeutigen Parameter könnte ich im SANITY-Key verwenden um die Session entsprechend zu schützen?

Gruß Bobby

[suit]

Danke, das war erklärend. Welche eineindeutigen Parameter könnte ich im SANITY-Key verwenden um die Session entsprechend zu schützen?

sagte ich bereits

[Felix Riesterer]

Lieber suit,

ich lese hier gerade sehr interessiert mit.

Die Session-ID kann sich während der Session problemlos bei jedem Request ändern, session_regenerate_id() eignet sich hierfür z.B.

DAS ist neu für mich und leuchtet mir spontan ein. Kann ich also direkt nach session_start() ein session_regenerate_id() notieren, damit bei jedem Request die Session-ID erneuert wird? Eingeloggte User bekommen so ihre alte ID ersetzt und neue User bekommen über session_start() eine erste (Vorab-ID), und mit session_regenerate_id() eine erneuerte ID zugewiesen. Oder habe ich da etwas missverstanden?

Liebe Grüße,

Felix Riesterer.

[suit]

DAS ist neu für mich und leuchtet mir spontan ein. Kann ich also direkt nach session_start() ein session_regenerate_id() notieren, damit bei jedem Request die Session-ID erneuert wird? Eingeloggte User bekommen so ihre alte ID ersetzt und neue User bekommen über session_start() eine erste (Vorab-ID), und mit session_regenerate_id() eine erneuerte ID zugewiesen. Oder habe ich da etwas missverstanden?

Ich glaube ich hab dich grade nicht verstanden :)

[Bobby]

Moin

DAS ist neu für mich und leuchtet mir spontan ein. Kann ich also direkt nach session_start() ein session_regenerate_id() notieren, damit bei jedem Request die Session-ID erneuert wird? Eingeloggte User bekommen so ihre alte ID ersetzt und neue User bekommen über session_start() eine erste (Vorab-ID), und mit session_regenerate_id() eine erneuerte ID zugewiesen. Oder habe ich da etwas missverstanden?

Ja, und über session_regenerate_id(TRUE) wird die alte Sessiondatei auch gelöscht (mit dem Parameter TRUE).

Gruß Bobby

[Tom]

Hello,

Ist es sinnvoll für Session-Sitzungen die Übergabe der SID per URL zu verbieten und nur per Cookie zu erlauben?

Einen Punkt möchte ich auch noch beitragen als Argument pro Cookie.
Wir hatten hier neulich den Fall, dass jemand danach fragte, wie er seinen aus externer Quelle eingebundenen Shop (im Frame oder in einer eigenen Seite) so anbinden kann, dass ein Rücksprung auf die Aussprungsseite/-stelle seiner eigenen Dokumente möglich ist. Der Shop bot für das "Zurück" nur die Möglichkeit, eine einzige URL statisch (eine pro Shop-Account) einzubinden.

Das funktioniert nur mit Cookie-gestützten Sessions.

https://forum.selfhtml.org/?t=202509&m=1367925

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg