[PHP] Sicherheit des Traffic

[Tobi]

Hi,
ich habe mich heute ein wenig mit sicherem Programmieren beschäftigt und bin dabei auf einen Artikel gestoßen, der sich mit der Thematik befasst, dass HTML-Traffic von anderen Personen mitgelesen wird, was dem Leser des Traffics ja eigentlich auch ermöglichen würde die SessionId's abzufangen und damit in den Account eines anderen Users einsteigen könnte. Nun hatte ich mir gedacht, vielleicht zusätzlich eine Datei mit einer Art SessionId auf den Client zu speichern. Wenn der Client jedoch dann die Daten dieser Datei an den Server schickt könnte dieser Traffic mitgelesen werden, oder nicht? Auf jeden fall würde mich, mal interessieren, wie aufwendig es ist den Traffic mitzulesen, wie das überhaupt genau funktioniert und wie man was dagegen machen kann. Schon mal vielen Dank im Vorhinein für die Antworten.

MfG
Tobi

 

[kbot]

also wenn einer mitliest, dann kannst du das auch nicht verhindern, das einzige was du tun kannst ist verschlüsseln, so dass das Gelesene nicht verständlich ist

(wie wird denn der "HTML-Traffic" laut dem Artikel mitgelesen? per Trojaner o.ä. oder per Leitung anzapfen? ^^)

 

[Tobi]

wie wird denn der "HTML-Traffic" laut dem Artikel mitgelesen? per Trojaner o.ä. oder per Leitung anzapfen? ^^

Der Artikel hat nur ganz oberflächlich das Thema angeschnitten und hat das Mitlesen des HTML-Traffics in einem Teilabschnitt zu SSL erwähnt, wobei SSL ja bestimmt teuer und aufwendig ist, jedoch habe ich mich mit dem Thema SSL noch nicht so richtig beschäftigt, da ich denke, dass sich das nur große Projekte leisten können. Über die Mehtoden, wie der Traffic mitgelesen wird wurde dort nichts gesagt, welhalb ich eben wissen wollte, wie das möglich ist. Gibt es eigentlich Alternativen zu SSL?
Wie kann man sich das anzapfen der Leitung eigentlich vorstellen? Das ist doch bestimmt aufwendig und damit sehr selten, oder?

Link zum Artikel

MfG
Tobi

 

[Freddixx]

Örm... Also mal im Ernst.

Der Hacker müsste es auf meinen Webserver schaffen und von da die Sessions holen. Aber wenn der auf meinem Server ist, ist eh alles aus Und sonst kann er lediglich auf dem Clientrechner mitloggen, was ein- / ausgeht.

Und selbst, wenn dieser Worst Case eintritt. Auf meinen Seiten gibt's nichts zu holen. Ich werde mir dieses Snippet dennoch bookmarken. Vielleicht baue ich es in meinem CMS ein.

Ich halte es trotzdem sehr unwahrscheinlich, dass sich jemand die Mühe macht, auf die Art und Weise Sessions zu klauen. Wenn du auf dem Clientrechner bist, kannst du genauso gut einen Keylogger laufen lassen. Der Erfolg sollte weit größer sein.

 

[kbot]

Der Artikel hat nur ganz oberflächlich das Thema angeschnitten und hat das Mitlesen des HTML-Traffics in einem Teilabschnitt zu SSL erwähnt, wobei SSL ja bestimmt teuer und aufwendig ist, jedoch habe ich mich mit dem Thema SSL noch nicht so richtig beschäftigt, da ich denke, dass sich das nur große Projekte leisten können.
...

https://forum.de.selfhtml.org/archiv/2006/1/t122625/

da steht, dass es wohl doch nicht so teuer und aufwändig ist

 

[Tobi]

Schon mal vielen Dank für die Antworten, wenn das so schnell ist kann ich ja noch ne Frage stellen : Ich habe in einem Anderen Artikel gelesen, dass es wohl möglich sein soll, bei shared Webhosting die Session-Variablen von anderen Seiten auslesen zu können, da man auf einen bestimmten ornder zugriff hat. Nun wollte ich wissen, ob es möglich ist, dass jemand, der die Informationenen der Sessions auslesen kann, die Werte auch ändern kann, denn es wär wohl sehr schelcht, wenn jemand einen Account bei meiner Seite hätte und bei dem Webhoster auf dem gleichen Server und könnte dann einfach seine Recht verändern, indem er einfach den Wert der Login-Session-Variablen von userstatus auf Adminstatus umstellt.

