EN

Sicherheits-Headern und Vermeidung von Sicherheitslücken

In diesem Artikel:

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

Security Assessment Increase TLS Key Size

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:

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:

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-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;
}
How to enable security headers and how to prevent vulnerabilities visually represented in a graphic - Crashtest Security

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:

WertWirkung
denyKeine Frames von dieser Website zulassen
sameoriginFrames dieser Website zulassen, wenn die Domain übereinstimmt
allow-from DOMAINErlaubt 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.

WertWirkung
0Deaktivieren des Filters
1Aktivieren des Filters, um die Webseite im Falle eines Angriffs zu sanitisieren
1; mode=blockAktivieren 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.

WertWirkung
nosniffNur 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.

WertWirkung
NoneDas Cookie wird in allen Kontexten gesendet.
LaxCookie 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.
StrictVerhindern 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.

WertWirkung
default-scr ’self‘ resources.example.orgDefiniert das Laden aller Ressourcentypen von der eigenen Domäne und resources.example.org
script-src ’self‘ scripts.example.orgErmö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.orgErmöglicht das Laden von Stylesheets aus der eigenen Domain und style.example.org
img-src ’self‘ imgs.example.orgErmöglicht das Laden von Bildern von der eigenen Domäne und von imgs.example.org
media-scr ’self‘ media.example.orgErmö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.orgErmöglicht das Laden von Schriftarten aus der eigenen Domain und fonts.example.org
connect-src ’self‘ api.example.orgErmö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
sandboxAktiviert 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-contentVerhindert, dass der Browser gemischte Inhalte lädt (z. B. gemischte HTTP- und https-Elemente)
upgrade-insecure-requestsAlle 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.

WertWirkung
no-referrerKeine Referrer-Informationen in Anfragen aufnehmen
no-referrer-when-downgradeDen Referrer nicht senden, wenn die aktuelle Verbindung eine https-Anfrage ist und die neue Anfrage HTTP ist
originSendet den Ursprung als Referrer, enthält aber keine Pfadinformationen
origin-when-cross-originDen Ursprung als Referrer senden, wenn die neue Anfrage von einer anderen Domäne stammt, und alle Informationen für Fälle gleichen Ursprungs
same-originSendet den Referrer nur, wenn die Anfrage in der aktuellen Domain bleibt
strict-originSendet den Ursprung als Referrer, aber nur wenn die Anfrage kein Downgrade von https zu HTTP ist
strict-origin-when-cross-originDen 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-urlImmer 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.

WertWirkung
must-revalidateDer Cache muss den Zustand der Ressource überprüfen, bevor er sie verwendet.
no-cacheDie Anfrage wird auch dann gesendet, wenn der Cache die Ressource gespeichert hat.
no-storeKeine Speicherung der Ressource in einem Cache
no-transformDie Ressource nicht umwandeln (z. B. das Bildformat ändern, um Cache-Speicherplatz zu sparen)
publicErlaubt das Speichern der Ressource in einem beliebigen Cache
privateErlaubt die Speicherung der Ressource in einem benutzerspezifischen Cache, aber nicht in einem gemeinsamen Cache
proxy-revalidateDasselbe 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.org

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

Präventionsleitfaden für SSL/TLS-Schwachstellen

Leitfaden

Erfahren Sie, wie Sie verschiedene Arten von SSL/TLS-Schwachstellen erkennen und verhindern können.

Mehr erfahren

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.

Erhalten Sie jetzt kostenlos einen schnellen Sicherheitsbericht für Ihre Website

Wir analysieren derzeit https://example.com
Wir scannen derzeit https://example.com
Status des Scans: In Bearbeitung
Scan target: http://example.com/laskdlaksd/12lklkasldkasada.a
Datum: 16/09/2023
Crashtest Security Suite prüft auf:
Information disclosure Known vulnerabilities SSL misconfiguration Open ports
Scanauftrag ausfüllen
Bitte geben Sie Ihre Daten ein, um die schnelle Sicherheitsüberprüfung zu erhalten.
Ein Sicherheitsspezialist analysiert gerade Ihren Scan-Bericht.
Bitte geben Sie Ihre Telefon-/Handynummer an, damit wir Ihre Identität überprüfen können:
Vielen Dank.
Wir haben Ihren Antrag erhalten.
Sobald Ihr Sicherheitsaudit fertig ist, werden wir Sie benachrichtigen.