Leserbriefe

Danke für Ihren Add-on-Test im aktuellen Heft. Sie haben auch Ghostery getestet. Darf ich fragen, wie das Resultat war, wenn man der Datenübertragung nicht zugestimmt hat? Keine Userdaten-Übertragung mehr sowie keine eindeutige ID?

K. Schmid, via E-Mail

Ich habe auch noch ein paar Informationen anzubieten. Folgendes Setup: Virtuelle Maschine auf einem Dedicated Server bei Hetzner. Die VM hat eine öffentliche IPv4 und IPv6 und stellt ein paar Dienste zur Verfügung, die nicht direkt ersichtlich sind. Einer dieser Dienste ist ein Shell-in-a-Box-Server, den ich hinter nginx und einer speziellen URL gut versteckt habe.

Die URI besteht aus einem MD5-Hash eines bestimmten Wortes und „shell“. Beispiel: https://abc.foo.com/d3b07384d113edec49eaa6238ad5ff00/shell/.

Da der Login nur für den absoluten Notfall gedacht ist, habe ich den Server nach der Installation nur ein einziges Mal von zu Hause aus getestet und danach nie wieder angefasst.

In den Logs von nginx finde ich jetzt allerdings Zugriffe auf diese URLs von mir unbekannten IP-Adressen. Wäre es von bestimmten statischen Adressen gekommen oder dem Telekom- oder Kabel-Deutschland-Subnetz, wäre es mir gar nicht aufgefallen. Filtere ich dann aber mal über die Logs, finde ich Folgendes:

nmc1.ptt.js.cn

root.nmc1.ptt.js.cn

a.1001.adoniscs.afiliasdns.info

216-55-186-43.dedicated.codero.net.

ns01.registrar.kabel-deutschland.de.

dns-admin.kabeldeutschland.de.

ip58868bb5.dynamic.kabel-deutschland.de.

ip58868d86.dynamic.kabel-deutschland.de.

ns01.registrar.kabel-deutschland.de.

dns-admin.kabeldeutschland.de.

(Ausgabe gekürzt, d. Red.) Besonders stechen die ersten beiden IPs ins Auge. Weder war ich in China noch habe ich von chinesischem Equipment oder einem Server des DOI auf Shell in a Box zugegriffen.

Jetzt kommt natürlich die Frage auf, wie externe Personen an diese Informationen gekommen sind. Shell in a Box fällt als Erstes ins Auge, allerdings glaube ich nicht, dass der Server nach Hause telefoniert.

Ich tippe eher auf eines der installierten Plug-ins im Browser. Da ich es mit Chrome getestet hatte, kommen nur die folgenden Plug-ins in Frage: AdBlock Plus, Kaspersky Protection (mittlerweile deaktiviert), ScriptSafe, URL in title.

Spannend an dem Kaspersky-Protection-Plug-in ist, dass es – besonders wenn die Kommunikation in einem sog. „sicheren Browser“ fortgesetzt werden soll – nach Hause telefoniert und erst nach dem Aufruf der Kasperky-URL den sicheren Browser startet. Finde ich für ein Sicherheitsprodukt schon reichlich bedenklich.

Was mir aber am meisten Sorgen macht, ist, dass die Informationen nicht nur zur Auswertung für Werbezwecke und so weiter gesammelt werden, sondern dass es offensichtlich Leute gibt, die sich die URLs ganz genau anschauen und dann durchaus mal versuchen, sich Zugang zu verschaffen.

Dass ein Referrer für die Weitergabe der Informationen verantwortlich ist, konnte ich übrigens ausschließen. Das System ist sauber. Neben Kaspersky benutze ich auch regelmäßig ein PowerShell- Skript mit der VirusTotal-API und den Prozess Explorer mit VirusTotal.

Oliver Loch, via E-Mail

Natürlich stimme ich den Allgemeinplätzen in diesem Beitrag zu, allerdings ist die Webentwicklung noch weit davon entfernt, „reif“ zu sein.

Das zum einen deshalb, weil das eines der typischen „Anfängerfelder“ ist. Leute fangen damit an und werden entweder nie gut oder wechseln in andere Bereiche, während sie gut werden. Das liegt vielleicht auch daran, dass die meisten realen Probleme in der Webentwicklung relativ trivial sind. Der Großteil der Probleme ist hausgemacht.

Dann gibt es noch den nicht verstandenen Konflikt der „2 Webs“. Die einen sehen das Web als Sammlung von (quasi-)statischen Hypertextdokumenten an, die anderen als Plattform für Anwendungen. Das Ergebnis ist, dass statische Seiten JavaScript verwenden können und Webanwendungen immer den Zustand zwischen unterschiedlichen Anfragen zuordnen müssen.

Damit die Entwicklung von Webanwendungen „reif“ werden kann, müsste mindestens folgende Bedingung erfüllt werden: Man bräuchte so was wie HTTP/HTML für Webanwendungen. Zum Beispiel ein Protokoll, das eine Verbindung definiert und Zugriff auf den Dokumentenbaum ermöglicht. Das könnte zum Beispiel über WebSocket passieren.

Christian Berger, Oberkotzau