O.Arch 9: Unterschied zwischen den Versionen

Aus d.hack
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
== 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 Anwendung MUSS Eingaben aus nicht vertrauenswürdigen Quellen vor deren Verwendung prüfen, um potenziell bösartige Werte vor der Verarbeitung herauszufiltern.


== Kurzfassung ==
== Kurzfassung ==
Verwendung von dem Stand der Technik entsprechenden HTTP-Server-Headern.
Prüfung von Eingaben vor Verwendung.


== Anmerkungen ==
==== Prüftiefe ====
<br />
== Testcharakteristik ==
== Testcharakteristik ==
==== Prüftiefe ====
==== Prüftiefe ====
Zeile 18: Zeile 15:
| 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 alle Eingaben aus nicht vertrauenswürdigen Quellen vor ihrer Verwendung dem Stand der Technik entsprechend geprüft werden. Eingaben meinen jegliche Art von Daten, die in die Anwendung hineinfließen. Das sind zum Beispiel Nutzereingaben, Eingaben aus Drittanbieterkomponenten etc.
 
== Lösungsansätze ==
== Lösungsansätze ==
=== Implementierung ===
=== Implementierung ===
;Security Headers
==== Best Practices und Standards ====
: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].
;Input Validation
Bekannte Sicherheitsheader sind beispielsweise:
:;Whitelisting Validation
# [https://content-security-policy.com/ Content Security Policy (CSP)] {{#set: has SecurityHeader=CSP}}
: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].
# [https://http.dev/x-content-type-options X-Content-Type-Options] {{#set: has SecurityHeader=X-Content-Options}}
<syntaxhighlight lang="python" style="border: 3px dashed blue;">
# [https://www.w3.org/TR/referrer-policy/ Referrer-Policy] {{#set: has SecurityHeader=Referrer-Policy}}
# Python
# [https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html Strict-Transport-Security (HSTS) ] {{#set: has SecurityHeader=HSTS}}
# Definiere eine Funktion für die Whitelisting-Validierung
# [https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html X-Frame-Options] {{#set: has SecurityHeader=X-Frame-Options}}
def validate_input(input_value):
# [https://www.w3.org/TR/permissions-policy/ Permission-Policy] {{#set: has SecurityHeader=Permission-Policy}}
    # Definiere eine Liste von erlaubten Zeichen
# [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}}
    whitelist = set('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789')
<br />
 
    # Ü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


;Content Security Policy (CSP)
# Beispielaufruf der Validierungsfunktion
:CSP legt fest, welche Ressourcen auf einer Seite geladen werden dürfen und hilft so, Cross-Site-Scripting (XSS)-Angriffe zu verhindern.
input_value = "Hello123"
<syntaxhighlight lang="bash" style="border: 3px dashed blue;">
if validate_input(input_value):
# Beispielkonfiguration eines Apache-Servers zu Verwendung von CSP
    print("Eingabe gültig.")
Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com
else:
    print("Ungültige Eingabe.")
