Redhat-Webseite des Session-Replaying bezichtigt

Da haben es Forscher der Princeton Universität mal genauer genommen und eine Menge bekannter Webseiten auf sogenanntes Session-Replaying untersucht. Dummerweise sind davon nicht nur hierzulande eher unbekannte Webseiten zu finden, sondern auch Teamviewer, wordpress.com, wp.com, conrad.de, comodo.com, Skype & Microsoft und Redhat .

Was ist Session-Replaying ?

Session-Replaying bezeichnet Trackingtechniken in Javascript, die alle Tastatureingaben, alle Mausbewegungen usw. aufzeichnen und zur Auswertung an einen Drittanbieter übermittelt. Natürlich ohne vorher zu fragen, ob die das dürfen. Mit den Daten kann man als Webseitenbetreiber auswerten lassen, wo die eigenen Seiten besonders gut oder besonders schlecht sind. Soweit, so „naja“. Jetzt zeichnen die Scripte aber auch Fehleingaben auf, also z.B. alles was in der Zwischenablage ist und per Copy&Paste unabsichtlich kopiert wird, bspw. auch Passwörter.

Was damit für Schindluder getrieben werden kann, kann sich jeder selbst ausmalen, dem das Copy&Paste schon einmal seine Dienste versagt hat. Das geht nämlich leider schneller, als einem Lieb ist.

Für Redhat kommt der Dienst von clicktale.net ins Spiel. Dieser wurde von Princeton mit dem Vermerk : „evidence of session recording“ versehen.

Gegenmaßnahmen

Wenn es nach dem jüngsten FireFox Update auf 57 gegangen wäre: Keine.

Glücklicherweise hat Giorgio Maone sein Plugin NoScript auf die neue Firefox Api angepaßt. Damit kann man die Tracking-Domains sperren, bzw. erst gar nicht aktivieren. Also, alle die an Giorgio gezweifelt haben, sollten vor Ihm auf die Knie fallen und um Entschuldigung bitten. Der Mann und sein Plugin können Euch jeden Tag den Arsch retten! Das Teil ist für den Datenschutz der Goldstandard. Wundert mich eigentlich, daß die Bundesdatenschutzbeauftragte das nicht für jeden Behörden PC vorschreibt. Das wäre ja mal was 🙂

Die Liste

Wer sich die Liste ansehen will, die ist hier erhältlich:

https://webtransparency.cs.princeton.edu/no_boundaries/session_replay_sites.html

Ihr werdet noch mehr prominente Namen finden z.B. addidas.com , dominos.com ( Ex-Joeys ) , symantec.com, mongodb.com, cpanel.net, magento.com, bitdefender.com, acrobat.com, worldoftanks.com und wenig verwundernd kaspersky.ru .

Alle Apacheprozesse gleichzeitig stracen

Der Apache Webserver kommt ja mit mehreren Methoden daher, wie er effektiv möglichst viele Anfragen gleichzeitig beantworten kann. Die alte Prefork-Methode, die nicht mit HTTP2 kompatibel ist, startet dazu einen Prozess mit wenigen Kindern und splittet neue Prozesse ab, sobald eine Anfrage reinkommt.

Ein einfaches strace -f -p [pidvonerstemhttpd] reicht völlig aus um alle Zugriffe auf den Apachen zu tracen.

Das Event-Modell

Im Eventmodell , das für HTTP2 nötig ist, klappt das nicht mehr ganz so leicht. Hier müssen tatsächlich alle laufenden Prozesse gleichzeitig getraced werden, was in dem Beispiel hier:

├─httpd─┬─httpd(apache)
│ └─4*[httpd(apache)───63*[{httpd}]]

schon sehr,sehr viel Tipparbeit wäre ( > 240 pids) . Natürlich kann man das vereinfachen, indem man ein paar kleine Shellanweisungen nutzt:

strace -f -p `pidof httpd | sed -e "s/ /,/g"`

