Server-Rezept
Ein web.config-Block zum Einfügen, eine Erklärung zu jedem Eintrag darin und die zwei IIS-Verhalten, die Ihnen doppelte Header bescheren oder gar keine.
01 Wohin es gehört
Der customHeaders-Abschnitt gehört in die web.config im Wurzelverzeichnis Ihrer Seite. IIS sendet die Header dann mit jeder Antwort dieser Seite, auch bei statischen Dateien, Downloads und Fehlerseiten, und genau das wollen Sie: ein Header, der auf Ihrer 404-Seite fehlt, fehlt auf einer Seite, die Angreifer erreichen können.
IIS führt die Konfiguration den Ordnerbaum hinunter zusammen, und dort geht es schief. Eine web.config im Unterordner erbt Ihre Header, aber sobald sie eigene customHeaders definiert, werden beide Sätze kombiniert statt ersetzt, und derselbe Header geht zweimal mit verschiedenen Werten raus. Setzen Sie ein clear-Element, um in diesem Ordner bei null anzufangen, oder ein remove-Element vor jedes add, und legen Sie sich auf eine Datei fest, der der Satz gehört.
02 Das Rezept
Ein sicherer Ausgangspunkt für eine Seite, die ihre eigenen Dateien ausliefert. Die remove-Zeile für X-Powered-By ist keine Zierde: IIS und ASP.NET nennen ihre Versionen standardmäßig, und damit weiß ein Angreifer, welche Schwachstellen er zuerst probiert.
<configuration> <system.webServer> <httpProtocol> <customHeaders> <remove name="X-Powered-By" /> <add name="Strict-Transport-Security" value="max-age=63072000; includeSubDomains" />
<add name="Content-Security-Policy" value="default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'" />
<add name="X-Frame-Options" value="DENY" />
<add name="X-Content-Type-Options" value="nosniff" />
<add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
<add name="Permissions-Policy" value="geolocation=(), camera=(), microphone=(), payment=(), usb=()" /> </customHeaders> </httpProtocol> </system.webServer> </configuration> Zwei Anpassungen, bevor das Ihres ist. Die Content-Security-Policy oben erlaubt nichts von Dritten, eingebundene Karten, Schriften oder Analyse werden also blockiert, und sie sollte zuerst im Report-Only-Modus rausgehen. Und X-AspNet-Version kommt von ganz woanders: den schalten Sie mit enableVersionHeader auf false im httpRuntime-Element ab, nicht über einen customHeaders-Eintrag.
03 Zeile für Zeile
Jeder Eintrag aus dem Block oben einzeln, damit Sie weglassen können, was nicht zu Ihrer Seite passt, statt etwas einzufügen, das Sie nicht erklären können.
Strict-Transport-Security Was er macht. Legt Browser darauf fest, Ihre Seite zwei Jahre lang nur über HTTPS zu erreichen. Fügen Sie ihn erst hinzu, wenn HTTPS auf jeder Subdomain funktioniert, denn includeSubDomains gilt auch für Hosts, die Sie vergessen haben.
<add name="Strict-Transport-Security" value="max-age=63072000; includeSubDomains" /> Content-Security-Policy Was er macht. Beschränkt jede Ressource auf Ihren eigenen Ursprung und verbietet das Einbetten vollständig. Das ist der Eintrag, der auf einer echten Seite am ehesten etwas kaputt macht, und der einzige, den Sie zuerst im Report-Only-Modus ausrollen sollten.
<add name="Content-Security-Policy" value="default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'" />
<add name="Content-Security-Policy-Report-Only" value="default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'; report-uri /csp-report" /> X-Frame-Options Was er macht. Verhindert, dass Ihre Seiten irgendwo in einem Rahmen eingebettet werden. Nehmen Sie SAMEORIGIN, wenn ein Teil Ihrer eigenen Seite einen anderen einbettet, was SharePoint und ältere ASP.NET-Anwendungen regelmäßig tun.
<add name="X-Frame-Options" value="DENY" /> X-Content-Type-Options Was er macht. Sagt dem Browser, Ihren angegebenen Inhaltstypen zu vertrauen, statt zu raten. Es gibt keine Seite, auf der dieser Wert falsch wäre.
<add name="X-Content-Type-Options" value="nosniff" /> Referrer-Policy Was er macht. Sendet die vollständige Adresse innerhalb Ihrer eigenen Seite und nach außen nur die bloße Domain. Der Wert für nahezu jede öffentliche Website.
<add name="Referrer-Policy" value="strict-origin-when-cross-origin" /> Permissions-Policy Was er macht. Schaltet Kamera, Mikrofon, Standort, Bezahlfunktion und USB-Zugriff für Ihre Seiten und alles Eingebettete ab. Erweitern Sie die Liste, statt sie zu kürzen: Funktionen, die Sie nicht nennen, bleiben verfügbar.
<add name="Permissions-Policy" value="geolocation=(), camera=(), microphone=(), payment=(), usb=()" /> 04 Nachprüfen
Eine Änderung an der web.config greift ohne Neustart, aber eine Anwendung, die Header im Code setzt, sendet ihre eigenen weiter, bis der Arbeitsprozess neu startet. Ein Neustart des Anwendungspools nimmt diese Unbekannte aus der Messung, bevor Sie irgendetwas ablesen.
Restart-WebAppPool -Name "DefaultAppPool" (Invoke-WebRequest -Uri https://example.com -UseBasicParsing).Headers Achten Sie auf einen Header, der zweimal auftaucht. Das ist die Vererbungsregel von oben, und Browser behandeln doppelte Security-Header uneinheitlich: manche nehmen den ersten Wert, manche den strengsten, manche ignorieren beide.
05 Fragen
Entweder ergänzt eine web.config weiter unten im Ordnerbaum eigene Einträge, oder Ihre Anwendung setzt den Header zusätzlich im Code. IIS kombiniert beides, statt sich zu entscheiden. Suchen Sie die zweite Quelle, und wenn es die Anwendung ist, legen Sie fest, welcher Ebene der Header gehört, und schalten Sie die andere ab.
Ja. customHeaders wird vom HTTP-Protokollmodul angewendet, bevor Ihre Anwendung läuft, Bilder, Stylesheets und Downloads bekommen sie also ebenfalls. Das ist der Vorteil gegenüber Headern aus dem Anwendungscode, der diese Anfragen nie zu sehen bekommt.
Können Sie: HTTP-Antwortheader im IIS-Manager schreibt exakt dieselben customHeaders-Einträge in dieselbe Datei. Die Datei direkt zu bearbeiten lässt sich leichter prüfen, leichter versionieren und leichter auf einen zweiten Server ausrollen, ohne sich noch einmal durch denselben Dialog zu klicken.
Nicht über customHeaders, weil IIS diesen Header nach der Stufe schreibt, auf der customHeaders greift. Ab IIS 10 erledigt das removeServerHeader im Abschnitt für die Anfragefilterung; auf älteren Versionen braucht es eine Rewrite-Regel oder ein Modul. Es ist ein Informationsleck und keine Lücke, behandeln Sie es also als Aufräumen und nicht als Behebung.
06 Im Detail
Diese Seite ist die Konfiguration. Diese Ratgeber erklären, was jeder Header wirklich macht und wie Sie seinen Wert wählen.
Was jeder Response-Header bewirkt, welche Ihre Website senden sollte und wie Sie sie richtig konfigurieren.
Der stärkste Schutz gegen Cross-Site-Scripting: welche Direktiven Sie setzen, wie Sie eine Richtlinie im Report-Only-Modus einführen und wie Sie erzwingend werden, ohne Ihre Website zu zerlegen.
Strict-Transport-Security erklärt: was max-age, includeSubDomains und preload wirklich bewirken und warum die Preload-Liste eine Entscheidung ist, die Sie nicht schnell zurücknehmen können.
Secure, HttpOnly und SameSite: die Cookie-Attribute, die eine Sitzung vor Skripten und fremden Seiten schützen, samt Einstellungen für einen typischen Stack.
Wie eine unsichtbare Überlagerung aus einem Besucherklick eine Aktion auf Ihrer Website macht, und die zwei Header, die das verhindern: X-Frame-Options für ältere Clients, frame-ancestors für alles andere.
Welcher Teil Ihrer URLs an fremde Seiten geht, wenn ein Besucher weiterklickt: die fünf Werte, die zählen, was jeder davon preisgibt und welcher der sinnvolle Standard ist.
Kamera, Mikrofon, Standort und Bezahlfunktion für Ihre Website und alle eingebetteten Inhalte abschalten: die Syntax der Positivliste und warum eine nicht genannte Funktion keine abgeschaltete Funktion ist.
Die Einträge, die verhindern, dass jemand in Ihrem Namen Mails verschickt, und der, der Ihre DNS-Antworten ehrlich hält: was jeder leistet und in welcher Reihenfolge Sie sie einführen.
Die Datei, die Sicherheitsforschern sagt, wohin eine Schwachstelle gemeldet wird. Zwei Pflichtfelder, zehn Minuten Arbeit, und der Unterschied zwischen einer privaten und einer öffentlichen Meldung.
Ein Header, der heute stimmt, kann nach dem nächsten Deploy fehlen. Drei Wege, das zu bemerken: ein Cronjob mit curl, eine Prüfung in Ihrer CI-Pipeline und ein geplanter Scan, jeweils mit dem, was er findet und was nicht.
Wie sich eine Richtlinie durch Deploys, Plugins und CDN-Regeln unbemerkt ändert und wie Sie es merken: ein Header-Diff, Verstoßmeldungen über report-to und was ein Scan-Vergleich zeigen kann und was nicht.
Weiterlesen
Jeder Ratgeber steht für sich, zusammen decken sie ab, worauf unser Scanner schaut. Wählen Sie den, der Ihrer nächsten Frage am nächsten kommt.
Unser kostenloser Quickscan liest die Header aus Ihrer ausgelieferten Antwort und nicht aus Ihrer web.config, und erklärt jeden Befund verständlich.