Anzeige
Anzeige
Ratgeber
Artikel merken

SRI, CSP, HPKP und HSTS – Bleeding Edge Web Standards kurz erklärt

Wenn es um Sicherheit geht, sind viele sinnvolle Standards weitgehend unbekannt. Das ändern wir heute. Schon mal was von Bleeding Edge Web Standards gehört?

5 Min. Lesezeit
Anzeige
Anzeige

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.

Anzeige
Anzeige

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.

Anzeige
Anzeige

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.

Anzeige
Anzeige

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)

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.

Anzeige
Anzeige

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.

Anzeige
Anzeige

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)

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.

Anzeige
Anzeige

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.

Anzeige
Anzeige

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: 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:

Anzeige
Anzeige
<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.

Anzeige
Anzeige

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

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
2 Kommentare
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Sicherheit interessiert kaum wen

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 ?

Antworten
bcaiy

> Was sagen denn die Hoster zum erhöhten Rechenbedarf von HTTPS?

Der Unterschied liegt bei unter 1 %: https://istlsfastyet.com/

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige