Sicherheits-Header können eine Reihe von Cyber-Bedrohungen abwehren. Sie werden auch als sicherheitsbezogene HTTP-Antwort-Header bezeichnet und verändern das Verhalten von Webbrowsern, um Sicherheitslücken zu vermeiden.
Ihre Verwendung ist zwar mit einigen Einschränkungen in Bezug auf die Browserfunktionen verbunden, doch können Sicherheits-Header eine große Hilfe bei der Verhinderung vieler gängiger Angriffe sein, darunter Cross-Site Scripting und Clickjacking. Darüber hinaus können sie eine zusätzliche Sicherheitsebene für Ihre Webanwendungen bieten.
Sehen wir uns im Folgenden die möglichen Schwachstellen und die Methoden zur Aktivierung von Sicherheits-Headern in modernen Browsern an.
Sicherheitsheader Sicherheitsbewertungsstufe
CVSS-Vektor: AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Was sind Sicherheits-Header
Es handelt sich um Richtlinien zur Erhöhung des Schutzes und zur Verbesserung der Abwehr vor Cyberangriffen in Browsern. Sie ändern zum Beispiel das Verhalten von Webbrowsern, um Sicherheitslücken zu vermeiden und nur eine Art von gültigem Serverzertifikat wie z.B. TLS zu akzeptieren.
Zu den Arten von Sicherheits-Headern gehören:
- HTTP Strict Transport Security (HSTS)
- Content Security Policy (CSP)
- HTTP Public Key Pinning (HPKP)
Wie Sicherheitsheader Sicherheitslücken verhindern können
Das Einfügen eines Sicherheits-Headers kann eine Vielzahl von Hacking-Versuchen verhindern.
Im OWASP Secure Headers Project finden Sie die wichtigsten HTTP-Antwort-Header, die Sicherheit und Benutzerfreundlichkeit bieten.
Hier sind einige der Schwachstellen, die Sie durch die Verwendung eines Security Headers vermeiden können:
- Protokoll-Downgrade-Angriffe wie Poodle
- Content Injection-Angriffe wie XSS und Clickjacking
- Reflektierte XSS-Angriff
- Cross-Site Request Forgery-Angriff
- Cross-Site Scripting-Angriff
Bevor Sie einen sicherheitsrelevanten HTTP-Response-Header zur Verhinderung von Angriffen einsetzen, sollten Sie prüfen, ob er mit den Browsern, auf die Sie abzielen, kompatibel ist.
Wie man Sicherheits-Header aktiviert
Um die Sicherheitsheader für Ihre Webanwendung korrekt einzustellen, können Sie die folgenden Anleitungen verwenden:
- Webserver Configuration (Apache, Nginx, and HSTS)
- X-Frame-Options
- X-XSS-Protection
- X-Content-Type-Options
- Same-Site Cookie
- Content-Security-Policy
- Referrer-Policy
- Cache-Control
- Access-Control-Allow-Origin
Webserver-Konfiguration (Apache, Nginx und HSTS)
Um Ihren Webserver zu konfigurieren, können Sie die unten beschriebenen Einstellungen für Apache, Nginx und HTTP Strict Transport Security (HSTS) vornehmen.
Apache-Sicherheits-Header
Für Apache müssen Sie Ihre Konfiguration aktualisieren, um die richtigen Header-Direktiven aufzunehmen.
Fügen Sie dies der Konfiguration des virtuellen Hosts in /etc/apache2/sites-enabled/domain.conf oder /etc/httpd/sites-enabled/domain.conf hinzu:
<VirtualHost *:443>
Header always set Strict-Transport-Security "max-age=31536000"
Header always set X-Frame-Options "deny"
Header always set X-XSS-Protection "1; mode=block"
Header always set X-Content-Type-Options "nosniff"
Header always set Content-Security-Policy "default-src 'self'"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</VirtualHost>Nginx Sicherheits-Header
Für nginx müssen Sie die Konfigurationsdatei aktualisieren. Sie befindet sich normalerweise unter /etc/nginx/nginx.conf, /etc/nginx/sited-enabled/yoursite.com (Ubuntu / Debian) oder /etc/nginx/conf.d/nginx.conf (RHEL / CentOS).
Fügen Sie den folgenden Header mit den add_header-Anweisungen ein:
server {
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains;" always;
add_header X-Frame-Options "deny" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'self'" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}
HTTP Strict Transport Security (HSTS)
Der HSTS-Header erzwingt HTTPS-Verbindungen. Dies verhindert Downgrade-Angriffe, die eine unsichere HTTP-Verbindung beeinträchtigen können. Die richtigen Einstellungen finden Sie in unserer Anleitung zur Aktivierung von HSTS.
X-Frame-Options
Der Antwort-Header X-Frame-Options legt fest, ob eine Website als Frame in andere Websites eingebettet werden kann.
Die Header-Werte sind:
| Wert | Wirkung |
| deny | Keine Frames von dieser Website zulassen |
| sameorigin | Frames dieser Website zulassen, wenn die Domain übereinstimmt |
| allow-from DOMAIN | Erlaubt Frames dieser Website, wenn sie in Webseiten auf DOMAIN eingebettet sind |
Wenn Sie den HTTP-Header X-Frame-Options auf deny setzen, schützen Sie die Website vor Clickjacking-Angriffen. Dadurch wird verhindert, dass ein Angreifer den Iframe der Webseite mit beliebigen Inhalten überlagert, um die Opfer zu ködern, auf bestimmte Links zu klicken.
X-XXS-Schutz
Einige Webbrowser sind mit einem Cross-Site-Scripting (XSS)-Filter ausgestattet. Dieser kann bestimmte XSS-Angriffe erkennen und abwehren. Um den Browserfilter zu konfigurieren, verwenden Sie den X-XSS-Protection-Header.
| Wert | Wirkung |
| 0 | Deaktivieren des Filters |
| 1 | Aktivieren des Filters, um die Webseite im Falle eines Angriffs zu sanitisieren |
| 1; mode=block | Aktivieren des Filters, um die Webseite im Falle eines Angriffs zu blockieren |
Das Setzen dieses Headers 1; mode=block weist den Browser an, die Webseite nicht zu rendern, wenn ein Angriff erkannt wird.
X-Content-Type-Options
Browser versuchen, den MIME-Typ der Dateien zu erkennen, die der Webserver sendet.
Wenn ein Angreifer eine bösartige ausführbare Datei auf einen Webserver hochlädt, der nur Bilder sendet, kann die MIME-Typ-Erkennung einen gewissen Schutz bieten. Sie teilt dem Browser mit, dass er ein Bild und keine ausführbare Datei erwarten sollte. Infolgedessen sollte der Browser nicht versuchen, den MIME-Typ zu erkennen, sondern nur den vom Webserver bereitgestellten MIME-Typ verwenden.
Sie können dies aktivieren, indem Sie den X-Content-Type-Options-Header verwenden und ihn auf nosniff setzen.
| Wert | Wirkung |
| nosniff | Nur den deklarierten MIME-Typ verwenden |
Same-Site-Cookie
Das Setzen eines Cookie-Flags verhindert das Austreten von Informationen zwischen den Seiten und kann dazu beitragen, Cross-Site Request Forgery-Angriffe abzuschwächen.
Sie können das Same-Site-Cookie-Flag verwenden, um den Browser daran zu hindern, Cookies zusammen mit Site-übergreifenden Anfragen zu senden. Mögliche Werte sind Strict, Lax oder None.
Wenn das Same-Site-Cookie-Flag auf None gesetzt ist, muss das Secure-Flag gesetzt sein, um das Senden des Cookies in einem unsicheren Kontext zu verhindern.
| Wert | Wirkung |
| None | Das Cookie wird in allen Kontexten gesendet. |
| Lax | Cookie wird gesendet, wenn ein Benutzer einem Link zu Ihrer Website folgt. Das Cookie wird jedoch nicht gesendet, wenn der Inhalt Ihrer Website in eine Website eines Drittanbieters eingebunden wird. |
| Strict | Verhindern Sie, dass das Cookie bei allen seitenübergreifenden Anfragen an die Zielsite gesendet wird, auch wenn ein Benutzer einem Link zu Ihrer Site folgt. |
Content-Security-Policy
Durch Setzen des Headers Content-Security-Policy können Sie dem Webbrowser mitteilen, von welchen Domänen er weitere Ressourcen wie Skripte, Bilder oder Stylesheets laden darf.
Dies kann verschiedene Cross-Site-Scripting (XSS) und andere Cross-Site-Injection-Angriffe verhindern. Die Richtlinie des HTTP-Headers Content-Security-Policy muss für die jeweilige Verwendung angepasst werden, da sie leicht das Laden von Analyseskripten, Schriftarten oder anderen Ressourcen von Dritten verhindern kann.
| Wert | Wirkung |
| default-scr ’self‘ resources.example.org | Definiert das Laden aller Ressourcentypen von der eigenen Domäne und resources.example.org |
| script-src ’self‘ scripts.example.org | Ermöglicht das Laden von Skripten aus der eigenen Domain und von scripts.example.org |
| object-src ’none‘ | Verbietet das Laden aller Objekte wie <applet>, <embed> und <object> |
| style-src ’self‘ style.example.org | Ermöglicht das Laden von Stylesheets aus der eigenen Domain und style.example.org |
| img-src ’self‘ imgs.example.org | Ermöglicht das Laden von Bildern von der eigenen Domäne und von imgs.example.org |
| media-scr ’self‘ media.example.org | Ermöglicht das Laden von Medienelementen von der eigenen Domain und media.example.org |
| child-src ’self‘ | Definieren Sie, dass in <frame>- und <iframe>-Elementen nur Seiten aus der eigenen Domain geladen werden dürfen |
| font-src ’self‘ fonts.example.org | Ermöglicht das Laden von Schriftarten aus der eigenen Domain und fonts.example.org |
| connect-src ’self‘ api.example.org | Ermöglicht Verbindungen über Skriptschnittstellen wie XMLHttpRequest oder WebSocket zur eigenen Domain und api.example.org |
| manifest-src ’self‘ | Ermöglicht das Laden von Manifesten aus der eigenen Domain |
| frame-ancestors ’self‘ | Legt fest, dass diese Seite nur als Frame auf Seiten der eigenen Domain verwendet werden darf |
| form-action ’self‘ | Stellt sicher, dass Formular-Aktionen nur von der eigenen Domain sein können |
| sandbox | Aktiviert eine Sandbox, die die meisten Aktionen auf der Seite blockiert. Mehr Informationen: CSP: sandbox |
| plugin-types application/x-java-applet | Ermöglicht die Einbettung eines <applet>. Dies funktioniert nur, wenn object-src nicht auf ’none‘ gesetzt ist. |
| block-all-mixed-content | Verhindert, dass der Browser gemischte Inhalte lädt (z. B. gemischte HTTP- und https-Elemente) |
| upgrade-insecure-requests | Alle Ressourcen über eine https-Verbindung herunterladen |
Eine unkomplizierte Richtlinie kann default-src ’self‘ sein. Stellen Sie jedoch sicher, dass Sie Ihre Konfiguration gründlich testen, damit Ihr Analyseskript oder andere Ressourcen von Dritten nicht blockiert werden.
Referrer-Policy
Der Referrer-Policy-Header legt fest, wie viele Informationen über den Referrer gesendet werden, wenn der Nutzer auf einen Link klickt.
Der Referrer kann sensible Informationen preisgeben, wie z. B. benutzerspezifische URLs. Sie können die Referrer-Policy möglicherweise auf einen restriktiveren Wert setzen.
Eine relativ sichere Einstellung ist strict-origin-when-cross-origin.
| Wert | Wirkung |
| no-referrer | Keine Referrer-Informationen in Anfragen aufnehmen |
| no-referrer-when-downgrade | Den Referrer nicht senden, wenn die aktuelle Verbindung eine https-Anfrage ist und die neue Anfrage HTTP ist |
| origin | Sendet den Ursprung als Referrer, enthält aber keine Pfadinformationen |
| origin-when-cross-origin | Den Ursprung als Referrer senden, wenn die neue Anfrage von einer anderen Domäne stammt, und alle Informationen für Fälle gleichen Ursprungs |
| same-origin | Sendet den Referrer nur, wenn die Anfrage in der aktuellen Domain bleibt |
| strict-origin | Sendet den Ursprung als Referrer, aber nur wenn die Anfrage kein Downgrade von https zu HTTP ist |
| strict-origin-when-cross-origin | Den Ursprung als Referrer bei herkunftsübergreifenden Anfragen und den vollständigen Referrer bei Anfragen gleichen Ursprungs senden, aber nur, wenn die Anfrage kein Downgrade ist |
| unsafe-url | Immer die vollständige URL als Referrer senden |
Cache-Kontrolle
With the Cache-Control header, you can control the configuration of the caching in the bMit dem Cache-Control-Header können Sie die Konfiguration der Zwischenspeicherung im Browser steuern.
Je nach Wert des Headers kann der Browser die Website zwischenspeichern, einschließlich aller vertraulichen Informationen. Für Seiten, bei denen Vertraulichkeit ein Thema ist, ist es daher am besten, den Header auf „no-store“ zu setzen.
| Wert | Wirkung |
| must-revalidate | Der Cache muss den Zustand der Ressource überprüfen, bevor er sie verwendet. |
| no-cache | Die Anfrage wird auch dann gesendet, wenn der Cache die Ressource gespeichert hat. |
| no-store | Keine Speicherung der Ressource in einem Cache |
| no-transform | Die Ressource nicht umwandeln (z. B. das Bildformat ändern, um Cache-Speicherplatz zu sparen) |
| public | Erlaubt das Speichern der Ressource in einem beliebigen Cache |
| private | Erlaubt die Speicherung der Ressource in einem benutzerspezifischen Cache, aber nicht in einem gemeinsamen Cache |
| proxy-revalidate | Dasselbe wie must-revalidate für gemeinsam genutzte Caches |
| max-age=<seconds> | Legen Sie fest, wie lange die Ressource als frisch behandelt werden soll |
| s-maxage=<seconds> | Überschreibt einen max-age- oder Expires-Header, wird aber nur für gemeinsam genutzte Caches verwendet |
Access-Control-Allow-Origin
Der Access-Control-Allow-Origin Header legt fest, welche Anwendungen Ihre API nutzen können.
Setzen Sie ihn auf die Domain Ihres Frontends, z.B.:
Access-Control-Allow-Origin: https://example.orgWenn Ihre API von mehreren Anwendungen genutzt wird, können Sie unsere Ressource zu Access-Control-Allow-Origin mit mehreren Werten konsultieren.
Benötigen Sie mehr Anwendungssicherheit? Mit der Software von Crashtest Security zum Testen von Schwachstellen können Sie Schwachstellen in der Cybersicherheit und verschiedene Arten von Angriffen auf Ihre Anwendungen aufdecken.
Leitfaden
Erfahren Sie, wie Sie verschiedene Arten von SSL/TLS-Schwachstellen erkennen und verhindern können.
Verwenden Sie ein Scanner-Tool, um die Angriffe zu verhindern
Eine weitere Möglichkeit, verschiedenen Angriffen vorzubeugen, ist der Einsatz eines automatisierten Schwachstellen-Scanners, der Ihre Website kontinuierlich überprüft.
- Sie erhalten einen Bericht mit allen Sicherheitskopfzeilen, die Sie anpassen müssen.
- Entdecken Sie neue Cybersicherheitsschwachstellen, durch die Sie Angriffen ausgesetzt sind, wie z. B. die Risiken der OWASP-10-Liste.
- Sie erhalten Zugang zu einem exklusiven Wiki mit Artikeln über Behebungsmaßnahmen und Prävention für Ihre Website.
Für Unternehmen ist dies wichtig, da es heutzutage nicht einfach ist, die richtigen Einstellungen zur Vermeidung von Angriffen zu treffen. Es erfordert Zeit von den Entwicklern und das entsprechende Budget des Unternehmens. Testen Sie diese neue Software für HTTP Header Schwachstellentests, um Ihre Daten und die Ihrer Kunden auf einfache und budgetfreundliche Weise zu schützen.
