„Es könnte der schlechteste Code sein, den ich jemals gesehen habe“
Puuuh… Gut dass sie den Proxer Code noch nicht gesehen haben 😀
Quelle des Zitats: https://www.golem.de/news/tizen-betriebssystem-koennte-der-schlechteste-code-sein-den-ich-je-gesehen-habe-1704-127133.html
Es ist echt unglaublich, was für ein Bullshit WordPress bei der Installation mitliefert und es als „Feature“ verkauft. Das hat zur Folge, dass massig Daten bei jeder WP-Installation an diverse Anbieter gesendet wird. Ich schreibe hier mal eine kleine Anleitung, wie man diese beseitigt. Den Source-Code der hier empfohlenen Plugins habe ich geprüft. Meine Prüfkriterien waren hierbei minimaler Code, und dass keine neuen Datenschutzmängel entstehen.
1. Gravatar abschalten: Nur geht das leider nicht ohne weiteres. Ob man will oder nicht, wird jeder Zugriff auf Seiten mit aktivierter Kommentarfunktion an die Betreiber von Gravatar (aka WordPress) gesendet. Zum deaktivieren eignet sich dieses Plugin.
2. Google Fonts: Auch an Google wird bei JEDEM Seitenaufruf Daten gesendet. Google weiß, welche Seiten du wann aufgerufen hast. Und das schlimmste ist, dass der Blog nicht funktioniert, wenn man die Anfragen blockiert. Um dies zu hindern, eignet sich dieses Plugin.
3. DNS Prefetch: DNS-Prefetch sorgt dafür, dass Webseiten ein paar tausendstel Sekunden schneller laden. Was passiert? Das Auflösen der Domainnamen der externen Seiten wird einfach etwas vorher durchgeführt. Ich habe dies mit diesem Plugin deaktiviert.
4. Smileys: Wenn man in Beiträgen Smileys verwendet, werden sie automatisch in Emojis umgewandelt. Die Bilder von den Emojis werden, wie nicht anders zu erwarten, extern geladen. Dafür habe ich kein gutes Plugin entdeckt. Es geht aber relativ einfach, indem man im Adminbereich auf „Design“ > „Editor“ > „functions.php“ geht, und anschließend ganz ans Ende der Datei folgende zwei Zeilen einfügt:
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');
Dadurch sollten auch Emojis ausgeblendet werden, und euer Blog sollte mit diesen Maßnahmen Datenschutztechnisch auf hohem Niveau sein.
In meinem Blog verzichte ich zusätzlich auf Google Analytics und nutze eine selbstgehostete „Piwik“-Installation, um Statistiken über meine Webseite zu erhalten. Ich weiß, dass sich das nicht jeder Leisten kann, zumal der Aufwand zum Warten und Instandhalten hoch ist. Aber wer Mitarbeiter hat, die Ahnung haben, kann sie ja beauftragen ^_^
Wer zusätzliche Tipps und Infos hat, kann sie mir gerne über die Kommentarfunktion mitteilen! Ich hoffe, dass der Beitrag etwas hilfreich ist 🙂
Yehaaa! Ich habe gestern angefangen mich aktiv in AngularJS einzuarbeiten. Meine zukünftigen Projekte will ich damit verwirklichen. Ich verwende das folgende Tutorial hierfür:
https://angular.io/docs/ts/latest/tutorial/toh-pt1.html
Ich bin das Tutorial fast durch, und muss sagen, dass ich bereits unheimlich viel neues gelernt habe. Man merkt richtig, dass sich da kluge Leute viele Gedanken gemacht haben. Ich freue mich auf den weiteren Verlauf des Tutorials!
Mein erstes Projekt damit wird wahrscheinlich der Proxer Messenger sein.
Am letzten Wochenende habe ich mich mit der Zwei-Faktor-Authentifizierung von Proxer beschäftigt. Dieses Wort ist jedes Mal soooo anstrengend zu schreiben. Daher kürze ich es ab und nenne es nur noch 2FA.
Am Freitag wurde öffentlich, dass Cloudflare einen Softwarefehler hatte, und dieser dafür gesorgt hat, dass durch ein Speicherleck viele persönliche Daten und Passwörter geleaket wurden.
Ich war da relativ locker. Passiert halt, lässt sich nicht vermeiden. Und da ich mein Passwort auf Proxer ohnehin regelmäßig ändere und Zufallspasswörter nutze, war die Gefahr relativ niedrig für mich. Jedoch habe ich am nächsten Tag eine ganze Menge Mitteilungen bekommen. E-Mails, PNs und Skype-Nachrichten über diesen Fall. Auch kamen Supportanfragen im Forum. Nicht jeder hat so eine sichere Passwortpolicy wie ich. Aus diesem Grund habe ich beschlossen im Rahmen dieses Falles die 2FA für Proxer zu priorisieren. Ich war auch zwei ganze Tage da dran, und habe versucht zu entschlüsseln, wie die 2FA im Joomla-Core gelöst ist. Darauf aufbauend habe ich das Ganze dann auf Proxer implementiert, sodass sie mit Joomla kompatibel ist. Ich denke, dass ich mit dieser Konsequenz ausreichend auf die Sorgen eingegangen bin. Wer 2FA nutzt, wird in Zukunft sicher sein.
Es gab jedoch ein kleines Problem: Für die 2FA wird ein weiteres Feld für den Geheimschlüssel benötigt. Wie ich Nutzer so kenne, werden seeeeehr viele verwirrt sein, wenn neben Benutzername und Passwort ein drittes Feld erscheint. Das heißt, dass das dritte Feld nur dann erscheinen darf, wenn 2FA bei dem Benutzer aktiv ist, der sich gerade einloggt. Das war jedoch mit der altem alten Login-Formular nicht möglich. Dieses gibt im Fehlerfalle keinerlei Nachrichten zurück, und ist wirklich stupide einfach programmiert. Aus diesem Grund musste das ganze Login-Feld umgebaut werden. Das klingt leicht, aber war es tatsächlich nicht. Wie bei der 2FA auch, habe ich auf Joomla-Core aufbauend die ganze Login-Routine neu entwickelt. Ich bin die Joomla-Core abläufe unzählige Male durchgegangen, um zu verstehen, wie Joomla die Login-Routine macht. Es war verdammt interessant, und im Großen und Ganzen ist das sehr schön gelöst. War auf jeden Fall ein sehr guter Einblick.
Das neue Login-Formular gibt Fehlermeldungen aus, falls beispielsweise Benutzername/Passwort falsch sind. Es aktiviert auch das dritte Feld, falls 2FA aktiv ist. Ich war endlich fertig! Nun kam das nächste Problem. Mir ist dann aufgefallen, dass Logindaten auf der nicht-SSL-Seite ungeschützt an den Server weitergeleitet werden. Um dem zu entgehen, habe ich erst den naiven Ansatz probiert: Einfach den AJAX-Link angepasst und SSL erzwungen. Wie nicht anders zu erwarten funktioniert das nicht. Es kommt die folgende Meldung:
Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf https://proxer.me/. (Grund: CORS-Kopfzeile ‚Access-Control-Allow-Origin‘ fehlt).
Nun musste eine Lösung dafür her! Als erstes habe ich mich an Jsonp rangewagt. Das wurde auch auf Stackoverflow als eine mögliche Lösung empfohlen. Erstmal die Json-Schnittstellen überarbeiten, sodass sie auch Jsonp fähig sind. Ich hatte das bisher nie gebraucht. Das ist eine erstaunlich nützliche Technik ist mir aufgefallen.
Nachdem das fertig war, hats immer noch nicht funktioniert. Die Login-Daten wurden nicht an den Server übermittelt. Sie Browserkonsole gab die Antwort: Jsonp unterstützt keine POST-Parameter. Ihr könnt euch vorstellen wie verärgert ich in dem Moment nach Stundenlangem friemeln war xD Dann hat mir ein Teammember CORS empfohlen. Damit kann man serverseitig Cross-Origin-Anfragen whitelisten. Damit war das Problem am Ende dann auch mit einfachen json-Anfragen gelöst. Login-Daten auf der nicht-SSL Seite wurden nun auch verschlüsselt an den Server übertragen. Ich war damit sehr glücklich 🙂 Ich weiß, schlussendlich war der Ganze Aufwand meiner eigenen Dummheit zu verdanken. Ich muss noch so viel lernen… Es war aber eine wundervolle Erfahrung. Ich habe mich damit in 2FA (Google Authenticate), Jsonp, CORS und Joomla-Authentifizierungs-Routinen eingearbeitet.
Fazit: Es gibt seit gestern die 2FA auf Proxer. Wer sich dies einrichtet, ist auch bei zukünftigen Passwort-Leaks geschützt. Einrichten kann man sich das unter „Profil bearbeiten“. Da ein paar Abhängigkeiten für die Umsetzung gebunden waren, habe ich ganze zwei Tage für diese Umsetzung benötigt.
Im Laufe der Woche wird die Ankündigung auf Proxer veröffentlicht. Ich bearbeite hier den Link ein, sobald dieser öffentlich ist. Edit: Hier ist die Ankündigung.