Web 2.0: Sicherheit weiter erhöhen

Nachricht

Wir betreiben bereits jetzt umfassende Maßnahmen zum bestmöglichen Schutz unserer Plattformen. Dies betrifft insbesondere den Schutz unserer Website, wo wir mit erschöpfender Sorgfalt alle aktuell für uns möglichen Sicherheitsvorkehrungen (vor allem im TLS-Bereich) getroffen haben. Für die Zukunft sind dennoch einige weitere Dinge geplant, die wir umsetzen werden sobald die externen Abhängigkeiten dies ermöglichen. Dies ist also ein Sammel-Ticket für diese Änderungen:

  • ✔ Certificate Transparency in nginx kompilieren. Hierdurch wird die Validität des Zertifikates ebenfalls durch CT geprüft und signiert. Dadurch ist es ausgeschlossen, das CAAs mit unsicherer Validierung unrechtmäßig für uns Zertifikate ausstellen und diese dann für MITM-Angriffe ausgenutzt werden können.
  • ✔ Expect-CT Header setzen. Sobald wir Certificate Transparency deployen, können wir Browsern vorschreiben nur dann unsere Handshakes zu akzeptieren, wenn die Validität von CT signiert und dem Handshake beigefügt wurde.
  • ✔ nginx server-name ändern. Unabhängig von der Brand-Assurance ist dies vor allem als minimaler Abwehrmechanismus gegenüber neuen Exploits von Botnetzen sinnvoll. Botnetze und Crawler suchen so nach bestimmten server-names, die womöglich verwundbar sind. Durch eine Änderung lässt sich dem entgehen.
  • ✔ "OCSP Must Staple" aktivieren.
  • ✔ Brotli-Compression Unterstützung einfügen: https://github.com/google/ngx_brotli.
  • ✔ Das noopener-Tag im rel-Attribut zu nofollow ergänzen. Dadurch wird click-jacking und phising verhindert, sowie das CORS-Netz erweitert. Andernfalls wird die Kontrolle über das window-Objekt mitgegeben, wodurch die Seite manipuliert werden kann. Mehr Details sind unter https://mathiasbynens.github.io/rel-noopener/ verfügbar. (Bereits im WSC integriert)
  • ✔ DNS CAA vornehmen. Dieser Eintrag dient der Beschränkung auf eine bestimmte CertificateAuthority.
  • ECDSA Intermediates bei OCSP beifügen. LetsEncrypt verfügt aktuell nur über RSA Intermediates und Roots. Dies wollen sie jedoch zeitnah ändern und dann können wir statt der RSA-Keys die ECDSA-Pendants verwenden. Dies verringert erheblich die Handshake-Größe.
  • SRI (Subresource Integrity) auch für interne Ressourcen unterstützen. Alle scripts und stylesheets sollten um einen Hash ergänzt werden. So kann verhindert werden, dass irgendwie der Inhalt eines unserer Scripts verändert wird, ohne das wir davon wissen.
  • Cookies mit SameSite=lax taggen. Dies verhindert, dass im Zuge eines CSRF-Angriffs die Cookies des Nutzers auf unserer Seite genutzt werden können. SameSite verhindert also effektiv, dass die Cookies an die Seite einer "Subresource" übertragen werden. Die Cookies werden nur dann übertragen, wenn sich der Nutzer wirklich auf der Domain befindet (Adressleiste). Get-Requests und einige andere werden bei der "Lax"-Policy aber noch erlaubt, so dass hier PayPal und co. kein Problem darstellen dürften.
  • CSP ohne style-src 'unsafe-inline' und script-src 'unsafe-inline' 'unsafe-eval' . Aktuell sind wir wegen der internen Architektur des WSCs noch darauf angewiesen die beschriebenen CSP Direktiven zu inkludieren. Sollte sich die in Zukunft (ggf. durch einen Merge-Request von uns) ändern, so ist es eine echte Errungenschaft diese Direktiven zu entfernen.
  • 100% Cipher-Security erreichen. Auch wenn wir jetzt schon mit unseren 90% meilenweit über praktisch allen Konkurrenten liegen ist das Ziel hier die 100% zu erreichen. Dies würde Sicherstellen, das wir ausschließlich State-Of-The-Art-Cipher verwenden und so alle Nutzer gleichermaßen gut geschützt sind. (Aus Kompatibilitätsgründen aktuell nicht möglich, viele Geräte unterstützen nicht mehr als 128-AES).

Wie bereits eingangs erwähnt unternehmen wir auch jetzt schon ungleich mehr Bemühungen als unsere Konkurrenz. Doch wir wollen uns lieber an dem maximal möglichen Messen, anstatt an den Fehlern die die Mitbewerber machen. Sollte jemand an einem Vergleich interessiert sein, so wird er hier (JustChunks) fündig.

Kommentare 6