O.Arch 9

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

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

HTTP Strict Transport Security (HSTS)

Zweck: Erzwingt HTTPS und verhindert, dass der Browser über unsichere HTTP-Verbindungen kommuniziert.

Anwendung: Schützt vor Man-in-the-Middle-Angriffen, indem HTTP zu HTTPS umgeleitet wird und der Browser nur verschlüsselte Verbindungen akzeptiert.

Beispiel-Implementierung:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Best Practice:

• includeSubDomains, um auch alle Subdomains einzuschließen.
• preload, um die Domain auf die HSTS Preload-Liste zu setzen, damit sie von Anfang an nur über HTTPS verfügbar ist.
• Zu Beginn eine kleinere max-age, um die Konfiguration zu testen. Nach Erfolgreichen Tests erhöhen.

Content Security Policy (CSP)

Zweck: Kontrolliert, welche Ressourcen (z. B. Skripte, Stylesheets) von der Webseite geladen werden dürfen, und schützt vor Cross-Site Scripting (XSS) und Code Injection.

Anwendung: Reduziert die Angriffsfläche durch das Einschränken von unsicheren Skripten oder externen Quellen.

Beispiel-Implementierung:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-scripts.example.com; object-src 'none'; frame-ancestors 'none';

Best Practice:

• self, um Ressourcen nur von der eigenen Domain zuzulassen.
• Vermeiden Sie unsafe-inline und unsafe-eval, um die Ausführung von Inline-JavaScript zu verhindern.
• Nutzen Sie den Report-Only-Modus, um potenzielle Verletzungen zu überwachen.

X-Frame-Options (Veraltet, aber nützlich für ältere Browser)

Zweck: Verhindert, dass eine Seite in einem Frame eingebettet wird, und schützt vor Clickjacking.

Anwendung: Ermöglicht es, Clickjacking-Angriffe zu verhindern, indem Seiten nur von der eigenen Domain eingebettet werden oder gar nicht eingebettet werden dürfen.

Beispiel-Implementierung:

X-Frame-Options: DENY

Best Practice:

• DENY, um Framing komplett zu verbieten, oder SAMEORIGIN, um es nur für die eigene Domain zu erlauben.
• Für modernere Browser kann CSP frame-ancestors verwendet werden, was mehr Flexibilität bietet.

X-Content-Type-Options

Zweck: Verhindert MIME-Type Sniffing, indem der Browser gezwungen wird, den angegebenen Content-Type strikt zu beachten.

Anwendung: Verhindert, dass der Browser versucht, den Dateityp anhand des Inhalts zu erraten, was zu Sicherheitslücken führen kann.

Beispiel-Implementierung:

X-Content-Type-Options: nosniff

Best Practice:

• Immer nosniff verwenden, um sicherzustellen, dass der Browser nur den im HTTP-Header angegebenen Dateityp akzeptiert.

X-XSS-Protection (Veraltet, aber nützlich für ältere Browser)

Zweck: Aktiviert den XSS-Schutz in älteren Browsern, indem Skripte blockiert werden, die versuchen, eine Cross-Site Scripting-Attacke durchzuführen.

Anwendung: Blockiert Seiten, bei denen versucht wird, schädliche Skripte einzufügen.

Beispiel-Implementierung:

X-XSS-Protection: 1; mode=block

Best Practice:

• Setzen Sie 1; mode=block, um XSS-Angriffe zu verhindern und betroffene Seiten zu blockieren.
• Für modernere Browser sollten CSP-Richtlinien als primärer Schutzmechanismus verwendet werden.

Referrer-Policy

Zweck: Kontrolliert, welche Informationen im HTTP-Referer-Header übermittelt werden. Dies schützt die Privatsphäre der Benutzer und verhindert die Weitergabe sensibler Daten.

Anwendung: Verhindert, dass vollständige URLs mit sensiblen Informationen an externe Websites weitergegeben werden.

Beispiel-Implementierung:

Referrer-Policy: no-referrer

Best Practice:

• no-referrer, um sicherzustellen, dass keine Referrer-Informationen gesendet werden.
• strict-origin-when-cross-origin, wenn Sie Referrer-Informationen nur für die eigene Domain senden möchten.

Feature-Policy (Permissions-Policy)

Zweck: Regelt den Zugriff auf bestimmte Browser-APIs wie Geolocation, Kamera, Mikrofon und mehr. Damit kannst du steuern, welche Features auf der Website genutzt werden dürfen. Anwendung: Beschränkt die Verwendung von sensiblen Features nur auf autorisierte Quellen.

Beispiel-Implementierung:

Permissions-Policy: geolocation 'self'; microphone 'none';

Best Practice:

• self oder spezifische vertrauenswürdige Quellen für die Features, die Sie erlauben möchten.
• sensible Features wie Kamera, Mikrofon oder Standort standardmäßig auf none, um unberechtigten Zugriff zu verhindern.

Validierung

Input Validation

Whitelisting Validation

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 [1].

# 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.")

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 [2].

// 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.")
	}
}

Allgemein sollte die Input Validation stets serverseitig angewendet werden, um Sicherheitsrisiken entgegenzuwirken.

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 [3].

// 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();
        }
    }
}

Input Sanitization

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 [4].

// 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);

Tools

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

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 [5].

Siehe auch

Arch_9

Weblinks

• OWASP Validation CheatSheet
• OWASP Header CheatSheet
• Android Security Tips

Ressourcen und Einzelnachweise

[6] 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