Nicht jeder Sicherheitsstandard ist so bekannt, wie er sein sollte. (Foto: Pixabay.com)
HTTP Strict Transport Security (HSTS)
HSTS verstärkt die Sicherheit der Übertragung von Daten per HTTPS. Es sorgt nämlich dafür, dass Verbindungen zwischen Browser und der entsprechend eingerichteten Website ausschließlich per HTTPS zustandekommen können. Jeglicher Zugriffsversuch per HTTP wird rigoros unterbunden.
Gerade bei frisch auf HTTPS umgestellten Seiten ist die Wahrscheinlichkeit hoch, dass sich doch noch irgendwo ein Link findet, der nicht mit dem zusätzlichen S ausgezeichnet ist. Ohne HSTS würde dieser Link dann auch so ausgeliefert, also unverschlüsselt via HTTP. Gleiches gilt, wenn ein Nutzer den Link etwa ohne das zusätzliche S eintippt. Mit HSTS ausgestattete Websites liefern alle Inhalte ausnahmslos nur noch per HTTPS aus. Unsichere Links werden umgeschrieben. Potenzielle Angreifer können sich nicht mehr in die Übermittlung einklinken.
HSTS funktioniert in allen modernen Browsern mit Ausnahme des Opera Mini, der aber ohnehin kaum eine Rolle spielt.
Trotz des zunächst unverzichtbaren Nutzens steht HSTS in der Kritik, da Seitenbetreiber darüber in der Lage sind, Nutzerinformationen ohne das Setzen von Cookies auszulesen, wenn der Header zu liberal gesetzt wird. Zwar ist der Zugriff einigermaßen kompliziert, aber eben generell möglich.
Nutzer können sich dagegen nur sehr unvollkommen zur Wehr setzen. Am sichersten ist der Chrome-Browser in dieser Hinsicht. Wenn du in Chrome die Cookies löscht, wird auch die HSTS-Datenbank mitgelöscht. Bessere Sicherheitsmaßnahmen gibt es zwar, allerdings müssten diese vom Seitenbetreiber ergriffen werden. Hier kommt das klassische Katze-Schwanz-Problem ins Spiel.
HTTP Public Key Pinning (HPKP)
HPKP schützt vor gefälschten Zertifikaten. (Foto: Pixabay.com)
Während HSTS lediglich die sichere Übertragung per HTTPS erzwingt, geht HPKP den nächsten Schritt. Die Maßnahmen sollten kumulativ implementiert werden.
HPKP wurde von Google vorangetrieben, um das Problem zu lösen, dass generell eine unüberschaubare Zahl an Zertifizierungsstellen potenziell falsche und damit unsichere Zertifikate erteilen kann, denen der Browser aber generell erst einmal vertraut, weil sie eben von „echten” Zertifizierungsstellen stammen.
Ist HPKP auf dem Webserver im Einsatz, so sendet die Website beim ersten Besuch eines Nutzers einen Header an den Besucherbrowser, der ihn anweist, bei künftigen Besuchen darauf zu achten, dass eines der gepinnten Zertifikate zum Einsatz kommt. Würden dem Browser dann beim nächsten Besuch andere Zertifikate übermittelt, würde dieser die Verbindung verweigern. Ein Risiko besteht in dem Falle also nur beim ersten Besuch, danach nicht mehr.
Für den Besucher ist HPKP ein verhältnismäßig sicheres Verfahren. Für Seitenbetreiber indes besteht das Risiko, dass sich ein Hacker die Website zugänglich macht und ein eigenes Zertifikat installiert, das fortan per HPKP ausgeliefert und fixiert wird. Davon bekommt der eigentliche Seitenbetreiber zunächst nichts mit, wenn er nicht ein dediziertes Monitoring installiert hat, das ihn über jegliche Änderung an seiner Konfiguration informiert.
Der Angreifer könnte sich dann zu einem Zeitpunkt X entscheiden, das Zertifikat zu löschen. Fortan erhalten wiederkehrende Besucher nur noch Fehlermeldungen. Denkbar, dass der Angreifer nun auf die Idee kommt, den eigentlichen Seitenbetreiber zur Kasse zu bitten, um das Zertifikat wieder gangbar zu machen. Dieser Vorgang ist nämlich nicht trivial. Einen Schutz, speziell durch den Verzicht auf HPKP, gibt es davor nicht, denn ein Angreifer ist ja nicht gehindert, auf einem Server HPKP überhaupt erstmalig in Betrieb zu nehmen.
HPKP funktioniert derzeit in Firefox, Chrome, Opera und dem Android-Browser nebst Chrome für Android.
Content Security Policy (CSP)
CSP lässt das Laden von Inhalten nur von bestimmten Lokationen zu. (Foto: Pixabay.com)
Ohne CSP lädt ein Browser jedweden Content auf einer Website, egal von wo er geliefert wird. Das ist in vielen Fällen hilfreich, muss man als Seitenbetreiber so etwa nicht alle verwendeten Frameworks/Scripts auf der eigenen Seite hinterlegen und entsprechend pflegen. Stattdessen linken wir schlicht die Originalquelle ein und haben so ein dauerhaftes automatisches Update sichergestellt.
Das Problem ist, dass eben nicht jede Site auch vertrauenswürdig ist. Das sogenannte Cross-Site-Scripting gehört nicht umsonst zu den größten Plagen moderner Webmaster. Gemeint ist das Ausführen bösartigen Scriptcodes per Cross-Site-Scripting oder mittels anderer Methoden der Code-Injection. Das Gefährliche ist, dass nicht einmal deine eigene Site betroffen sein muss. Es reicht ja, wenn der Angreifer in der Lage war, die Quelle zu vergiften, von der aus du das Script einlinkst.
CSP bekämpft Cross-Site-Scripting (XSS) effektiv. In einem weiteren Header definierst du per CSP Content-Quellen, also sichere Herkunftsorte, von denen aus Inhalte abgerufen und eingebunden werden können. Die erlaubten Inhalte legst du sehr individuell fest. So könntest du etwa Scripte (script-src) verbieten, aber Bilder (img-src) erlauben.
In der restriktivsten Einstellung lässt der Browser nur Inhalte zu, die von der aufgerufenen Domain selber (self) stammen. Jede weitere erlaubte Domain muss händisch zugefügt werden – Wildcards sind erlaubt, aber logischerweise wenig sinnvoll. Insgesamt kannst du deine CSP sehr kleinteilig konfigurieren. Bedenke aber, dass es um die Sicherheit geht und vermeide deshalb zu offene Definitionen.
CSP funktioniert in Chrome, Safari, Opera und in den mobilen Browsern. Firefox implementiert CSP nicht vollständig, Microsoft gar nicht. Browser, die CSP nicht unterstützen, ignorieren den Header schlicht und ergreifend, was sich nicht auf die Funktionalität der Seite auswirkt, aber eben die Sicherheit beeinträchtigt.
Subresource Integrity (SRI)
SRI: Stimmt der Hash-Wert nicht, wird die Datei nicht ausgeführt. (Foto: Pixabay.com)
SRI geht wieder einen Schritt weiter als CSP. Mit SRI sorgst du dafür, dass deine Inhalte, vor allem Scripte und andere Risikoelemente, mit einem Hash versehen werden und nur dann ausgeführt werden, wenn der Hash aus dem Dateilink mit dem Hash der tatsächlichen Datei übereinstimmt.
Das versteht man nur an einem Beispiel:
<link rel="stylesheet" href="dateiname.css" integrity="2b8e866efb9c91ae4d9baab1a4412e6c65c4d7517a9f85fc2f7ee87bc9e1557132f35dcfe677cbd90014e3f0862278bc">Hier wird eine CSS-Datei auf den ersten Blick ganz normal eingebunden. Dir fällt aber das Attribut integrity auf. Dieses Attribut beinhaltet den Hash-Wert der zuvor genannten Datei. Hash-Werte kannst du schnell und einfach mit dem SRI Hash Generator erzeugen.
Stößt der Browser auf eine solche Datei, lädt er sie zunächst herunter und vergleicht ihren tatsächlichen Hash mit dem per link übermittelten. Nur, wenn beide Werte übereinstimmen, wird die Datei ausgeführt. Stimmen die Werte nicht, wird die Ressource nicht ausgeführt. So kannst du ausschließen, dass jemand Inhalte, die nicht auf deinem Webspace liegen, sondern etwa über ein CDN ausgeliefert werden, austauscht und durch schadhafte Inhalte ersetzt. Zwar kann der Angreifer das immer noch tun, jedoch werden diese Inhalte aufgrund des signifikant veränderten Hash-Werts nicht mehr ausgeführt.
SRI funktioniert für die Browser Firefox, Chrome, Opera, Android-Browser und Chrome für Android, nicht hingegen in Microsoft-Browsern, sowie in den Safari-Varianten und Opera Mini.
Bei SRI kommt es indes nicht nur auf den Besucherbrowser an. Auf dem ausliefernden Webserver muss Cross-Origin Resource Sharing (CORS) aktiviert sein, um Hashes generieren zu können.
Zum Weiterlesen
- The double-edged sword of HSTS persistence and privacy | Leviathan Security
- Wachsende Kritik an Public Key Pinning für HTTPS | Heise Security
- Is HTTP Public Key Pinning Dead? | Qualys Blog
- XSS-Bremse Content Security Policy | Heise Security
- SRI Hash Generator | srihash.org
- I want to add CORS support to my server | Enable CORS
- Subresource Integrity | W3C
HTTP Public Key Pinning; Endlich wird meine ewig alte Idee durchgesetzt.
Man sollte bei seinem Browser-Hersteller (M$, Safari-Apple, Google-Chrome, Opera, …) am besten auch noch das Zertifikat checkern lassen und von China, USA, FSF usw. bestätigen lassen. Das die NA alle dazu bringt, das falsche Zertifikat zu akzeptieren dürfte unwahrscheinlich sein.
Es darf kein Baum sondern muss ein Mesh sein.
Firefox hat auch meine Idee das man böse Zertifikate verpetzt endlich umgesetzt.
Sowas („böse Zertifikate“) müssen vollautomatisch durch Browser-Crowding entdeckt und beendigt werden.
SRI: Gabs früher nicht auch ein „hash=“-Feld ? Davon abgesehen sollten Hashes immer den Namen dranstehen haben. Denn auch md5 wurde „geknackt“ also Dubletten mit anderem Inhalt erzeugt.
Und google hat schon Quantenechner. Daher sollten die hashes dran stehen.
Vorteil: Man kann besser cachen weil man nur Content mit neuem SRI runterladen muss am Handy am Monatsende mit GSM weil die 500 MByte UMTS-Tape-Flat längst verbraucht sind. Machen die Browser das ? kann da Webserver-Log das beweisen ? Klingt pillepalle aber die Downloadkosten fressen manchen Projekten die Spenden vom Konto leer.
„aufgrund des signifikant veränderten Hash-Werts“: Every bit counts. Im Gegenatz zu den Staatsschulden welche von 100 oder 1000 Generationen wohl nicht abgebaut werden, gilt ein Hash als TOTAL anders und somit UNZUTREFFEND wenn auch nur 1 Bit sich verändert hat. Bei Kunden-Nummern oder Bank-Konto-IBANs oder Kredit-Karten-Nummern wollt ihr ja auch nicht das die „nicht signifikant anders also ziemlich ähnlich“ sind. Bei Analystenvorhersagen oder Wahlprognosen ist Abweichung normal.
„Bei SRI kommt es indes nicht nur auf den Besucherbrowser an. Auf dem ausliefernden Webserver muss Cross-Origin Resource Sharing (CORS) aktiviert sein, um Hashes generieren zu können.“
Häh ? Im Link steht doch der Hashwert. Der Server soll es ausliefern.
Interessant wären zusätzliche Absicherungen wie geschützte Listen der Hashes und der Webserver merkt schon an der Datei wie ein Briefträger das Name/Adresse nicht mit der Adresse am Briefkasten übereinstimmen.
Aber um es zu überprüfen muss man es selber durchrechnen und den Hash vergleichen und nicht der (evtl gehackte) Webserver behaupten „ja ja stimmt schon“.
HSTS: Wird das im Browser angezeigt ? Manchmal ist ja ein Blitz für diese Google-HTTP-Alternative oder ein Schloss für httpS.
CSP: uBlock auf Serverseite. Har har har.
Dasselbe Problem wie auch mit SRI: Die Werbe-Netzwerke sind ja oft extern und wurden auch hin und wieder übernommen oder mit schädlichen Dateien verseucht. Da man nicht weiss, welche Werbebanner eingebaut werden oder welcher Werbedienstleister die Auktion gewinnt, ist speziell Werbung schlecht kontrollierbar.
Nett wäre noch meine ur-alte Idee das man IP-Nummern sich mal merkt. Der Twitter(?)-Ausfall vor ein paar Wochen beweist, wieso das sinnvoll war.
Im Prinzip sollte man (um in Übung zu bleiben) alle Keys einmal pro Jahr durch neue Keys ersetzen müssen. Dann kann man sie auch mitten im Jahr ändern falls Sicherheitsprobleme damit aufgetreten sein sollten. Die neuen und alten Keys signieren sich natürlich gegenseitig und wenn man unpassenden Content verpetzt man es an FSF, EFF, Chrome, Firefox und sonst jeden weltweit und lädt automatisch alles Böse bei Virustotal hoch. Ohne Kaspersky aus Russland hätte NSA vermutlich Direktzugriff auf jeden weltweiten Rechner.
In guten Ländern könnte man das machen und dem Volk und vielen Oppositionellen Verbesserung bringen und ihre Verseuchung stoppen.
Wenn man ein paar Tage die Checksummen, Besuchten Server und das Zeugs sich merkt erkennt man auch schnell, ob man angeseucht wurde oder verseucht werden sollte. 99.9% der Server sind ja sauber. Der Kühlschrank kann durch Kamera die zurückgezogenen und abgelaufenen Produkte erkennen und warnen. Auto-Rückrufe finden STÄNDIG statt. Browser sind bisher dümmer.
Denn Sicherheit interessiert doch kaum wen. Doch bald sind die Lichtschalter digital. Und dann kriegt es jeder mit oder muss teuer nachkaufen obwohl einzig und allein die Software Crap und unsicher ist, während der Lichtschalter noch 50 Jahre funktionieren würde. Hoffentlich wirken sich Schwedens(?) neue „nachhaltigkeit-reparierbarkeits-Gesetze“ auch auf Produkte aus. Also vielleicht nur Bestseller von Amazon-Schweden kaufen (von Amazon Deutchland aber die Top-Besteller-Produkte von Schweden als Vorlage nehmen was überhaupt in Frage kommt) wenn dort un-reparierbarer Schrott hoffentlich nicht mehr verkauft werden kann.
Tesla kriegt Update. Android nicht. Google seid stolz auf Euch. Fast die einzigen die sich um Kunden (also Bürger) kümmern sind früher Steve Jobs, aktuell Elon Musk von Tesla und die Discounter wodurch sich als Dauer-Opfer sofort BREXIT und TRUMP und Protest-Wahl erklären lassen während die iPhone-Establishment-Systempresse die Armut nicht mal erkennt.
Updates beinhalten natürlich auch Sicherheits-Verbesserungen aber es werden womöglich vielleicht immer noch Android-VIER_Geräte als neu bei Amazon verkauft weil es anscheinend nur mich interessiert.
Was sagen denn die Hoster zum erhöhten Rechenbedarf von HTTPS ?
> Was sagen denn die Hoster zum erhöhten Rechenbedarf von HTTPS?
Der Unterschied liegt bei unter 1 %: https://istlsfastyet.com/