O.Arch 9: Unterschied zwischen den Versionen

Aus d.hack
Keine Bearbeitungszusammenfassung
Zeile 5: Zeile 5:
Verwendung von dem Stand der Technik entsprechenden HTTP-Server-Headern.
Verwendung von dem Stand der Technik entsprechenden HTTP-Server-Headern.


== Anmerkungen ==
==== Prüftiefe ====
<br />
== Testcharakteristik ==
== Testcharakteristik ==
==== Prüftiefe ====
==== Prüftiefe ====
Zeile 15: Zeile 18:
| Der Evaluator validiert (englisch „check“, analog zu Begriffsverwendung in der Common Criteria Evaluation Methodology) die vom Hersteller beschriebene Maßnahme im Hinblick auf ihre Wirksamkeit und räumt bestehende Zweifel (Plausibilitätsprüfung) aus, ob der Prüfaspekt und die damit verbundene Sicherheitsproblematik umfassend durch die beschriebenen Maßnahmen adressiert wird. Hierbei [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03161/BSI-TR-03161-2.pdf?__blob=publicationFile&v=10#%5B%7B%22num%22%3A15%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C54%2C243%2C0%5D MUSS] der Evaluator den aktuellen Stand der Technik für die jeweilige Plattform mitberücksichtigen. Die Validierung [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03161/BSI-TR-03161-2.pdf?__blob=publicationFile&v=10#%5B%7B%22num%22%3A15%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C54%2C243%2C0%5D KANN] weitergehende Schritte, wie z.B. eine Quelltextanalyse, umfassen, falls der Evaluator diese für eine umfassende Einschätzung benötigt.
| Der Evaluator validiert (englisch „check“, analog zu Begriffsverwendung in der Common Criteria Evaluation Methodology) die vom Hersteller beschriebene Maßnahme im Hinblick auf ihre Wirksamkeit und räumt bestehende Zweifel (Plausibilitätsprüfung) aus, ob der Prüfaspekt und die damit verbundene Sicherheitsproblematik umfassend durch die beschriebenen Maßnahmen adressiert wird. Hierbei [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03161/BSI-TR-03161-2.pdf?__blob=publicationFile&v=10#%5B%7B%22num%22%3A15%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C54%2C243%2C0%5D MUSS] der Evaluator den aktuellen Stand der Technik für die jeweilige Plattform mitberücksichtigen. Die Validierung [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03161/BSI-TR-03161-2.pdf?__blob=publicationFile&v=10#%5B%7B%22num%22%3A15%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C54%2C243%2C0%5D KANN] weitergehende Schritte, wie z.B. eine Quelltextanalyse, umfassen, falls der Evaluator diese für eine umfassende Einschätzung benötigt.
|}
|}
<br />