</syntaxhighlight>
</syntaxhighlight>
{{#set: Has ProgrammingLanguage=Python}}
<br />
<br />


;X-Content-Header
:;Blacklisting Validation
: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.
: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="bash" style="border: 3px dashed blue;">
 
# Beispielkonfiguration eines Apache-Servers zu Verwendung von X-Content-Header
<syntaxhighlight lang="go" style="border: 3px dashed blue;">
X-Content-Type-Options: nosniff
// 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 />


;Referrer-Policy
Allgemein sollte die Input Validation stets serverseitig angewendet werden, um Sicherheitsrisiken entgegenzuwirken.
: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 />
<br />


;HTTP Strict Transport Security (HSTS):
;Parameterized Queries
: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.
: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="bash" style="border: 3px dashed blue;">
 
# Beispielkonfiguration eines Apache-Servers zu Verwendung von HSTS
<syntaxhighlight lang="java" style="border: 3px dashed blue;">
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
// 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 />


;X-Frame-Option
;Input Sanitization
:X-Frame-Options verhindert das Laden der Webseite in einem <frame>, <iframe> oder <object> und schützt so vor Clickjacking-Angriffen.
: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="bash" style="border: 3px dashed blue;">
# Beispielkonfiguration eines Apache-Servers zu Verwendung von x-Frame-Options
X-Frame-Options: DENY
</syntaxhighlight>
<br />


;Permission-Policy
<syntaxhighlight lang="javascript" style="border: 3px dashed blue;">
:Die Permission-Policy legt die Berechtigungen fest, die eine Webseite anfordern kann.
// JavaScript
<syntaxhighlight lang="bash" style="border: 3px dashed blue;">
// Funktion zur Validierung und Bereinigung einer E-Mail-Adresse
# Beispielkonfiguration eines Apache-Servers zu Verwendung von Permission-Policy
function validateAndSanitizeEmail(email) {
Permissions-Policy: geolocation=(), microphone=()
    // Validierung: Überprüfe, ob die E-Mail-Adresse ein gültiges Format hat
</syntaxhighlight>
    if (!isValidEmailFormat(email)) {
In diesem Beispiel sind die Berechtigungen für die Geolokalisierung und das Mikrofon deaktiviert.
        return null; // Ungültige E-Mail-Adresse, Rückgabe von null
<br />
    }
<br />


;X-XSS-Protection
    // Sanitization: Bereinige die E-Mail-Adresse von potenziell schädlichen Zeichen
:Der X-XSS-Protection-Header aktiviert den XSS-Schutz im Browser und verhindert das Laden einer Seite, wenn ein XSS-Angriff erkannt wird.
    var sanitizedEmail = sanitizeEmail(email);
<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 ===
    return sanitizedEmail;
Die Implementierung von Security Header ist auf unterschiedliche Weisen möglich:
}


;Manuell im Webbrowser
// Funktion zur Überprüfung des E-Mail-Formats
:Durch das Wechseln in die Entwicklertools des Webbrowsers kann man die gesendeten Header im Reiter Netzwerk überprüfen.
function isValidEmailFormat(email) {
    // Einfache Überprüfung des E-Mail-Formats mit einem regulären Ausdruck
    var emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    return emailRegex.test(email);
}


;Online-Tools
// Funktion zur Bereinigung einer E-Mail-Adresse von potenziell schädlichen Zeichen
:Die Anwendung der Security Headers kann beispielsweise mit [https://securityheaders.com/ SecurityHeaders.com] {{#set: has PentestingTool=SecurityHeaders.com}} validiert werden.
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;
}


== Weblinks ==
// 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}}


[https://content-security-policy.com/ Content Security Policy] {{#set: has Literacy=Content Security Policy}}
<br />


[https://http.dev/x-content-type-options X-Content-Type-Options] {{#set: has Literacy=X-Content-Type-Options}}
==== 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:
<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://www.w3.org/TR/referrer-policy/ Referrer-Policy] {{#set: has Literacy=Referrer-Policy}}
<br />


[https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html Strict-Transport-Security (HSTS) ] {{#set: has Literacy=HSTS}}
;[https://semediwiki.labs.inf.fh-dortmund.de/index.php/O.Arch_9 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].


[https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html X-Frame-Options] {{#set: has Literacy=X-Frame-Options}}
<br />


[https://www.w3.org/TR/permissions-policy/ Permission-Policy] {{#set: has Literacy=Permission-Policy}}
== Siehe auch ==


[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}}
[https://semediwiki.labs.inf.fh-dortmund.de/index.php/O.Arch_9 Arch_9]
 
== 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://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.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.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://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://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://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security HTTP-Strict-Transport-Security (HSTS)] {{#set: has Literacy=HSTS}}
[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}}


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

Version vom 25. Juli 2024, 13:48 Uhr

Beschreibung

Die Anwendung MUSS Eingaben aus nicht vertrauenswürdigen Quellen vor deren Verwendung prüfen, um potenziell bösartige Werte vor der Verarbeitung herauszufiltern.

Kurzfassung

Prüfung von Eingaben vor Verwendung.

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 alle Eingaben aus nicht vertrauenswürdigen Quellen vor ihrer Verwendung dem Stand der Technik entsprechend geprüft werden. Eingaben meinen jegliche Art von Daten, die in die Anwendung hineinfließen. Das sind zum Beispiel Nutzereingaben, Eingaben aus Drittanbieterkomponenten etc.

Lösungsansätze

Implementierung

Best Practices und Standards

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

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