Vorhaben besprechen

TOOLBOX · SECURITY-CHECK

MIXED CONTENTFINDEN.

Lädt Ihre HTTPS-Seite noch Inhalte über unverschlüsseltes HTTP, und sind Skripte von fremden Servern gegen Manipulation abgesichert? Adresse eingeben, Note erhalten und jede Fundstelle sehen.

Die Bot-Prüfung schützt die Toolbox vor automatisiertem Missbrauch.

Wir laden die Seite einmal wie ein Browser und werten ihren HTML-Code aus. Eingebundene Dateien laden wir nicht. Ergebnisse speichern wir nicht dauerhaft.

WAS GEPRÜFT WIRD

Ein Schloss.
Keine Lücke.

Das Schloss in der Adresszeile gilt nur, wenn auch alles verschlüsselt kommt, was die Seite nachlädt. Und Skripte von fremden Servern laufen mit denselben Rechten wie Ihre eigenen.

  • 01

    Aktiver Mixed Content

    Skripte, Stylesheets, Frames, Plugin-Inhalte und Formularziele über HTTP. Browser blockieren solche Abrufe; ohne Blockade könnte jeder im Netzwerk Code einschleusen. Ein kritischer Befund.

  • 02

    Passiver Mixed Content

    Bilder, Symbole, Audio und Video über HTTP. Browser nach aktuellem Standard fragen sie über HTTPS an oder blockieren sie, etwa bei srcset und picture. Ein Hinweis.

  • 03

    upgrade-insecure-requests

    Setzt Ihre Content-Security-Policy diese Anweisung, stellen Browser alle Abrufe auf HTTPS um. Das entschärft die Funde; die Adressen sollten trotzdem stimmen.

  • 04

    Subresource Integrity

    Skripte und Stylesheets von fremden Servern mit Hash im Attribut integrity: Ändert jemand die Datei, führt der Browser sie nicht aus. Dazu die Abdeckung: wie viele fremde Dateien abgesichert sind.

  • 05

    integrity und crossorigin

    Nur sha256, sha384 und sha512 zählen, md5 und sha1 übergeht der Browser. Fremde Dateien mit integrity brauchen crossorigin, sonst lädt er sie gar nicht.

  • 06

    Basis-Adresse und Inline-Code

    Eine Basis-Adresse auf fremde Server, Weiterleitungen per meta-Refresh auf HTTP und die Zahl der Inline-Skripte und Eventhandler als Vorarbeit für eine strenge CSP.

SO BEHEBEN SIE ES

Adressen umstellen.
Dateien absichern.

Am besten stehen im HTML nur Adressen mit https:// oder relative Adressen. Für den Übergang und für Dateien von fremden Servern helfen diese Zeilen.

  • 01

    Alle Abrufe auf HTTPS umstellen

    Als Header in der Webserver-Konfiguration. Browser fragen dann jede eingebundene Datei über HTTPS an. Kann ein Ziel kein HTTPS, fehlt die Datei; einen Rückfall auf HTTP gibt es nicht.

    # nginx
add_header Content-Security-Policy "upgrade-insecure-requests" always;

# Apache (.htaccess oder VirtualHost)
Header always set Content-Security-Policy "upgrade-insecure-requests"
  • 02

    Oder direkt im HTML

    Ohne Zugriff auf den Server geht es auch mit einem meta-Element im <head>. Im Beobachtungsmodus (Content-Security-Policy-Report-Only) wirkt die Anweisung nicht.

    <meta http-equiv="Content-Security-Policy"
      content="upgrade-insecure-requests">
  • 03

    Fremde Dateien mit SRI einbinden

    Eine feste Version einbinden, den Hash der Datei in integrity eintragen und crossorigin="anonymous" ergänzen. Weicht die Datei ab, lädt der Browser sie nicht.

    <script src="https://cdn.example.com/bibliothek@1.2.3/bibliothek.min.js"
        integrity="sha384-HASH-DER-DATEI"
        crossorigin="anonymous"></script>