==== Ergänzende Informationen für Evaluatoren ====
==== Ergänzende Informationen für Evaluatoren =====
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.
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 ==
== 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 Schwachstellen zu verbessern. Sie bieten eine wichtige Sicherheitsebene, um Benutzer und Daten vor Bedrohungen zu schützen [https://www.tutkit.com/de/blog/200-security-headers-fuer-deine-website-gut-fuer-sicherheit-und-seo].
Bekannte Sicherheitsheader sind beispielsweise:
# [https://content-security-policy.com/ Content Security Policy (CSP)] {{#set: has SecurityHeader=CSP}}
# [https://http.dev/x-content-type-options X-Content-Type-Options] {{#set: has SecurityHeader=X-Content-Options}}
# [https://www.w3.org/TR/referrer-policy/ Referrer-Policy] {{#set: has SecurityHeader=Referrer-Policy}}
# [https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html Strict-Transport-Security (HSTS) ] {{#set: has SecurityHeader=HSTS}}
# [https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html X-Frame-Options] {{#set: has SecurityHeader=X-Frame-Options}}
# [https://www.w3.org/TR/permissions-policy/ Permission-Policy] {{#set: has SecurityHeader=Permission-Policy}}
# [https://www.ibm.com/docs/de/control-desk/7.6.1.x?topic=checklist-vulnerability-web-browser-xss-protection X-XSS-Protection] {{#set: has SecurityHeader=X-XSS-Protection}}
<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-Content-Header
:Die X-Content-Type-Options sind ein Sicherheitsheader, der den Browser anweist, den MIME-Typ von Ressourcen nicht zu erraten und ihnen stattdessen zu vertrauen, wie er vom Server bereitgestellt wird.
<syntaxhighlight lang="bash" style="border: 3px dashed blue;">
# Beispielkonfiguration eines Apache-Servers zu Verwendung von X-Content-Header
X-Content-Type-Options: nosniff
</syntaxhighlight>
<br />
;Referrer-Policy
:Der Referrer-Policy-Header legt die Richtlinie für das Übermitteln von Referrern fest, wenn der Benutzer von einer anderen Website aus auf Ihre Seite zugreift.
<syntaxhighlight lang="bash" style="border: 3px dashed blue;">
# Beispielkonfiguration eines Apache-Servers zu Verwendung von Referrer-Policy
Referrer-Policy: strict-origin-when-cross-origin
</syntaxhighlight>
In diesem Beispiel wird der Referrer nur weitergegeben, wenn die Herkunfts-URL dieselbe ist, ansonsten wird er auf den Ursprung reduziert.
<br />
<br />
;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 />
;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>
<br />
;Permission-Policy
:Die Permission-Policy legt die Berechtigungen fest, die eine Webseite anfordern kann.
<syntaxhighlight lang="bash" style="border: 3px dashed blue;">
# Beispielkonfiguration eines Apache-Servers zu Verwendung von Permission-Policy
Permissions-Policy: geolocation=(), microphone=()
</syntaxhighlight>
In diesem Beispiel sind die Berechtigungen für die Geolokalisierung und das Mikrofon deaktiviert.
<br />
<br />
;X-XSS-Protection
:Der X-XSS-Protection-Header aktiviert den XSS-Schutz im Browser und verhindert das Laden einer Seite, wenn ein XSS-Angriff erkannt wird.
<syntaxhighlight lang="bash" style="border: 3px dashed blue;">
# Beispielkonfiguration eines Apache-Servers zu Verwendung von X-XSS-Protection
X-XSS-Protection: 1; mode=block
</syntaxhighlight>
Der Modus block verhindert, dass der Browser versucht, die Seite zu reparieren, wenn ein XSS-Angriff festgestellt wird.
<br />
<br />
=== Validierung ===
Die Implementierung von Security Header ist auf unterschiedliche Weisen möglich:
;Manuell im Webbrowser
:Durch das Wechseln in die Entwicklertools des Webbrowsers kann man die gesendeten Header im Reiter Netzwerk überprüfen.
;Online-Tools
:Die Anwendung der Security Headers kann beispielsweise mit [https://securityheaders.com/ SecurityHeaders.com] {{#set: has PentestingTool=SecurityHeaders.com}} validiert werden.


== Weblinks ==
== Weblinks ==
[https://content-security-policy.com/ Content Security Policy] {{#set: has Literacy=Content Security Policy}}
[https://http.dev/x-content-type-options X-Content-Type-Options] {{#set: has Literacy=X-Content-Type-Options}}
[https://www.w3.org/TR/referrer-policy/ Referrer-Policy] {{#set: has Literacy=Referrer-Policy}}
[https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html Strict-Transport-Security (HSTS) ] {{#set: has Literacy=HSTS}}
[https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html X-Frame-Options] {{#set: has Literacy=X-Frame-Options}}
[https://www.w3.org/TR/permissions-policy/ Permission-Policy] {{#set: has Literacy=Permission-Policy}}
[https://www.ibm.com/docs/de/control-desk/7.6.1.x?topic=checklist-vulnerability-web-browser-xss-protection X-XSS-Protection] {{#set: has Literacy=X-XSS-Protection}}


== Ressourcen und Einzelnachweise ==
== Ressourcen und Einzelnachweise ==
[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03161/BSI-TR-03161-2.pdf?__blob=publicationFile&v=8] Bundesamt für Sicherheit in der Informationstechnik & Referat DI 24. (2024a). ''Technische Richtlinie TR-03161: Anforderungen an Anwendungen im Gesundheitswesen Teil 2: Web-Anwendungen.'' https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03161/BSI-TR-03161-2.pdf?__blob=publicationFile&v=8
[https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html HTTP_Headers_Cheat_Sheet] {{#set: has Literacy=HTTP_Headers_Cheat_Sheet}}
[https://www.tutkit.com/de/blog/200-security-headers-fuer-deine-website-gut-fuer-sicherheit-und-seo Matthias Petri:Security Headers für deine Website: gut für Sicherheit und SEO] aufgerufen am 15.05.2024 {{#set: has Literacy=Matthias Petri:Security Headers für deine Website: gut für Sicherheit und SEO}}
[https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security HTTP-Strict-Transport-Security (HSTS)] {{#set: has Literacy=HSTS}}


[[Category:Pruefaspekt]]
[[Category:CHECK]]
[[Category:CHECK]]
[[Category: Arch]]

Version vom 25. Juli 2024, 13:00 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


Testcharakteristik

Prüftiefe

Bezeichnung Mindestanforderungen an die Prüfung
CHECK Der Evaluator validiert (englisch „check“, analog zu Begriffsverwendung in der Common Criteria Evaluation Methodology) die vom Hersteller beschriebene Maßnahme im Hinblick auf ihre Wirksamkeit und räumt bestehende Zweifel (Plausibilitätsprüfung) aus, ob der Prüfaspekt und die damit verbundene Sicherheitsproblematik umfassend durch die beschriebenen Maßnahmen adressiert wird. Hierbei MUSS der Evaluator den aktuellen Stand der Technik für die jeweilige Plattform mitberücksichtigen. Die Validierung KANN weitergehende Schritte, wie z.B. eine Quelltextanalyse, umfassen, falls der Evaluator diese für eine umfassende Einschätzung benötigt.


Ergänzende Informationen für Evaluatoren =

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

Weblinks

Ressourcen und Einzelnachweise