MfG
Tobi

 

[Talion]

Traffic kann an verschiedensten Stellen mitgelesen werden, z.b. könnte es selbstverständlich der ISP, oder der Betreiber eines Proxyservers (wenn man einen nutzt), oder wenn man sich z.b. im Internetcafe/Firmennetz/Uninetz/etc befindet, der jeweilige Betreiber und unter bestimmten Umständen sogar beliebige andere Leute im selben Netz. (Das hängt dann z.b. davon ab, wie die angeschlossenen Computer gekoppelt sind; Hubs leiten zum Beispiel allen Traffic an alle die am selben Knoten sind weiter, während man bei Switches in der Regel spezielle Methoden anwenden muss, um den Traffic zu sehen der für andere bestimmt ist.) Physikalisch eine Leitung anzuzapfen ist prinzipiell auch denkbar (wenn es nicht gerade um Glasfaserkabel geht) aber normalerweise nicht relevant.
HTTP-Traffic ist (ebenso wie FTP, POP und viele weitere) zunächst einmal ungeschützt. Echte Sicherheit bekommt man erst, wenn SSL/TLS o.ä. eingesetzt wird.
Allerdings stimme ich völlig zu, dass sich in den meisten Fällen niemand die Mühe machen wird. Dort wo es nicht um Geld oder vertrauliche Informationen geht, ist Verschlüsselung derzeit eher ein nice-to-have das die Mehrheit der Nutzer nichtmal wahrnimmt.

Aufwändig ist SSL übrigens nicht (jedenfalls nicht über die Konfiguration hinaus), das schöne daran ist ja, dass es transparent ist, so dass man es bei der eigentlichen Programmierung einer Seite nicht wirklich zu berücksichtigen braucht. Und teuer muss es auch nicht sein, es gibt ja kostenlose Zertifikate. Aber bei gewöhnlichen Shared-Hostern kann man mit denen im Normalfall nichts anfangen, und wenn der Zertifikatgeber (Certificate Authority) nicht im Browser verankert ist, ist (zumindest in der Theorie) die Sicherheit wieder hinfällig, da sich dann mit gefälschten Zertifikaten der Traffic doch wieder abhören lässt.




Mir wäre nicht bekannt wie man auf einem Sharedhost Sessions von anderen Kunden ändern können sollte. Sehen kann man sie teilweise schon, z.b. dank mod_status beim Apache.

 

[Tobi]

Vielen dank an Talion für seine ausführliche Beschreibung der Lage und natürlich auch ein herzliches Dankeschön an alle anderen. Ihr habt mir damit sehr weiter geholfen.

MfG
Tobi

 

[MrToiz]

[...] und wenn der Zertifikatgeber (Certificate Authority) nicht im Browser verankert ist, ist (zumindest in der Theorie) die Sicherheit wieder hinfällig, da sich dann mit gefälschten Zertifikaten der Traffic doch wieder abhören lässt.

Erstmal ein Lob für den Rest deines Postings, aber diese Passage kann ich nicht unkommentiert lassen!

Die Verschlüsselung ist nämlich auch bei einer (dem Client) unbekannten CA exakt genauso sicher wie bei einer bekannten. Der einzige Unterschied ist der, dass die Authentizität der Daten nicht bestätigt ist, was aber wirklich nur bei hoch-wichtigen Transaktionen von Bedeutung ist.

Ein einfaches Abhören (etwa im W-LAN oder am Hub des Clients, oder vom Betreiber des Proxy-Servers) ist damit nicht mehr möglich. Um an die Daten zu kommen, muss der Hacker zu wesentlich komplizierteren Mitteln greifen, nämlich einer Man-in-the-middle-Attacke.

Abgesehen davon sind bei den meisten Shared-Hosting-Angeboten höchstens SSL-Proxies möglich, und die haben dann ein Zertifikat, das von einer bekannten CA stammt.

 

[Talion]

Der einzige Unterschied ist der, dass die Authentizität der Daten nicht bestätigt ist, was aber wirklich nur bei hoch-wichtigen Transaktionen von Bedeutung ist.

Ohne Authentizität ist Verschlüsselungs nichts wert. Sicher verschlüsseltes Onlinebanking, bei dem du aber in Wirklichkeit nicht mit der Bank sondern mit dem Angreifer kommunizierst, bringt leider nicht viel

Vom Prinzip her hast du recht, aber ...

Um an die Daten zu kommen, muss der Hacker zu wesentlich komplizierteren Mitteln greifen, nämlich einer Man-in-the-middle-Attacke.

... der Man-in-the-middle-Angriff ist z.b. in ettercap bereits implementiert und lässt sich nahezu ohne Vorkenntnisse nutzen. (Natürlich nur wenn sich der Angreifer im anzugreifenden Netzwerk befindet, aber das wäre ja im Falle des bösen Internetcafebetreibers o.ä. gegeben.)

 

[Tyrell]

Örm... Also mal im Ernst.

Der Hacker müsste es auf meinen Webserver schaffen und von da die Sessions holen.

Nö. Es reicht schon, wenn ich im gleichen LAN/WLAN bin, wie du und Wireshark o.ä. anwerfe. Dann sehe ich deinen kompletten HTTP-Stream und brauche die Session-ID nur rauszufiltern. Die benutze ich dann beim Seitenaufruf und habe deine Session übernommen. Der Aufwand beträgt ca. 60 Sekunden.

 

[Freddixx]

Du hast einen Schritt vergessen:

Dazu musst du in mein WLAN und von dem Fall gehe ich bei WPA2 nicht aus. Wenn es beim User selbst passiert entfällt das aus meinem Zuständigkeitsbereich.

 

[Tyrell]

An Daten zu kommen ist kein Problem, es gibt schließlich genügend öffentliche Netzwerke, z.B. an Unis.

 

[neuerpc]

Nö. Es reicht schon, wenn ich im gleichen LAN/WLAN bin, wie du und Wireshark o.ä. anwerfe. Dann sehe ich deinen kompletten HTTP-Stream und brauche die Session-ID nur rauszufiltern. Die benutze ich dann beim Seitenaufruf und habe deine Session übernommen. Der Aufwand beträgt ca. 60 Sekunden.

diese Äußerung trifft nur dann zu, wenn man einen Hub benutzt.
Und da heutzage jeder einen Router besitzt, sind noch weitere Schritte dafür nötig, die länger als 60 Sekunden dauern

 

[Tyrell]

diese Äußerung trifft nur dann zu, wenn man einen Hub benutzt.
Und da heutzage jeder einen Router besitzt, sind noch weitere Schritte dafür nötig, die länger als 60 Sekunden dauern

Wie gesagt, Daten gibt es genug.
Wenn jemand an Daten herankommen will, sucht er sich ja nicht eine einzelne Person aus und versucht, in dessen Netzwerk einzudringen. Es ist wohl einfacher, ein offenes Netzwerk mit x-tausend Nutzern zu wählen und dort gezielt nach den Daten zu suchen.

Als Webservice-Anbieter kann mir das natürlich scheiß-egal sein, allerdings fällt es ja doch immer wieder auf mich zurück, wenn Daten erschlichen und Missbrauch betrieben wird. Die Sparkasse könnte auch sagen: "Wir verschlüsseln unser Homebanking nicht, ist ja das Problem des Kunden." Ist sicherlich der einfacherere Weg, aber nicht unbedingt der sinnvollste.

 

[Scar]

Mir wäre nicht bekannt wie man auf einem Sharedhost Sessions von anderen Kunden ändern können sollte. Sehen kann man sie teilweise schon, z.b. dank mod_status beim Apache.

wenn die sessions aller nutzer im selben verzeichnis abgelegt werden, kannst du in der regel drauf zugreifen. das wäre inzwischen aber eher ein konfigurationsfehler vom server-admin.