<link rel="stylesheet" href="https://cdn.example.com/stil@1.2.3/stil.min.css"
      integrity="sha384-HASH-DER-DATEI"
      crossorigin="anonymous">
  • 04

    Hash erzeugen

    Mit OpenSSL aus genau der Datei, die Sie geprüft haben. Vor den Wert gehört der Algorithmus, also sha384- und dann die Ausgabe.

    openssl dgst -sha384 -binary datei.js | openssl base64 -A

FRAGEN

Gut zu wissen.

Was ist Mixed Content, und was machen Browser damit?

Mixed Content heißt: Eine Seite kommt verschlüsselt über HTTPS, lädt aber Teile über unverschlüsseltes HTTP nach. Skripte, Stylesheets, Frames und andere aktive Inhalte blockieren aktuelle Browser, weil darüber jeder im Netzwerk Code in die Seite einschleusen könnte. Bilder, Audio und Video fragen Browser nach dem aktuellen Standard selbst über HTTPS an und laden sie nicht, wenn das scheitert; Bilder aus srcset oder <picture> und Adressen mit IP-Adresse blockieren sie sofort (W3C Mixed Content, MDN). Ältere Browser laden solche Inhalte unverschlüsselt. Formulare mit HTTP-Ziel würden Eingaben unverschlüsselt senden; Chrome warnt davor.

Was bringt Subresource Integrity?

Mit dem Attribut integrity geben Sie den Hash einer fremden Datei an, etwa einer Bibliothek von einem CDN. Der Browser vergleicht die geladene Datei damit und führt sie nicht aus, wenn sie abweicht, zum Beispiel nach einem Angriff auf den Anbieter. Gültig sind nur sha256, sha384 und sha512, andere Werte übergeht der Browser (W3C SRI). Dateien von fremden Servern brauchen zusätzlich crossorigin="anonymous", sonst kann der Browser den Hash nicht prüfen und lädt sie nicht (MDN). Ob ein Hash zur Datei passt, prüft unser Check nicht, weil er fremde Dateien nicht lädt.

Wie entsteht die Note?

Jede Prüfung hat ein Gewicht. Bestanden zählt voll, ein Hinweis halb, ein kritischer Befund nicht. Daraus ergibt sich ein Wert von 0 bis 100 und die Note A+ bis F. Aktiver Mixed Content und eine Seite ohne HTTPS sind kritisch und begrenzen die Note auf höchstens C. Setzt die Seite upgrade-insecure-requests, fragt der Browser nichts mehr unverschlüsselt an: Aktiver Mixed Content zählt dann als Hinweis, passiver als bestanden. Fehlendes SRI ist ein Hinweis bei Dateien von öffentlichen CDNs. Bei Diensten, die ihre Skripte laufend ändern, lässt sich SRI nicht sinnvoll einsetzen; das zählt nicht in die Note.

Was sieht der Check nicht?

Er wertet den HTML-Code der eingegebenen Seite aus, so wie der Server ihn ausliefert, höchstens 1 MB. Inhalte, die Skripte erst im Browser nachladen, Adressen in externen CSS-Dateien und andere Unterseiten sieht er nicht. Inhalte in <noscript> behandelt er wie ein Browser mit JavaScript, sie laden also nichts. Alle Abrufe einer Seite zeigen die Entwicklerwerkzeuge Ihres Browsers; in der Konsole meldet er auch blockierten Mixed Content.

Speichert TOMORIS meine Eingabe oder das Ergebnis?

Nein, nicht dauerhaft. Unser Server ruft die Seite einmal ab; die geprüfte Website sieht dabei unseren Server, nicht Ihre IP-Adresse. Das Ergebnis bleibt fünf Minuten im Arbeitsspeicher, damit wiederholte Abrufe derselben Adresse die Website nicht erneut belasten, und ist spätestens nach sechs Minuten gelöscht. Details stehen in der Datenschutzerklärung.

TOOLBOX

Weitere
Werkzeuge.

IHR NÄCHSTER SCHRITT

Ergebnis da.
Und jetzt?

Wir ordnen Befunde ein, priorisieren nach Risiko und setzen auf Wunsch um: einmalig mit EXPERTS oder laufend im Betrieb mit GRID.

Ergebnis besprechen