pidof als Befehl gibt uns leerzeichensepariert alle Prozessids zurück, die zum Httpd gehören. Leider kann strace die so nicht verarbeiten, also müssen wir die Ausgabe in kommasepariert umwandeln, dies macht der SED – Befehl. Die Backticks führen die Befehlsanweisung vor dem Aufruf von strace aus, so daß das Ergebnis direkt als Argument benutzt werden kann.

Linux – mysqldump sieht Leerzeichen als leeren Datenbanknamen an

Erinnert Ihr Euch noch an diesen Beitrag : Solution – mysqldump – No database selected when selecting the database aus dem Jahr 2016 ?

MariaDB & mysqldump

Damals stolperte ich über einen Fehler im Kommandozeilenparsing von Mysqldump.

Wie sich herausgestellt hat, konnte der Betreuer Michael Scholm bei Redhat die Ursache für das Problem entdecken. Kommt Ihr nie drauf: Das  war Schuld ! Oh ?! Ihr habt es nicht gesehen, hier nochmal  . Vielleicht mit der Lupe, da: > <. Ein Space.  Hier … zwischen dem „usr/bin/mysqldump“ und dem „–addlocks“ ist ein “ “ zuviel drin:

/usr/bin/mysqldump  --add-locks -e --force -R ....

Da es keine Option ist, wird es tatsächlich als valider Versuch, einen Datenbanknamen anzugeben gewertet.IMHO, ein Parser-Logik-Bug. Redhat sieht das anders: „not a bug“. Da jetzt raus ist, was es verursacht, kann man es ja leicht beheben.

etwas Kontext

Die Parser für Linux sind, sagen wir mal, ein bisschen eigen und deren Interpretation auch. Als Trenner zweier Argumente einer Kommandozeile gilt ein freistehendes Leerzeichen. Die Bash-Shell entfernt doppelte Leerzeichen und setzte ein Leerzeichen an die Stelle. So ein Leerzeichen zu viel ist schnell getippt und würde zu vielen „Dicke Finger-Syndrom“-Problemen führen, weil ..

… Ja, weil der Parser ohne diesen Trick, zwei Leerzeichen in Folge so übersetzen :

ls -la  foo => ls -la "" foo

Weil „Leerzeichen“ sind Trenner, also steht da oben eigentlich: „ls{Trenner}-la{Trenner}{Trenner}foo .

Wenn man aber zwischen den Trennern nichts hat, dann kommt ein leeres Argument raus. Was ein leeres Argument bedeutet, zeigt sich hier im Beispiel:

[marius ~]$ ls -la "" foo
ls: Zugriff auf '' nicht möglich: No such file or directory
ls: Zugriff auf 'foo' nicht möglich: No such file or directory

Wie man sehen kann versucht ls tatsächlich auf aka. „“ zuzugreifen. Wie das gehen soll ? Gar nicht. Ist ein Logikbug im Kontext von ls . Es wiederspricht der Natur eines ls , etwas aufzulisten, das es nicht gibt. Ergo müßte das Argument ignoriert werden. Jeder Mensch würde das so machen. Computerprogramme sind in der Beziehung blöde. Deswegen gibt es die Bash, die das Doppel-Leerzeichen wegnormaliziert und so vorhersehbare Fehler vermeidet, weil ..

Fehler vermeiden

wie man im obigen ls Beispiel gesehen hat, kann man es ja explizit angeben, wenn man muß => „“ oder “

MariaDB zieht sich jetzt auf den Standpunkt zurück, daß mysqldump sich ja nur wie ls verhalten würde. Tut es natürlich nicht, weil mysqldump komplett failed, wo ls einfach weitermacht und einen Fehler ausgibt.  Naja, Nobodys perfect.

Update

… oh, Redhat hat die Meinung geändert und einen Featurerequest bei MariaDB für einen besseren Parser erstellt. \o/ Das gibt einen dicken Daumen rauf! Mal sehen wies bei MariaDB ausgeht.