man-in-the-middle habt ihr bereits erwähnt und das ssl in solchen fällen nichts bringt. allerdings ist ssl wirklich teuer. hier ist nicht die anschaffung relevant, sondern die permanten verschlüsselung. das kostet cpu-zeit und wirkt sich bei größeren seiten bzw. allgemein mehr traffic aus.

ansonsten interessiert euch vielleicht noch folgender artikel:
https://shiflett.org/articles/the-truth-about-sessions

 

[shenziro]

Naja,

"wirklich teuer" würde ich es heutzutage nicht mehr nennen. Der Handshake ist etwas rechenintensiv, aber danach gehts ja mit einem symmetrischen Algorithmus weiter (AES beispielsweise), der weniger rechenintensiv und bei sauberer implementation sehr schnell ist. Ich schaff hier auf meinem PC mit AES256 immerhin 50MB/s mit einem AMD X2 3800+. So schnell werden Websites i.d.R. nicht versendet.. die breite Masse hat ja gerade einmal 6 bzw. 16 MBit..

Es kommt jedoch auch darauf an, wie viele Nutzer den ganzen Spaß nutzen. Vorteilhaft wäre auch, TLS nur bei eingeloggten Nutzern zu erlauben und sonst auf die unverschlüsselte Seite zu leiten.

Nun ist die Frage, wie sich bei ändern der Session-ID nach jedem Request die Last auf dem Server verhält, da ja immer wieder die ganzen Daten neu auf die Platte geschrieben werden.
Wäre evtl. sogar besser, seine Sessions in einer MySQL abzulegen und mit eigenen Funktionen dann einfach nur per UPDATE die ID zu ändern und den restlichen Datensatz so zu lassen.
.. Das müsste man mal ausprobieren..

Aber auf den Traffic sollte es sich nicht bis nur ein wenig legen, da i.d.R. nicht nur verschlüsselt sondern auch komprimiert wird.
Dann ist ebenfalls die Frage, wie ein Webspaceprovider den Traffic zählt.. Wenn die Webserverlogs "zusammengerechnet" werden, ist da der Traffic für den TLS-Handshake afaik nicht mit drin.. Das sind dann schonmal paar Kilobyte weniger.

 

[Talion]

Vorteilhaft wäre auch, TLS nur bei eingeloggten Nutzern zu erlauben und sonst auf die unverschlüsselte Seite zu leiten.

Das wäre relativ sinnlos, da dann ja der Login noch unverschlüsselt übertragen wurde. Aber was man natürlich machen kann, ist nur für die Seiten TLS zu verwenden, die schutzungsbedürftig sind. Wie shenziro richtig sagt, ist aber hauptsächlich der Handshake rechenintensiv, so dass sich damit nicht soo viel herausholen lässt.

 

[Tyrell]

Naja,

"wirklich teuer" würde ich es heutzutage nicht mehr nennen. Der Handshake ist etwas rechenintensiv, aber danach gehts ja mit einem symmetrischen Algorithmus weiter (AES beispielsweise), der weniger rechenintensiv und bei sauberer implementation sehr schnell ist. Ich schaff hier auf meinem PC mit AES256 immerhin 50MB/s mit einem AMD X2 3800+. So schnell werden Websites i.d.R. nicht versendet.. die breite Masse hat ja gerade einmal 6 bzw. 16 MBit..

50 MBit/s ist gar nichts. Natürlich haben die meisten Menschen keinen 50 Mbit-Anschluss. Aber evtl. besucht mehr als einer gleichzeitig deine Seite. Sagen wir mal so... 100. Dann möchteste schon deine 200 MBit/s durchkriegen, was immer noch langsam, aber akzeptabel ist.

 

[shenziro]

Das wäre relativ sinnlos, da dann ja der Login noch unverschlüsselt übertragen wurde.

Man sollte dann schon <form action="https://..."> machen, dann geht das auch.

50 MBit/s ist gar nichts.

Ich habe "50MB/s" geschrieben. MB sind immernoch MegaByte.
Das wären dann also genau 400Mbit/s.

Edit
TrueCrypt Benchmark: (screenshot)
PS.: Ist erst seit der neuen Version, die ich vorhin draufgemacht habe, so schnell.. da haben die Jungs ordentlich optimiert.