O.Arch 9: Unterschied zwischen den Versionen

Aus d.hack
Zeile 24: Zeile 24:
# [https://www.w3.org/TR/permissions-policy/ Permission-Policy]
# [https://www.w3.org/TR/permissions-policy/ Permission-Policy]
# [https://www.ibm.com/docs/de/control-desk/7.6.1.x?topic=checklist-vulnerability-web-browser-xss-protection X-XSS-Protection]
# [https://www.ibm.com/docs/de/control-desk/7.6.1.x?topic=checklist-vulnerability-web-browser-xss-protection X-XSS-Protection]
;HTTP Strict Transport Security (HSTS):
:HSTS stellt sicher, dass die Webanwendung ausschließlich über eine verschlüsselte Verbindung (HTTPS) erreichbar ist und schützt somit vor man-in-the-middle-Angriffen.
<syntaxhighlight lang="bash" style="border: 3px dashed blue;">
# Beispielkonfiguration eines Apache-Servers zu Verwendung von HSTS
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</syntaxhighlight>
<br />
;Content Security Policy (CSP)
:CSP legt fest, welche Ressourcen auf einer Seite geladen werden dürfen und hilft so, Cross-Site-Scripting (XSS)-Angriffe zu verhindern.
<syntaxhighlight lang="bash" style="border: 3px dashed blue;">
# Beispielkonfiguration eines Apache-Servers zu Verwendung von CSP
Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com
</syntaxhighlight>
<br />
;X-Frame-Option
:X-Frame-Options verhindert das Laden der Webseite in einem <frame>, <iframe> oder <object> und schützt so vor Clickjacking-Angriffen.
<syntaxhighlight lang="bash" style="border: 3px dashed blue;">
# Beispielkonfiguration eines Apache-Servers zu Verwendung von x-Frame-Options
X-Frame-Options: DENY
</syntaxhighlight>


== Weblinks ==
== Weblinks ==

Version vom 15. Mai 2024, 10:38 Uhr

Beschreibung

Die Web-Anwendung SOLL HTTP-Server-Header nutzen, die dem aktuellen Stand der Technik entsprechen und die Sicherheit der Anwendung erhöhen. Dazu gehören unter anderem HTTP Strict Transport Security (HSTS), Content Security Policy (CSP) und X-Frame-Options.

Kurzfassung

Verwendung von dem Stand der Technik entsprechenden HTTP-Server-Headern.

Anmerkungen

Prüftiefe


CHECK


Der Evaluator prüft, ob entsprechende HTTP-Server-Header verwendet werden. Falls keine dem Stand der Technik entsprechenden HTTP-Server-Header verwendet werden, ist dies in der Risikobewertung zu berücksichtigen.

Lösungsansätze

Implementierung

Security Headers
Security Headers sind HTTP-Header, die auf Webseiten und Webanwendungen verwendet werden, um die Sicherheit und den Schutz vor verschiedenen Arten von Angriffen und Sicherheitslücken zu verbessern. Sie bieten eine wichtige Sicherheitsebene, um Benutzer und Daten vor Bedrohungen zu schützen [1].

Bekannte Sicherheitsheader sind beispielsweise:

  1. Content Security Policy (CSP)
  2. X-Content-Type-Options
  3. Referrer-Policy
  4. Strict-Transport-Security (HSTS)
  5. X-Frame-Options
  6. Permission-Policy
  7. X-XSS-Protection
HTTP Strict Transport Security (HSTS)
HSTS stellt sicher, dass die Webanwendung ausschließlich über eine verschlüsselte Verbindung (HTTPS) erreichbar ist und schützt somit vor man-in-the-middle-Angriffen.
# Beispielkonfiguration eines Apache-Servers zu Verwendung von HSTS
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"


Content Security Policy (CSP)
CSP legt fest, welche Ressourcen auf einer Seite geladen werden dürfen und hilft so, Cross-Site-Scripting (XSS)-Angriffe zu verhindern.
# Beispielkonfiguration eines Apache-Servers zu Verwendung von CSP
Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com


X-Frame-Option
X-Frame-Options verhindert das Laden der Webseite in einem <frame>, <iframe> oder <object> und schützt so vor Clickjacking-Angriffen.
# Beispielkonfiguration eines Apache-Servers zu Verwendung von x-Frame-Options
X-Frame-Options: DENY

Weblinks

Content Security Policy

X-Content-Type-Options

Referrer-Policy

Strict-Transport-Security (HSTS)

X-Frame-Options

Permission-Policy

X-XSS-Protection

Ressoucen und Einzelnachweise