O.Arch 9: Unterschied zwischen den Versionen
D.hack (Diskussion | Beiträge) |
D.hack (Diskussion | Beiträge) |
||
(91 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
== Beschreibung == | == Beschreibung == | ||
[[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. | 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 == | == Kurzfassung == | ||
[[Kurzfassung:: | |||
Verwendung von dem Stand der Technik entsprechenden HTTP-Server-Headern. | Verwendung von dem Stand der Technik entsprechenden HTTP-Server-Headern. | ||
]] | |||
== | == Testcharakteristik == | ||
==== Prüftiefe ==== | ==== Prüftiefe ==== | ||
{|class="wikitable" style="width:50%; border: 1px solid black;" | |||
:: | |- | ||
! style="background-color: #f2f2f2;" | Bezeichnung | |||
! style="background-color: #f2f2f2;" | Mindestanforderungen an die Prüfung | |||
|- | |||
| [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%3A65%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C54%2C725%2C0%5D 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 [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 /> | <br /> | ||
==== Ergänzende Informationen für Evaluatoren ==== | |||
[[Anmerkungen:: | |||
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 == | ||
=== | === Header === | ||
====Strict Transport Security==== | |||
HTTP Strict Transport Security (auch HSTS genannt) ist ein Mechanismus zur Websicherheit, der hilft, Websites vor Protokoll-Downgrade-Angriffen und Cookie-Diebstahl zu schützen. Er ermöglicht es Webservern zu erklären, dass Webbrowser nur über sichere HTTPS-Verbindungen mit ihnen interagieren sollten und niemals über das unsichere HTTP-Protokoll. | |||
HSTS ist ein Protokoll im IETF-Standardverlauf und ist in RFC 6797 spezifiziert. Ein Server implementiert eine HSTS-Richtlinie, indem er einen Header (Strict-Transport-Security) über eine HTTPS-Verbindung bereitstellt (HSTS-Header über HTTP werden ignoriert). | |||
# | |||
====X-Frame-Options==== | |||
Der X-Frame-Options-Response-Header {{#set: Has SecurityHeader=X-Frame-Options}} (auch XFO genannt) verbessert den Schutz von Webanwendungen gegen Clickjacking. Er weist den Browser an, ob der Inhalt innerhalb von Frames angezeigt werden kann. | |||
Die Content-Security-Policy (CSP) <code>frame-ancestors</code>-Direktive macht den X-Frame-Options-Header obsolet. Wenn eine Ressource beide Richtlinien hat, wird die CSP <code>frame-ancestors</code>-Richtlinie durchgesetzt, und die X-Frame-Options-Richtlinie wird ignoriert. | |||
< | ====X-Content-Type-Options==== | ||
Das Setzen dieses Headers verhindert, dass der Browser Dateien als einen anderen MIME-Typ interpretiert als den, der im <code>Content-Type</code>-HTTP-Header angegeben ist (z. B. wird <code>text/plain</code> nicht als <code>text/css</code> behandelt). | |||
====Content-Security-Policy==== | |||
Eine Content Security Policy (auch CSP genannt) {{#set: Has SecurityHeader=Content-Security-Policy}}{{#set: Has SecurityHeader=CSP}} erfordert eine sorgfältige Anpassung und präzise Definition der Richtlinie. Wenn sie aktiviert ist, hat die CSP erhebliche Auswirkungen auf die Art und Weise, wie Browser Seiten rendern (z. B. ist Inline-JavaScript standardmäßig deaktiviert und muss ausdrücklich in der Richtlinie erlaubt werden). Die CSP verhindert eine Vielzahl von Angriffen, einschließlich Cross-Site-Scripting und anderen Cross-Site-Injektionen. | |||
====X-Permitted-Cross-Domain-Policies==== | |||
Eine Cross-Domain-Policy-Datei ist ein XML-Dokument, das einem Webclient, wie zum Beispiel Adobe Flash Player oder Adobe Acrobat (obwohl nicht unbedingt auf diese beschränkt), die Erlaubnis erteilt, Daten über verschiedene Domains hinweg zu verarbeiten. Wenn Clients Inhalte anfordern, die auf einer bestimmten Quell-Domain gehostet werden, und diese Inhalte Anfragen an eine andere Domain als ihre eigene senden, muss die entfernte Domain eine Cross-Domain-Policy-Datei bereitstellen, die den Zugriff auf die Quell-Domain gewährt, sodass der Client die Transaktion fortsetzen kann. Normalerweise wird eine Meta-Policy in der Haupt-Policy-Datei deklariert, aber für diejenigen, die nicht im Stammverzeichnis schreiben können, besteht auch die Möglichkeit, eine Meta-Policy über den HTTP-Response-Header X-Permitted-Cross-Domain-Policies zu deklarieren. | |||
====Referrer-Policy==== | |||
Der Referrer-Policy-HTTP-Header regelt, welche Referrer-Informationen, die im Referer-Header gesendet werden, in die gestellten Anfragen einbezogen werden sollen. | |||
====Clear-Site-Data==== | |||
Der Clear-Site-Data-Header löscht die Browsing-Daten (Cookies, Speicher, Cache), die mit der anfordernden Website verbunden sind. Dieser Header ist beispielsweise während eines Logout-Prozesses nützlich, um sicherzustellen, dass alle gespeicherten Inhalte auf der Client-Seite, wie Cookies, Speicher und Cache, entfernt werden. | |||
====Cross-Origin-Resource-Policy==== | |||
Dieser Response-Header (auch CORP genannt) ermöglicht es, eine Richtlinie zu definieren, die Websites und Anwendungen schützt, indem sie sich gegen bestimmte Anfragen von anderen Ursprüngen (wie beispielsweise solchen, die mit Elementen wie <script> und <img> gesendet werden) absichern, um spekulativen Seitenkanalangriffen wie Spectre sowie Cross-Site Script Inclusion (XSSI)-Angriffen entgegenzuwirken. | |||
*CORP gilt auf der Seite der geladenen Ressource (Ressourcenbesitzer). | |||
====Cross-Origin-Embedder-Policy==== | |||
Dieser Response-Header (auch COEP genannt) verhindert, dass ein Dokument beliebige Cross-Origin-Ressourcen lädt, die dem Dokument nicht ausdrücklich die Erlaubnis erteilen. | |||
*COEP gilt auf der Seite des „Laders“ der Ressource (Verbraucher der Ressource). | |||
====Cross-Origin-Opener-Policy==== | |||
Dieser Antwort-Header (auch COOP genannt) ermöglicht es, sicherzustellen, dass ein übergeordnetes Dokument keine Browsing-Context-Gruppe mit Dokumenten von fremden Ursprüngen teilt. COOP wird das Dokument prozessisolieren, sodass potenzielle Angreifer nicht auf globale Objekte zugreifen können, wenn sie es in einem Popup-Fenster geöffnet werden. Dies verhindert eine Reihe von Cross-Origin-Angriffen, die als XS-Leaks bezeichnet werden. | |||
====Permissions Policy==== | |||
Der Permissions-Policy-Header ersetzt den bestehenden Feature-Policy-Header zur Steuerung der Delegation von Berechtigungen und leistungsstarken Funktionen. Der Header verwendet eine strukturierte Syntax und ermöglicht es Websites, genauer zu regeln, welche Ursprünge Zugriff auf Funktionen gewährt werden kann. | |||
====Cache-Control==== | |||
Dieser Header enthält Anweisungen (Direktiven) für das Caching sowohl in Anfragen als auch in Antworten. Die Angabe, ob eine Ressource zwischengespeichert werden kann, ist wichtig, um die Offenlegung von Informationen über den Cache zu verhindern. | |||
Die Header mit den Namen Expires und Pragma können zusätzlich zum Cache-Control-Header verwendet werden. Der Pragma-Header kann zur Rückwärtskompatibilität mit HTTP/1.0-Caches verwendet werden. Der Cache-Control-Header wird jedoch als die empfohlene Methode angesehen, um die Caching-Richtlinie zu definieren. | |||
===Best Practices=== | |||
{| class="wikitable" | |||
! Header !! Vorschlag für den Wert | |||
|- | |||
| Strict-Transport-Security || <code>max-age=31536000; includeSubDomains</code> | |||
|- | |||
| X-Frame-Options || <code>deny</code> | |||
|- | |||
| X-Content-Type-Options || <code>nosniff</code> | |||
|- | |||
| Content-Security-Policy || <code>default-src 'self'; form-action 'self'; object-src 'none'; frame-ancestors 'none'; upgrade-insecure-requests; block-all-mixed-content</code> | |||
|- | |||
| X-Permitted-Cross-Domain-Policies || <code>none</code> | |||
|- | |||
| Referrer-Policy || <code>no-referrer</code> | |||
|- | |||
| Clear-Site-Data || <code>"cache","cookies","storage"</code> | |||
|- | |||
| Cross-Origin-Embedder-Policy || <code>require-corp</code> | |||
|- | |||
| Cross-Origin-Opener-Policy || <code>same-origin</code> | |||
|- | |||
| Cross-Origin-Resource-Policy || <code>same-origin</code> | |||
|- | |||
| Permissions-Policy || <code>accelerometer=(), autoplay=(), camera=(), cross-origin-isolated=(), display-capture=(), encrypted-media=(), fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(self), usb=(), web-share=(), xr-spatial-tracking=(), clipboard-read=(), clipboard-write=(), gamepad=(), hid=(), idle-detection=(), interest-cohort=(), serial=(), unload=()</code> | |||
|- | |||
| Cache-Control || <code>no-store, max-age=0</code> | |||
|} | |||
=== Validierung === | |||
====Permissions-Policy zurück in Feature-Policy konvertieren==== | |||
Da der Permissions-Policy-Header noch in der Entwicklung ist und nicht gut unterstützt wird, kann es interessant sein, die beiden Formate zu verwenden, um die Abdeckung der Browser je nach ihrem Unterstützungsgrad für die Permissions-Policy und Feature-Policy-Richtlinien zu erhöhen. | |||
Der folgende Python3-Code-Schnipsel kann nützlich sein, um eine solche Konvertierung zu erreichen. | |||
<syntaxhighlight lang="python"> | |||
: | permissions_policy = 'fullscreen=(), geolocation=(self "https://game.com" "https://map.example.com"), gyroscope=(self), usb=*' | ||
feature_policy_directives = [] | |||
# | # Direktiven sammeln | ||
permissions_policy_directives = permissions_policy.split(",") | |||
# Jede Direktive verarbeiten | |||
for permissions_policy_directive in permissions_policy_directives: | |||
# Leerzeichen am Anfang und Ende entfernen | |||
directive = permissions_policy_directive.strip(" ") | |||
# Alle Anführungszeichen entfernen | |||
directive = directive.replace("\"", "") | |||
# Deaktivierungsausdruck () durch den entsprechenden in der Feature-Policy ersetzen | |||
directive = directive.replace("()", "'none'") | |||
# Schlüsselwörter angeben: self | |||
directive = directive.replace("self", "'self'") | |||
# Das Zuweisungszeichen durch ein Leerzeichen ersetzen | |||
directive = directive.replace("=", " ") | |||
# Klammern entfernen | |||
directive = directive.replace("(", "").replace(")", "") | |||
# Die aktuelle Direktive zur Sammlung hinzufügen | |||
feature_policy_directives.append(directive) | |||
# Die Sammlung der Direktiven in einen String mit ; als Trennzeichen umwandeln | |||
feature_policy = "; ".join(feature_policy_directives) | |||
print(feature_policy) | |||
</syntaxhighlight> | </syntaxhighlight> | ||
Ausführungsbeispiel: | |||
<syntaxhighlight lang="bash | <syntaxhighlight lang="bash"> | ||
$ python code.py | |||
fullscreen 'none'; geolocation 'self' https://game.com https://map.example.com; gyroscope 'self'; usb * | |||
</syntaxhighlight> | </syntaxhighlight> | ||
====Content-Security-Policy lokal auf Schwächen testen==== | |||
<syntaxhighlight lang=" | Es kann interessant sein, eine Content-Security-Policy lokal auf Schwächen zu validieren, bevor sie auf bereitgestellten Webanwendungen angewendet wird. | ||
Der folgende JavaScript-Code-Schnipsel kann nützlich sein, um eine solche Validierung durchzuführen, indem das csp-evaluator NPM-Modul von Google verwendet wird. | |||
<syntaxhighlight lang="javascript"> | |||
import {CspEvaluator} from "csp_evaluator/dist/evaluator.js"; | |||
import {CspParser} from "csp_evaluator/dist/parser.js"; | |||
const args = process.argv.slice(2) | |||
if(args.length == 0){ | |||
console.error("[!] Missing CSP!"); | |||
}else{ | |||
const csp = args[0] | |||
console.info(`[+] CSP to evaluate:\n${csp}`); | |||
const parsed = new CspParser(csp).csp; | |||
console.info(`[+] Evaluation results:`); | |||
const results = new CspEvaluator(parsed).evaluate(); | |||
results.forEach(elt => { | |||
let info = `[Directive '${elt.directive}' - Severity ${elt.severity}]: ${elt.description}`; | |||
console.info(info); | |||
}); | |||
} | |||
</syntaxhighlight> | </syntaxhighlight> | ||
Ausfürhungsbeispiel: | |||
<syntaxhighlight lang="bash" | <syntaxhighlight lang="bash"> | ||
$ node code.js "default-src 'self'; object-src 'none'; frame-ancestors 'none'; upgrade-insecure-requests; block-all-mixed-content" | |||
[+] CSP to evaluate: | |||
default-src 'self'; object-src 'none'; frame-ancestors 'none'; upgrade-insecure-requests; block-all-mixed-content | |||
[+] Evaluation results: | |||
[Directive 'default-src' - Severity 50]: 'self' can be problematic if you host JSONP, Angular or user uploaded files. | |||
</syntaxhighlight> | </syntaxhighlight> | ||
<!--;Input Validation | |||
: | :;Whitelisting Validation | ||
<syntaxhighlight lang=" | :Whitelisting Validation ERLAUBT nur eine gewisse Palette an Eingaben, die der Applikation bereits bekannt sind. Gemäß der OWASP gilt Whitelisting Validation als der empfohlene Minimalansatz [https://owasp-top-10-proactive-controls-2018.readthedocs.io/en/latest/c5-validate-all-inputs.html#whitelisting-vs-blacklisting]. | ||
# | <syntaxhighlight lang="python" style="border: 3px dashed blue;"> | ||
# Python | |||
# Definiere eine Funktion für die Whitelisting-Validierung | |||
def validate_input(input_value): | |||
# Definiere eine Liste von erlaubten Zeichen | |||
whitelist = set('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789') | |||
# Überprüfe, ob alle Zeichen in der Eingabe in der Whitelist enthalten sind | |||
for char in input_value: | |||
if char not in whitelist: | |||
return False | |||
# Rückgabe True, wenn die Eingabe den Validierungsregeln entspricht | |||
return True | |||
# Beispielaufruf der Validierungsfunktion | |||
input_value = "Hello123" | |||
if validate_input(input_value): | |||
print("Eingabe gültig.") | |||
else: | |||
print("Ungültige Eingabe.") | |||
</syntaxhighlight> | </syntaxhighlight> | ||
{{#set: Has ProgrammingLanguage=Python}} | |||
<br /> | <br /> | ||
; | :;Blacklisting Validation | ||
: | :Blacklisting Validation besitzt eine Auswahl an Eingaben, die explizit VERBOTEN sind. Aufgrund der Fehleranfälligkeit dieser Methode rät die OWASP von der Blacklisting Validation ab [https://owasp-top-10-proactive-controls-2018.readthedocs.io/en/latest/c5-validate-all-inputs.html#whitelisting-vs-blacklisting]. | ||
<syntaxhighlight lang=" | |||
<syntaxhighlight lang="go" style="border: 3px dashed blue;"> | |||
// GOLang | |||
package main | |||
import ( | |||
"fmt" | |||
"strings" | |||
) | |||
// Funktion zur Überprüfung von Eingaben anhand einer Blacklist | |||
func isBlacklisted(input string, blacklist []string) bool { | |||
for _, blacklistedWord := range blacklist { | |||
if strings.Contains(input, blacklistedWord) { | |||
return true | |||
} | |||
} | |||
return false | |||
} | |||
func main() { | |||
// Definiere eine Blacklist von verbotenen Wörtern oder Zeichenfolgen | |||
blacklist := []string{"spam", "malicious", "dangerous"} | |||
// Beispiel für eine Benutzereingabe | |||
userInput := "This is a spam message." | |||
// Überprüfe, ob die Benutzereingabe auf der Blacklist steht | |||
if isBlacklisted(userInput, blacklist) { | |||
fmt.Println("Die Eingabe enthält verbotene Wörter.") | |||
} else { | |||
fmt.Println("Die Eingabe ist in Ordnung.") | |||
} | |||
} | |||
</syntaxhighlight> | </syntaxhighlight> | ||
{{#set: Has ProgrammingLanguage=GO}} | |||
<br /> | <br /> | ||
Allgemein sollte die Input Validation stets serverseitig angewendet werden, um Sicherheitsrisiken entgegenzuwirken. | |||
<br /> | <br /> | ||
; | ;Parameterized Queries | ||
: | :Parameterized Queries sollen SQL-Injections vorbeugen, indem sie die SQL-Queries parametrisieren und Abfragen dadurch nicht direkt in die Datenbank gesendet werden. In Java kann dazu beispielsweise PreparedStatements genutzt werden [https://www.sciencedirect.com/topics/computer-science/input-validation#:~:text=Input%20validation%20is%20the%20process,standard%20defined%20within%20the%20application.]. | ||
<syntaxhighlight lang=" | |||
<syntaxhighlight lang="java" style="border: 3px dashed blue;"> | |||
// Java | |||
import java.sql.Connection; | |||
import java.sql.DriverManager; | |||
import java.sql.PreparedStatement; | |||
import java.sql.ResultSet; | |||
import java.sql.SQLException; | |||
public class ParametrizedQueryExample { | |||
public static void main(String[] args) { | |||
// Verbindung zur Datenbank herstellen | |||
try (Connection connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/mydatabase", "username", "password")) { | |||
// SQL-Abfrage mit Platzhaltern für Parameter | |||
String sql = "SELECT * FROM users WHERE username = ?"; | |||
// Vorbereiten der parametrisierten Abfrage | |||
try (PreparedStatement statement = connection.prepareStatement(sql)) { | |||
// Wert für den Parameter setzen | |||
statement.setString(1, "john_doe"); | |||
// Ausführen der Abfrage | |||
try (ResultSet resultSet = statement.executeQuery()) { | |||
// Verarbeitung der Abfrageergebnisse | |||
while (resultSet.next()) { | |||
String username = resultSet.getString("username"); | |||
String email = resultSet.getString("email"); | |||
System.out.println("Username: " + username + ", Email: " + email); | |||
} | |||
} | |||
} | |||
} catch (SQLException e) { | |||
e.printStackTrace(); | |||
} | |||
} | |||
} | |||
</syntaxhighlight> | </syntaxhighlight> | ||
{{#set: Has ProgrammingLanguage=Java}} | |||
<br /> | <br /> | ||
=== Validierung === | ;Input Sanitization | ||
Die | :Input Sanitization bezeichnet den Prozess der Bereinigung von Eingabedaten. Anders als die Validation zielt die Sanitization nicht auf die Gültigkeit von Daten ab, sondern versucht die Sicherheit der Anwendung zu gewährleisten, indem potenziell gefährliche Eingaben neutralisiert werden [https://www.sciencedirect.com/topics/computer-science/input-validation#:~:text=Input%20validation%20is%20the%20process,standard%20defined%20within%20the%20application.]. | ||
<syntaxhighlight lang="javascript" style="border: 3px dashed blue;"> | |||
// JavaScript | |||
// Funktion zur Validierung und Bereinigung einer E-Mail-Adresse | |||
function validateAndSanitizeEmail(email) { | |||
// Validierung: Überprüfe, ob die E-Mail-Adresse ein gültiges Format hat | |||
if (!isValidEmailFormat(email)) { | |||
return null; // Ungültige E-Mail-Adresse, Rückgabe von null | |||
} | |||
// Sanitization: Bereinige die E-Mail-Adresse von potenziell schädlichen Zeichen | |||
var sanitizedEmail = sanitizeEmail(email); | |||
return sanitizedEmail; | |||
} | |||
// Funktion zur Überprüfung des E-Mail-Formats | |||
function isValidEmailFormat(email) { | |||
// Einfache Überprüfung des E-Mail-Formats mit einem regulären Ausdruck | |||
var emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; | |||
return emailRegex.test(email); | |||
} | |||
// Funktion zur Bereinigung einer E-Mail-Adresse von potenziell schädlichen Zeichen | |||
function sanitizeEmail(email) { | |||
// Verwendung von JavaScript's replace()-Funktion mit einem regulären Ausdruck, | |||
// um potenziell schädliche Zeichen zu entfernen | |||
var sanitizedEmail = email.replace(/[^\w\s@.-]/g, ''); | |||
return sanitizedEmail; | |||
} | |||
// Beispielaufruf der Validierungs- und Bereinigungsfunktion für eine E-Mail-Adresse | |||
var userInputEmail = "example@mail.com<script>alert('XSS');</script>"; | |||
var sanitizedEmail = validateAndSanitizeEmail(userInputEmail); | |||
console.log("Sanitized Email: " + sanitizedEmail); | |||
</syntaxhighlight> | |||
{{#set: Has ProgrammingLanguage=JavaScript}} | |||
<br /> --> | |||
=== Tools und Libraries === | |||
==== Analyse Tools ==== | |||
{| class="wikitable" | |||
! Tool!! Beschreibung | |||
|- | |||
| hsecscan[https://github.com/riramar/hsecscan] || Ein Sicherheitsscanner für HTTP-Antwort-Header. | |||
|- | |||
| humble[https://github.com/rfc-st/humble] || Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. | |||
|- | |||
| SecurityHeaders.com[https://securityheaders.com/] || Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. | |||
|- | |||
| Mozilla Observatory[https://developer.mozilla.org/en-US/observatory][https://github.com/mozilla/http-observatory/][https://github.com/mozilla/http-observatory-website/] || Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. | |||
|- | |||
| testssl.sh[https://github.com/drwetter/testssl.sh] || Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. | |||
|- | |||
| DrHEADer[https://github.com/Santandersecurityresearch/DrHeader] || DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. | |||
|- | |||
| csp-evaluator[https://github.com/google/csp-evaluator] || NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) {{#set: Has SecurityHeader=Content-Security-Policy}}{{#set: Has SecurityHeader=CSP}} einen starken Schutz gegen XSS-Angriffe bietet. | |||
|} | |||
====Libraries==== | |||
=====Java===== | |||
{| class="wikitable" | |||
! Library !! Beschreibung | |||
|- | |||
| Spring Security[https://docs.spring.io/spring-security/reference/features/exploits/headers.html] || Spring Security unterstützt das Hinzufügen verschiedener Sicherheits-Header. | |||
|} | |||
=====DotNet===== | |||
: | {| class="wikitable" | ||
! Library!! Beschreibung | |||
|- | |||
| NWebsec[https://docs.nwebsec.com/] || NWebsec besteht aus mehreren Sicherheitsbibliotheken für ASP.NET-Anwendungen. | |||
|- | |||
| NetEscapades.AspNetCore.SecurityHeaders[https://github.com/andrewlock/NetEscapades.AspNetCore.SecurityHeaders] || Paket, um Sicherheits-Header zu ASP.NET Core-Websites hinzuzufügen. | |||
|- | |||
| OwaspHeaders.Core[https://github.com/GaProgMan/OwaspHeaders.Core] || .NET Core-Middleware zum Einfügen der von OWASP empfohlenen HTTP-Header zur Erhöhung der Sicherheit. | |||
|} | |||
=====Ruby===== | |||
:Die | {| class="wikitable" | ||
! Tool!! Beschreibung | |||
|- | |||
| hsecscan[https://github.com/riramar/hsecscan] || Ein Sicherheitsscanner für HTTP-Antwort-Header. | |||
|- | |||
| humble[https://github.com/rfc-st/humble] || Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. | |||
|- | |||
| SecurityHeaders.com[https://securityheaders.com/] || Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. | |||
|- | |||
| Mozilla Observatory[https://developer.mozilla.org/en-US/observatory][https://github.com/mozilla/http-observatory/][https://github.com/mozilla/http-observatory-website/] || Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. | |||
|- | |||
| testssl.sh[https://github.com/drwetter/testssl.sh] || Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. | |||
|- | |||
| DrHEADer[https://github.com/Santandersecurityresearch/DrHeader] || DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. | |||
|- | |||
| csp-evaluator[https://github.com/google/csp-evaluator] || NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) {{#set: Has SecurityHeader=Content-Security-Policy}}{{#set: Has SecurityHeader=CSP}} einen starken Schutz gegen XSS-Angriffe bietet. | |||
|} | |||
== | =====PHP===== | ||
{| class="wikitable" | |||
! Tool!! Beschreibung | |||
|- | |||
| hsecscan[https://github.com/riramar/hsecscan] || Ein Sicherheitsscanner für HTTP-Antwort-Header. | |||
|- | |||
| humble[https://github.com/rfc-st/humble] || Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. | |||
|- | |||
| SecurityHeaders.com[https://securityheaders.com/] || Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. | |||
|- | |||
| Mozilla Observatory[https://developer.mozilla.org/en-US/observatory][https://github.com/mozilla/http-observatory/][https://github.com/mozilla/http-observatory-website/] || Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. | |||
|- | |||
| testssl.sh[https://github.com/drwetter/testssl.sh] || Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. | |||
|- | |||
| DrHEADer[https://github.com/Santandersecurityresearch/DrHeader] || DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. | |||
|- | |||
| csp-evaluator[https://github.com/google/csp-evaluator] || NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) {{#set: Has SecurityHeader=Content-Security-Policy}}{{#set: Has SecurityHeader=CSP}} einen starken Schutz gegen XSS-Angriffe bietet. | |||
|} | |||
[https:// | =====NodeJS===== | ||
{| class="wikitable" | |||
! Tool!! Beschreibung | |||
|- | |||
| hsecscan[https://github.com/riramar/hsecscan] || Ein Sicherheitsscanner für HTTP-Antwort-Header. | |||
|- | |||
| humble[https://github.com/rfc-st/humble] || Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. | |||
|- | |||
| SecurityHeaders.com[https://securityheaders.com/] || Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. | |||
|- | |||
| Mozilla Observatory[https://developer.mozilla.org/en-US/observatory][https://github.com/mozilla/http-observatory/][https://github.com/mozilla/http-observatory-website/] || Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. | |||
|- | |||
| testssl.sh[https://github.com/drwetter/testssl.sh] || Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. | |||
|- | |||
| DrHEADer[https://github.com/Santandersecurityresearch/DrHeader] || DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. | |||
|- | |||
| csp-evaluator[https://github.com/google/csp-evaluator] || NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) {{#set: Has SecurityHeader=Content-Security-Policy}}{{#set: Has SecurityHeader=CSP}} einen starken Schutz gegen XSS-Angriffe bietet. | |||
|} | |||
[https://http. | =====Python===== | ||
{| class="wikitable" | |||
! Tool!! Beschreibung | |||
|- | |||
| hsecscan[https://github.com/riramar/hsecscan] || Ein Sicherheitsscanner für HTTP-Antwort-Header. | |||
|- | |||
| humble[https://github.com/rfc-st/humble] || Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. | |||
|- | |||
| SecurityHeaders.com[https://securityheaders.com/] || Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. | |||
|- | |||
| Mozilla Observatory[https://developer.mozilla.org/en-US/observatory][https://github.com/mozilla/http-observatory/][https://github.com/mozilla/http-observatory-website/] || Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. | |||
|- | |||
| testssl.sh[https://github.com/drwetter/testssl.sh] || Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. | |||
|- | |||
| DrHEADer[https://github.com/Santandersecurityresearch/DrHeader] || DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. | |||
|- | |||
| csp-evaluator[https://github.com/google/csp-evaluator] || NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) {{#set: Has SecurityHeader=Content-Security-Policy}}{{#set: Has SecurityHeader=CSP}} einen starken Schutz gegen XSS-Angriffe bietet. | |||
|} | |||
[https:// | =====Go===== | ||
{| class="wikitable" | |||
! Tool!! Beschreibung | |||
|- | |||
| hsecscan[https://github.com/riramar/hsecscan] || Ein Sicherheitsscanner für HTTP-Antwort-Header. | |||
|- | |||
| humble[https://github.com/rfc-st/humble] || Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. | |||
|- | |||
| SecurityHeaders.com[https://securityheaders.com/] || Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. | |||
|- | |||
| Mozilla Observatory[https://developer.mozilla.org/en-US/observatory][https://github.com/mozilla/http-observatory/][https://github.com/mozilla/http-observatory-website/] || Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. | |||
|- | |||
| testssl.sh[https://github.com/drwetter/testssl.sh] || Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. | |||
|- | |||
| DrHEADer[https://github.com/Santandersecurityresearch/DrHeader] || DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. | |||
|- | |||
| csp-evaluator[https://github.com/google/csp-evaluator] || NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) {{#set: Has SecurityHeader=Content-Security-Policy}}{{#set: Has SecurityHeader=CSP}} einen starken Schutz gegen XSS-Angriffe bietet. | |||
|} | |||
[https:// | =====Rust===== | ||
{| class="wikitable" | |||
! Tool!! Beschreibung | |||
|- | |||
| hsecscan[https://github.com/riramar/hsecscan] || Ein Sicherheitsscanner für HTTP-Antwort-Header. | |||
|- | |||
| humble[https://github.com/rfc-st/humble] || Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. | |||
|- | |||
| SecurityHeaders.com[https://securityheaders.com/] || Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. | |||
|- | |||
| Mozilla Observatory[https://developer.mozilla.org/en-US/observatory][https://github.com/mozilla/http-observatory/][https://github.com/mozilla/http-observatory-website/] || Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. | |||
|- | |||
| testssl.sh[https://github.com/drwetter/testssl.sh] || Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. | |||
|- | |||
| DrHEADer[https://github.com/Santandersecurityresearch/DrHeader] || DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. | |||
|- | |||
| csp-evaluator[https://github.com/google/csp-evaluator] || NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) {{#set: Has SecurityHeader=Content-Security-Policy}}{{#set: Has SecurityHeader=CSP}} einen starken Schutz gegen XSS-Angriffe bietet. | |||
|} | |||
[https://www. | ;Escape Untrusted Data | ||
:Escape Untrusted Data bezieht sich vor Allem auf den Schutz vor Cross-Site-Scripting (XSS). Hierbei ist es wichtig potenziell gefährliche Zeichen oder Symbole aus der Applikation zu entfernen oder zu maskieren. Dabei können eine Vielzahl an guten Frameworks oder Bibliotheken helfen: | |||
<br /> | |||
:::: {|class:"wikitable" border="1" | |||
| Name || Technologie | |||
|- | |||
| [https://owasp.org/www-project-enterprise-security-api/ OWASP ESAPI (Enterprise Security API)]{{#set: use Framework=ESAPI}} || Java & JavaScript | |||
|- | |||
| [https://github.com/cure53/DOMPurify DOMPurify] {{#set: use Framework=DOMPurify}} || JavaScript | |||
|- | |||
| [https://www.npmjs.com/package/helmet Helmet] {{#set: use Framework=Helmet}} || JavaScript | |||
|- | |||
| [http://htmlpurifier.org/ HTMLPurifier] {{#set: use Framework=HTMLPurifier}} || PHP | |||
|- | |||
| [https://content-security-policy.com/ Content Security Policy (CSP)] {{#set: use Framework=CSP}} || Security Header | |||
|- | |||
|} | |||
[https:// | == Weblinks == | ||
* [https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html OWASP Validation CheatSheet]{{#set: has Literacy=OWASP Validation CheatSheet}} | |||
* [https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html OWASP Header CheatSheet]{{#set: has Literacy=OWASP Header CheatSheet}} | |||
* [https://developer.android.com/privacy-and-security/security-tips Android Security Tips]{{#set: has Literacy=Android Security Tips}} | |||
== Ressourcen und Einzelnachweise == | == Ressourcen und Einzelnachweise == | ||
[https:// | [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://www. | [https://www.sciencedirect.com/topics/computer-science/input-validation#:~:text=Input%20validation%20is%20the%20process,standard%20defined%20within%20the%20application. Justin Clarke: SQL Injection Attacks and Defense ] Clarke, J. (2009). SQL Injection Attacks and Defense. Elsevier Inc. [ISBN 978-1-59749-424-3]{{#set: has Literacy=Clarke, J. (2009). SQL Injection Attacks and Defense. Elsevier Inc.}} | ||
[https:// | [https://wiki.sei.cmu.edu/confluence/display/java/Input+Validation+and+Data+Sanitization Robert Seacord: Input Validation and Data Sanitization] Seacord, R. (Manager). (2015, April 28). Input Validation and Data Sanitization. Abrufdatum: 30.04.2024.{{#set: has Literacy= Seacord, R. (Manager). (2015, April 28). Input Validation and Data Sanitization}} | ||
[https://owasp-top-10-proactive-controls-2018.readthedocs.io/en/latest/c5-validate-all-inputs.html C5: Validate All Inputs] C5: Validate All Inputs, aufgerufen am 07.05.2024{{#set: has Literacy=C5: Validate All Inputs}} | |||
{{#set:Status=angelegt}} | |||
[[Category:CHECK]] | [[Category:CHECK]] | ||
[[Category: Arch]] |
Aktuelle Version vom 17. Oktober 2024, 06:54 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.
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
Header
Strict Transport Security
HTTP Strict Transport Security (auch HSTS genannt) ist ein Mechanismus zur Websicherheit, der hilft, Websites vor Protokoll-Downgrade-Angriffen und Cookie-Diebstahl zu schützen. Er ermöglicht es Webservern zu erklären, dass Webbrowser nur über sichere HTTPS-Verbindungen mit ihnen interagieren sollten und niemals über das unsichere HTTP-Protokoll.
HSTS ist ein Protokoll im IETF-Standardverlauf und ist in RFC 6797 spezifiziert. Ein Server implementiert eine HSTS-Richtlinie, indem er einen Header (Strict-Transport-Security) über eine HTTPS-Verbindung bereitstellt (HSTS-Header über HTTP werden ignoriert).
X-Frame-Options
Der X-Frame-Options-Response-Header (auch XFO genannt) verbessert den Schutz von Webanwendungen gegen Clickjacking. Er weist den Browser an, ob der Inhalt innerhalb von Frames angezeigt werden kann.
Die Content-Security-Policy (CSP) frame-ancestors
-Direktive macht den X-Frame-Options-Header obsolet. Wenn eine Ressource beide Richtlinien hat, wird die CSP frame-ancestors
-Richtlinie durchgesetzt, und die X-Frame-Options-Richtlinie wird ignoriert.
X-Content-Type-Options
Das Setzen dieses Headers verhindert, dass der Browser Dateien als einen anderen MIME-Typ interpretiert als den, der im Content-Type
-HTTP-Header angegeben ist (z. B. wird text/plain
nicht als text/css
behandelt).
Content-Security-Policy
Eine Content Security Policy (auch CSP genannt) erfordert eine sorgfältige Anpassung und präzise Definition der Richtlinie. Wenn sie aktiviert ist, hat die CSP erhebliche Auswirkungen auf die Art und Weise, wie Browser Seiten rendern (z. B. ist Inline-JavaScript standardmäßig deaktiviert und muss ausdrücklich in der Richtlinie erlaubt werden). Die CSP verhindert eine Vielzahl von Angriffen, einschließlich Cross-Site-Scripting und anderen Cross-Site-Injektionen.
X-Permitted-Cross-Domain-Policies
Eine Cross-Domain-Policy-Datei ist ein XML-Dokument, das einem Webclient, wie zum Beispiel Adobe Flash Player oder Adobe Acrobat (obwohl nicht unbedingt auf diese beschränkt), die Erlaubnis erteilt, Daten über verschiedene Domains hinweg zu verarbeiten. Wenn Clients Inhalte anfordern, die auf einer bestimmten Quell-Domain gehostet werden, und diese Inhalte Anfragen an eine andere Domain als ihre eigene senden, muss die entfernte Domain eine Cross-Domain-Policy-Datei bereitstellen, die den Zugriff auf die Quell-Domain gewährt, sodass der Client die Transaktion fortsetzen kann. Normalerweise wird eine Meta-Policy in der Haupt-Policy-Datei deklariert, aber für diejenigen, die nicht im Stammverzeichnis schreiben können, besteht auch die Möglichkeit, eine Meta-Policy über den HTTP-Response-Header X-Permitted-Cross-Domain-Policies zu deklarieren.
Referrer-Policy
Der Referrer-Policy-HTTP-Header regelt, welche Referrer-Informationen, die im Referer-Header gesendet werden, in die gestellten Anfragen einbezogen werden sollen.
Clear-Site-Data
Der Clear-Site-Data-Header löscht die Browsing-Daten (Cookies, Speicher, Cache), die mit der anfordernden Website verbunden sind. Dieser Header ist beispielsweise während eines Logout-Prozesses nützlich, um sicherzustellen, dass alle gespeicherten Inhalte auf der Client-Seite, wie Cookies, Speicher und Cache, entfernt werden.
Cross-Origin-Resource-Policy
Dieser Response-Header (auch CORP genannt) ermöglicht es, eine Richtlinie zu definieren, die Websites und Anwendungen schützt, indem sie sich gegen bestimmte Anfragen von anderen Ursprüngen (wie beispielsweise solchen, die mit Elementen wie <script> und <img> gesendet werden) absichern, um spekulativen Seitenkanalangriffen wie Spectre sowie Cross-Site Script Inclusion (XSSI)-Angriffen entgegenzuwirken.
- CORP gilt auf der Seite der geladenen Ressource (Ressourcenbesitzer).
Cross-Origin-Embedder-Policy
Dieser Response-Header (auch COEP genannt) verhindert, dass ein Dokument beliebige Cross-Origin-Ressourcen lädt, die dem Dokument nicht ausdrücklich die Erlaubnis erteilen.
- COEP gilt auf der Seite des „Laders“ der Ressource (Verbraucher der Ressource).
Cross-Origin-Opener-Policy
Dieser Antwort-Header (auch COOP genannt) ermöglicht es, sicherzustellen, dass ein übergeordnetes Dokument keine Browsing-Context-Gruppe mit Dokumenten von fremden Ursprüngen teilt. COOP wird das Dokument prozessisolieren, sodass potenzielle Angreifer nicht auf globale Objekte zugreifen können, wenn sie es in einem Popup-Fenster geöffnet werden. Dies verhindert eine Reihe von Cross-Origin-Angriffen, die als XS-Leaks bezeichnet werden.
Permissions Policy
Der Permissions-Policy-Header ersetzt den bestehenden Feature-Policy-Header zur Steuerung der Delegation von Berechtigungen und leistungsstarken Funktionen. Der Header verwendet eine strukturierte Syntax und ermöglicht es Websites, genauer zu regeln, welche Ursprünge Zugriff auf Funktionen gewährt werden kann.
Cache-Control
Dieser Header enthält Anweisungen (Direktiven) für das Caching sowohl in Anfragen als auch in Antworten. Die Angabe, ob eine Ressource zwischengespeichert werden kann, ist wichtig, um die Offenlegung von Informationen über den Cache zu verhindern.
Die Header mit den Namen Expires und Pragma können zusätzlich zum Cache-Control-Header verwendet werden. Der Pragma-Header kann zur Rückwärtskompatibilität mit HTTP/1.0-Caches verwendet werden. Der Cache-Control-Header wird jedoch als die empfohlene Methode angesehen, um die Caching-Richtlinie zu definieren.
Best Practices
Header | Vorschlag für den Wert |
---|---|
Strict-Transport-Security | max-age=31536000; includeSubDomains
|
X-Frame-Options | deny
|
X-Content-Type-Options | nosniff
|
Content-Security-Policy | default-src 'self'; form-action 'self'; object-src 'none'; frame-ancestors 'none'; upgrade-insecure-requests; block-all-mixed-content
|
X-Permitted-Cross-Domain-Policies | none
|
Referrer-Policy | no-referrer
|
Clear-Site-Data | "cache","cookies","storage"
|
Cross-Origin-Embedder-Policy | require-corp
|
Cross-Origin-Opener-Policy | same-origin
|
Cross-Origin-Resource-Policy | same-origin
|
Permissions-Policy | accelerometer=(), autoplay=(), camera=(), cross-origin-isolated=(), display-capture=(), encrypted-media=(), fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(self), usb=(), web-share=(), xr-spatial-tracking=(), clipboard-read=(), clipboard-write=(), gamepad=(), hid=(), idle-detection=(), interest-cohort=(), serial=(), unload=()
|
Cache-Control | no-store, max-age=0
|
Validierung
Permissions-Policy zurück in Feature-Policy konvertieren
Da der Permissions-Policy-Header noch in der Entwicklung ist und nicht gut unterstützt wird, kann es interessant sein, die beiden Formate zu verwenden, um die Abdeckung der Browser je nach ihrem Unterstützungsgrad für die Permissions-Policy und Feature-Policy-Richtlinien zu erhöhen.
Der folgende Python3-Code-Schnipsel kann nützlich sein, um eine solche Konvertierung zu erreichen.
permissions_policy = 'fullscreen=(), geolocation=(self "https://game.com" "https://map.example.com"), gyroscope=(self), usb=*'
feature_policy_directives = []
# Direktiven sammeln
permissions_policy_directives = permissions_policy.split(",")
# Jede Direktive verarbeiten
for permissions_policy_directive in permissions_policy_directives:
# Leerzeichen am Anfang und Ende entfernen
directive = permissions_policy_directive.strip(" ")
# Alle Anführungszeichen entfernen
directive = directive.replace("\"", "")
# Deaktivierungsausdruck () durch den entsprechenden in der Feature-Policy ersetzen
directive = directive.replace("()", "'none'")
# Schlüsselwörter angeben: self
directive = directive.replace("self", "'self'")
# Das Zuweisungszeichen durch ein Leerzeichen ersetzen
directive = directive.replace("=", " ")
# Klammern entfernen
directive = directive.replace("(", "").replace(")", "")
# Die aktuelle Direktive zur Sammlung hinzufügen
feature_policy_directives.append(directive)
# Die Sammlung der Direktiven in einen String mit ; als Trennzeichen umwandeln
feature_policy = "; ".join(feature_policy_directives)
print(feature_policy)
Ausführungsbeispiel:
$ python code.py
fullscreen 'none'; geolocation 'self' https://game.com https://map.example.com; gyroscope 'self'; usb *
Content-Security-Policy lokal auf Schwächen testen
Es kann interessant sein, eine Content-Security-Policy lokal auf Schwächen zu validieren, bevor sie auf bereitgestellten Webanwendungen angewendet wird.
Der folgende JavaScript-Code-Schnipsel kann nützlich sein, um eine solche Validierung durchzuführen, indem das csp-evaluator NPM-Modul von Google verwendet wird.
import {CspEvaluator} from "csp_evaluator/dist/evaluator.js";
import {CspParser} from "csp_evaluator/dist/parser.js";
const args = process.argv.slice(2)
if(args.length == 0){
console.error("[!] Missing CSP!");
}else{
const csp = args[0]
console.info(`[+] CSP to evaluate:\n${csp}`);
const parsed = new CspParser(csp).csp;
console.info(`[+] Evaluation results:`);
const results = new CspEvaluator(parsed).evaluate();
results.forEach(elt => {
let info = `[Directive '${elt.directive}' - Severity ${elt.severity}]: ${elt.description}`;
console.info(info);
});
}
Ausfürhungsbeispiel:
$ node code.js "default-src 'self'; object-src 'none'; frame-ancestors 'none'; upgrade-insecure-requests; block-all-mixed-content"
[+] CSP to evaluate:
default-src 'self'; object-src 'none'; frame-ancestors 'none'; upgrade-insecure-requests; block-all-mixed-content
[+] Evaluation results:
[Directive 'default-src' - Severity 50]: 'self' can be problematic if you host JSONP, Angular or user uploaded files.
Tools und Libraries
Analyse Tools
Tool | Beschreibung |
---|---|
hsecscan[1] | Ein Sicherheitsscanner für HTTP-Antwort-Header. |
humble[2] | Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. |
SecurityHeaders.com[3] | Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. |
Mozilla Observatory[4][5][6] | Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. |
testssl.sh[7] | Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. |
DrHEADer[8] | DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. |
csp-evaluator[9] | NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) einen starken Schutz gegen XSS-Angriffe bietet. |
Libraries
Java
Library | Beschreibung |
---|---|
Spring Security[10] | Spring Security unterstützt das Hinzufügen verschiedener Sicherheits-Header. |
DotNet
Library | Beschreibung |
---|---|
NWebsec[11] | NWebsec besteht aus mehreren Sicherheitsbibliotheken für ASP.NET-Anwendungen. |
NetEscapades.AspNetCore.SecurityHeaders[12] | Paket, um Sicherheits-Header zu ASP.NET Core-Websites hinzuzufügen. |
OwaspHeaders.Core[13] | .NET Core-Middleware zum Einfügen der von OWASP empfohlenen HTTP-Header zur Erhöhung der Sicherheit. |
Ruby
Tool | Beschreibung |
---|---|
hsecscan[14] | Ein Sicherheitsscanner für HTTP-Antwort-Header. |
humble[15] | Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. |
SecurityHeaders.com[16] | Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. |
Mozilla Observatory[17][18][19] | Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. |
testssl.sh[20] | Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. |
DrHEADer[21] | DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. |
csp-evaluator[22] | NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) einen starken Schutz gegen XSS-Angriffe bietet. |
PHP
Tool | Beschreibung |
---|---|
hsecscan[23] | Ein Sicherheitsscanner für HTTP-Antwort-Header. |
humble[24] | Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. |
SecurityHeaders.com[25] | Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. |
Mozilla Observatory[26][27][28] | Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. |
testssl.sh[29] | Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. |
DrHEADer[30] | DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. |
csp-evaluator[31] | NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) einen starken Schutz gegen XSS-Angriffe bietet. |
NodeJS
Tool | Beschreibung |
---|---|
hsecscan[32] | Ein Sicherheitsscanner für HTTP-Antwort-Header. |
humble[33] | Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. |
SecurityHeaders.com[34] | Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. |
Mozilla Observatory[35][36][37] | Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. |
testssl.sh[38] | Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. |
DrHEADer[39] | DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. |
csp-evaluator[40] | NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) einen starken Schutz gegen XSS-Angriffe bietet. |
Python
Tool | Beschreibung |
---|---|
hsecscan[41] | Ein Sicherheitsscanner für HTTP-Antwort-Header. |
humble[42] | Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. |
SecurityHeaders.com[43] | Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. |
Mozilla Observatory[44][45][46] | Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. |
testssl.sh[47] | Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. |
DrHEADer[48] | DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. |
csp-evaluator[49] | NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) einen starken Schutz gegen XSS-Angriffe bietet. |
Go
Tool | Beschreibung |
---|---|
hsecscan[50] | Ein Sicherheitsscanner für HTTP-Antwort-Header. |
humble[51] | Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. |
SecurityHeaders.com[52] | Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. |
Mozilla Observatory[53][54][55] | Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. |
testssl.sh[56] | Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. |
DrHEADer[57] | DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. |
csp-evaluator[58] | NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) einen starken Schutz gegen XSS-Angriffe bietet. |
Rust
Tool | Beschreibung |
---|---|
hsecscan[59] | Ein Sicherheitsscanner für HTTP-Antwort-Header. |
humble[60] | Ein schneller, sicherheitsorientierter HTTP-Header-Analysator. |
SecurityHeaders.com[61] | Die HTTP-Antwort-Header, die diese Seitenanalyse bereitstellt, bieten ein hohes Maß an Schutz. |
Mozilla Observatory[62][63][64] | Ein Mozilla-Projekt, das Entwicklern, Systemadministratoren und Sicherheitsexperten dabei helfen soll, ihre Websites sicher und geschützt zu konfigurieren. |
testssl.sh[65] | Ein einfach zu verwendendes Shell-Skript, das nicht nur die SSL/TLS-Verschlüsselung testet, sondern auch gängige Header überprüft und diese analysiert. Die Ausgabe erfolgt auf dem Bildschirm als JSON, CSV und HTML. |
DrHEADer[66] | DrHEADer hilft bei der Überprüfung von Sicherheits-Headern, die als Antwort auf eine einzelne Anfrage oder eine Liste von Anfragen empfangen werden. |
csp-evaluator[67] | NPM-Modul, das es Entwicklern und Sicherheitsexperten ermöglicht zu überprüfen, ob eine Content Security Policy (CSP) einen starken Schutz gegen XSS-Angriffe bietet. |
- Escape Untrusted Data
- Escape Untrusted Data bezieht sich vor Allem auf den Schutz vor Cross-Site-Scripting (XSS). Hierbei ist es wichtig potenziell gefährliche Zeichen oder Symbole aus der Applikation zu entfernen oder zu maskieren. Dabei können eine Vielzahl an guten Frameworks oder Bibliotheken helfen:
Name Technologie OWASP ESAPI (Enterprise Security API) Java & JavaScript DOMPurify JavaScript Helmet JavaScript HTMLPurifier PHP Content Security Policy (CSP) Security Header
Weblinks
Ressourcen und Einzelnachweise
[68] 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
Justin Clarke: SQL Injection Attacks and Defense Clarke, J. (2009). SQL Injection Attacks and Defense. Elsevier Inc. [ISBN 978-1-59749-424-3]
Robert Seacord: Input Validation and Data Sanitization Seacord, R. (Manager). (2015, April 28). Input Validation and Data Sanitization. Abrufdatum: 30.04.2024.
C5: Validate All Inputs C5: Validate All Inputs, aufgerufen am 07.05.2024