PHP Session anfällig gegen Replay Attacks?

#1 Hallo, ich bin gerade dabei einen Chat Client zu implementieren und versuche natürlich, diesen möglichst sicher zu machen.
Nun frage ich mich gerade, ob PHP Sessions nicht völlig ungeschützt gegen Replay Attacks sind?
Wenn ich z.B. ein Login System habe, wie es im Internet ja oft als Beispiel angegeben wird, welches einen Benutzer nach erfolgreicher Anmeldung durch eine PHP Session anmeldet.
Wenn dann der Benutzer eine Aktion durchführen möchte, und das Skript mittels isset einer Session Variable prüft ob der Benutzer eingeloggt ist und die entsprechenden Rechte hat, kann dann ein Angreifer mit Zugriff auf den Netzwerkverkehr nicht einfach die gleiche Nachricht noch einmal schicken (welche dann richtige Session ID und / oder Cookie enthält) und kann die Aktion auch durchführen?

Viele Grüße
Oliver

#2 Die Verschlüsselung der Kommunikation (Topologie) hat nichts mit deinem Script zu tun,
die Session kann entweder via HTTP GET übertragen werden oder durch ein COOKIE (was aber essentiell aufs gleiche hinaus läuft).
Solange der Transportweg nicht verschlüsselt ist, kann er auch abgehört werden.

Es steht dir natürlich frei deine Session an eine feste IP oä. zu binden... das ist dann ein wenig sicherer - je nach dem von welchem Netzwerk der Client aus sendet (kann aber auch da durch Man in the Middle manipuliert werden).
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#3 Danke für deine schnelle und gute Antwort.
Also die Standardmethode dieses zu lösen wäre dann wohl TLS ?

Ich wollte es ohne TLS umsetzen. Hatte dafür eine Challenge Response Authentication (mit RSA) geschrieben um die Login Nachricht nicht replaybar zu machen - sinnlos oder?
Ohne TLS wäre es aber auch eine Möglichkeit, anfangs beim Login eine Reihe von Nonces verschlüsselt an den User zu schicken die dieser dann bei seinen Aktionen benutzen kann oder?

(Wollte aber eh noch einen Post zu dem Chat aufmachen und euch bzgl. möglicher Angriffe fragen.)

#4 Nur dann könnte ich mir die Session auch ganz sparen und nur Nonces benutzen oder?

#5

Zitat

bloggeroliver postete
Nur dann könnte ich mir die Session auch ganz sparen und nur Nonces benutzen oder?

Das eine hat mit dem anderen einfach nicht viel zu tun.
Wenn du über HTTPS/TLS gehst dann hast du ja Verschlüsselung.

Was sind Nonces?
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#6 Stimmt natürlich, ich wollte es nur ohne HTTPS/TLS umsetzen.

#7 Habe nun auch einen Thread mit spezielleren Fragen zu dem Chat gestartet (http://board.protecus.de/t43135.htm), somit könnte dieser Post, falls im Forum erwünscht, auch gelöscht werden.

#8

Zitat

bloggeroliver postete
Stimmt natürlich, ich wollte es nur ohne HTTPS/TLS umsetzen.

Warum willst du denn unbedingt etwas neu implementieren was schon vorhanden ist?
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#9 Guter Punkt.
Wie aber auch in dem anderen Post erwähnt, ist ein Punkt, dass ich den Client leicht einsetzbar machen möchte. Momentan wird nur (C#), PHP und MySQL benötigt was auch auf kostenlosen Webanbietern läuft, und kein TLS Zertifikat o.ä.
Der zweite Punkt ist, dass ich den Chat im Rahmen eines Blogs über C# schreibe, und deshalb das Programm möglichst weit selber implementieren und erklären möchte, bzw. einfach die Konzepte hinter sicherer Kommunikation erläutern.

#10 Beides basiert auf falsche Annahmen:
1. C# nutzt das .NET Framework und die Assemblies laufen sowieso in der .NET VM.
.NET beherscht TLS/HTTPS bereits.
Es ist also schon bereits easy deployment.

2. RSA (sowie ein Transport Protokoll) zu implementieren ist weder leicht noch sicher, es ist viel wahrscheinlicher das deine Implementation (auf einer oder beide Seiten) Fehler enthalten kann
darüber hinaus ist es inkompatibel mit bestehender Software.
Ergo macht man sowas nicht (nennt man auch security by obscurity).

Zu TLS (und HTTPS) brauchst du nichts mehr zu erklären, es ist bereits gut genug dokumentiert.
Du kannst viel mehr selbst die Dokumentation durchlesen und dich mit bestehenden Implementationen vertraut machen -> das Rad neu zu erfinden ist vielmehr schlechter Stil.
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#11 Danke für die interessante Diskussion, wie gesagt ich sehe ja auch den Vorteil von TLS und möchte nichts neu erfinden.
Ich kenne mich in dem Bereich auch schon einigermaßen aus würde ich behaupten, drücke mich vielleicht nur unsauber aus.

Richtig, ich weiß das die Benutzung von TLS (in C#) nicht schwer ist, allerdings muss ja vor allem der Server dies unterstützen. Das tut (fast?) kein kostenloser, und dann bräuchte man ja eventuell noch ein Zertifikat etc. Auf dieser Seite der "Aufwand", das praktische an dem Programm soll eben sein, dass sich wirklich jeder einen eigenen Server für den Chat aufsetzen könnte (ohne Kosten).
Und nein, RSA möchte ich natürlich nicht neu implementieren auf Grund der Fehleranfälligkeit - allerdings die Kommunikation ohne TLS absichern. In dem anderen Post habe ich meine "Lösung" beschrieben, würde mich interessieren was du davon hälst und was für Lücken du noch findest.

Btw: Was hat das mit security by obscurity zu tun? Die Funktionsweise des Systems kann ja genauso wie bei Benutzung von TLS o.ä. bekannt sein.

#12

Zitat

Das tut (fast?) kein kostenloser, und dann bräuchte man ja eventuell noch ein Zertifikat etc.

Du brauchst auf jedenfall ein Zertifikat wenn das richtig gemacht werden soll, wenn du nichts signieren lassen willst kannst du dir dein eigenes Zertifikat ausstellen.
Die gibts aber heut zu Tage schon kostenlos für den einfachen/privaten Gebrauch.
Jeder normale Webserver den du auf irgendeinem Webspace/Hoster antreffen kannst untertützt TLS/HTTPS.

Zitat

...dass sich wirklich jeder einen eigenen Server für den Chat aufsetzen könnte (ohne Kosten).

Das ist immer mit Kosten verbunden, so ist das leben - ob du nun selbst einen Webserver aufsetzt und dann den Strom bezahlst (und Arbeit investierst).
Ob du dir Webspace mietest, ob du dir einen ganzen Server oder VServer mietest ... usw.

Zitat

Btw: Was hat das mit security by obscurity zu tun? Die Funktionsweise des Systems kann ja genauso wie bei Benutzung von TLS o.ä. bekannt sein.

Zum Transportprotokoll sagtest du noch nichts, außer das du HTTPS auf gar keinen Fall nehmen willst (warum auch immer...).
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode