Nachdem wir in unserem ersten OWASP Top 10 Beitrag 3 Broken Access Control Attacks vorgestellt haben, geht es nun um Injection Angriffe. In diesem Artikel befassen wir uns mit der Implementierung einer Web Application Firewall (WAF) mit NGINX und ModSecurity, um Websites gegen die OWASP Top 10 Injection Angriffe zu schützen.
Eine WAF ist eine Sicherheitslösung, die zwischen einer Website und dem Internet platziert wird, um sie vor bekannten Bedrohungen zu schützen. OWASP Top 10 Injection Angriffe sind eine der häufigsten Bedrohungen, denen Webanwendungen ausgesetzt sind.
OWASP Top 10 Injection Angriffe sind eine Vielzahl von Angriffen, die darauf abzielen, die Integrität von Daten zu beeinträchtigen, welche auf der Webanwendung liegen. Im Folgenden stellen wir einige der bekanntesten OWASP Top 10 Injection Angriffe vor.
Ein SQL Injection Angriff wird durchgeführt, indem ein Angreifer eine schädliche SQL Abfrage an die Datenbank der Webanwendung sendet. Wenn die Webanwendung keine geeigneten Schutzmaßnahmen implementiert hat, kann der Angreifer die Datenbank manipulieren, Informationen offen legen und stehlen.
LDAP Injection Angriffe sind ähnlich wie SQL Injection Angriffe, richten sich aber gegen das Lightweight Directory Access Protocol (LDAP). Mit einem LDAP Injection Angriff kann ein Angreifer auf das LDAP Verzeichnis der Webanwendung zugreifen und es manipulieren.
Ein Command Injection Angriff tritt auf, wenn ein Angreifer eine schädliche Befehlszeile an die Webanwendung sendet, die von einem Betriebssystem ausgeführt wird. Wenn die Webanwendung keine geeigneten Schutzmaßnahmen implementiert hat, kann der Angreifer beliebige Befehle auf dem betroffenen System ausführen.
Eine WAF arbeitet, indem sie den eingehenden Datenverkehr einer Webanwendung überwacht und Filter auf diesen Datenverkehr anwendet. Diese Filter sind so konfiguriert, dass sie z. B. Injection-Eingaben erkennen und blockieren. Eine WAF kann entweder als Hardware oder als Software implementiert werden.
NGINX ist eine beliebte Open-Source-Software, die häufig als Reverse Proxy und Load Balancer eingesetzt wird. Für NGINX (Plus) ist mit dem Modul ModSecurity WAF eine weitere Open-Source-Software verfügbar.
NGINX ModSecurity WAF ist allerdings ab nächstem Jahr end of life und wird nur noch bis zum März 2024 unterstützt. Weiterhin unterstützt wird NGINX Plus.
Die Implementierung einer WAF mit NGINX Plus und ModSecurity erfordert 5 Schritte, die wir im Folgenden beschreiben.
NGINX Plus kannst du auf verschiedenen Betriebssystemen installieren, einschließlich Linux, Windows und MacOS. Die Installation von NGINX Plus unterscheidet sich je nach Betriebssystem, aber es gibt zahlreiche Anleitungen im Internet.
ModSecurity ist eine plattformübergreifende Open-Source-WAF-Engine und kann als Modul in NGINX Plus integriert werden. Die Installation von ModSecurity kann je nach Betriebssystem variieren.
Nachdem du das Modul installiert hast, musst du sicherstellen, dass es über die passende Konfigurationsdatei geladen wird: /etc/nginx/nginx.conf
load_module modules/ngx_http_modsecurity_module.so;
NGNIX Plus kann als Reverse Proxy konfiguriert werden. Dazu erstellst du eine passende Konfigurationsdatei /etc/nginx/conf.d/proxy.conf. In dieser Datei hinterlegst du entsprechende Parameter – angepasst an deinen eigenen Anwendungsfall.
server {
listen 80;
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;
location / {
proxy_pass http://localhost:8085;
proxy_set_header Host $host;
}
}
Achte darauf, dass in keiner weiteren Konfigurationsdatei ein virtueller Server auf Port 80 lauscht. Sollte dies der Fall sein, musst du die entsprechenden Dateien anpassen, indem du die jeweiligen Codezeilen auskommentierst.
Dies ist beispielsweise in der Datei /etc/nginx/conf.d/default.conf der Fall, die Bestandteil des NGINX Plus Package ist.
Damit die Ausführung der Filterregeln zugelassen wird, musst du die Konfigurationsdatei /etc/nginx/modsec/modsecurity.conf entsprechend anpassen und die Engine einschalten.
# SecRuleEngine DetectionOnly
SecRuleEngine On
Anschließend kannst du mit /etc/nginx/modsec/main.conf eine weitere Konfigurationsdatei erstellen, in der die zuvor angepasste modsecurity.conf aufgerufen wird. Außerdem aktivierst du hier die Regeln für die OWASP Top 10 Injection Angriffe:
# Include the recommended configuration
Include /etc/nginx/modsec/modsecurity.conf
# OWASP CRS v3 rules
Include /usr/local/owasp-modsecurity-crs-3.0.2/crs-setup.conf
...
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-912-DOS-PROTECTION.conf
Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/REQUEST-913-SCANNER-DETECTION.conf
...
Die Dateien crs-setup.conf und *.conf enthalten die Regeln zum Schutz gegen die OWASP Top 10 Injection Angriffe. Mit dem OWASP Core Rule Set (CRS), das wir hier verwenden, stehen bereits fertige Regeln zur Verfügung.
Natürlich besteht auch die Möglichkeit, eigene Regeln zu konfigurieren und einzubinden. In diesem Artikel erklären wir, wie du dabei vorgehst: ModSecurity Core Rule Sets und Eigene Regeln
Bei Verwendung des OWASP CRS solltest du beachten, dass Requests mit Cross-Site-Scripting (XSS) Inhalten standardmäßig nicht geblockt werden. Diese Regel musst du entsprechend ergänzen.
Die Funktionalität der WAF kannst du überprüfen, indem du einen OWASP Top 10 Injection Angriff gegen die Webanwendung ausführst. Wenn die WAF ordnungsgemäß konfiguriert ist, sollte sie den Angriff erkennen und blockieren. Überlicherweise ist eine Nachkonfiguration und Anpassung an die eigenen Anforderungen sinnvoll. Verwende einen Schwachstellenscanner deiner Wahl (z.B. Nikto), um die implementierten Sicherheitsmaßnahmen zu validieren.
Die folgenden Beispiele zeigen, welchen Schaden OWASP Top 10 Injection Angriffe anrichten können. Durch die Verwendung einer WAF können Unternehmen ihre Webanwendungen vor einer Vielzahl dieser Angriffe schützen und die Sicherheit ihrer Kunden gewährleisten. Es ist jedoch wichtig, dass die WAF regelmäßig aktualisiert und die konfigurierten Rulesets erweitert werden. Nur so kannst du sicherstellen, dass sie immer auf dem neuesten Stand ist und die neuesten Bedrohungen erkennen kann.
SELECT * FROM users WHERE username = '$username' AND password = '$password';
Ein Angreifer könnte versuchen, diesen Code mit einem schädlichen Benutzernamen und Passwort zu injizieren, um Zugriff auf die Datenbank des Juice Shop zu erhalten. Hier ist ein Beispiel für eine schädliche Eingabe:
' OR '1'='1
Die SQL-Abfrage sieht dann wie folgt aus:
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '' OR '1'='1';
Eine WAF kann diese Art von Angriff erkennen, indem sie die Eingabeformulare auf schädliche Zeichenfolgen und verdächtige Schlüsselwörter überprüft.
<div>
<p>Willkommen, $username</p>
</div>
Ein Angreifer könnte versuchen, diesen Code mit einem schädlichen Benutzernamen zu injizieren, um bösartigen Code auf der Website des Juice Shop auszuführen. Hier ist ein Beispiel für eine schädliche Eingabe:
alert('Ich habe den Juice Shop gehackt!');
Dies würde dazu führen, dass der bösartige Javascript Code auf der Website des Juice Shop ausgeführt wird, wenn ein Benutzer mit diesem Benutzernamen angemeldet ist und die Seite besucht. Eine WAF kann diese Art von Angriff erkennen, indem sie die Eingabeformulare auf verdächtige Skript-Tags und schädliche Zeichenfolgen überprüft.
const exec = require('child_process').exec;
const cmd = '$command';
exec(cmd, (error, stdout, stderr) => {
console.log(stdout);
});
Ein Angreifer könnte versuchen, diesen Code mit einem schädlichen Befehl zu injizieren, um Kontrolle über den Server des Juice Shop zu erlangen. Hier ist ein Beispiel für eine schädliche Eingabe:
const cmd = 'rm -rf /';
Dies würde dazu führen, dass der Befehl rm -rf / auf dem Server des Juice Shop ausgeführt wird, was zu einem katastrophalen Datenverlust führen würde. Eine WAF könnte diese Art von Angriff erkennen, indem sie den eingehenden Datenverkehr auf verdächtige Befehle und schädliche Zeichenfolgen überprüft.
const path = '/uploads/' + req.query.file;
fs.readFile(path, (err, data) => {
res.send(data);
});
Ein Angreifer könnte versuchen, diesen Code mit einer manipulierten Query-Parameter-Datei zu injizieren, um auf eine Datei zuzugreifen, auf die er normalerweise keinen Zugriff hat. Hier ist ein Beispiel für eine schädliche Eingabe:
?file=../../../../../etc/passwd
Dies würde dazu führen, dass der Angreifer auf die Datei /etc/passwd zugreifen kann, die normalerweise nur für den Root-Benutzer zugänglich ist. Eine WAF kann diese Art von Angriff erkennen, indem sie die Query-Parameter-Dateien auf verdächtige Muster und unerlaubte Zeichenfolgen überprüft.
const xml = `
<!DOCTYPE foo [
]>
&xxe;
`;
parser.parse(xml, (err, result) => {
console.log(result);
});
Ein Angreifer könnte versuchen, diesen Code mit einem schädlichen XML-Dokument zu injizieren, um auf Dateien auf dem Server des Juice Shop zuzugreifen. Hier ist ein Beispiel für eine schädliche Eingabe:
<!DOCTYPE foo [
]>
&xxe;
Dies würde dazu führen, dass der Angreifer auf die Datei /etc/passwd zugreifen kann, die normalerweise nur für den Root-Benutzer zugänglich ist. Eine WAF kann diese Art von Angriff erkennen, indem sie die XML-Dokumente auf verdächtige Muster und unerlaubte Zeichenfolgen überprüft.
Hier sind einige der Methoden, die eine WAF zur Erkennung von Angriffen verwenden kann:
Es können bekannte Angriffssignaturen hinterlegt werden, um Angriffe zu erkennen. Diese Signaturen basieren auf bekannten Angriffsmustern und stammen von Sicherheitsforschern und anderen IT-Security relevanten Quellen.
Eine WAF kann auch das Verhalten von Benutzern und Anwendungen überwachen, um Anomalien und verdächtige Aktivitäten zu erkennen. Wenn eine Anwendung zum Beispiel plötzlich eine große Anzahl von Anfragen von einer einzelnen IP-Adresse erhält, kann dies ein Indikator für einen Angriff sein.
Die Reputation von IP-Adressen und anderen Quellen wird überwacht, um verdächtige Aktivitäten zu erkennen. Wenn eine IP-Adresse zum Beispiel in der Vergangenheit für Angriffe auf andere Webanwendungen bekannt war, kann diese entsprechend auf eine Blacklist gesetzt werden.
Anomalien und verdächtige Aktivitäten können als Muster erkannt und gespeichert werden, um zu erkennen, dass es sich um einen Angriff handelt. Der Algorithmus lernt, wie sich eine normale Anwendung verhält, und Anomalien erkennen, die auf einen Angriff hinweisen.
Durch die Kombination dieser Technologien kann eine WAF eine Webanwendung vor einer Vielzahl von Bedrohungen schützen und die Integrität ihrer Daten sicherstellen. Es ist jedoch wichtig, dass eine WAF regelmäßig aktualisiert wird, um sicherzustellen, dass sie immer auf dem neuesten Stand ist und die neuesten Updates eingespielt sind.
Eine WAF kann eine Vielzahl von Angriffen verhindern, darunter SQL-Injection, LDAP-Injection, Command Injection und viele andere Arten von Angriffen.
Eine WAF kann nicht alle Arten von Angriffen verhindern, aber sie kann helfen, das Risiko von Angriffen zu minimieren und den Schaden zu begrenzen, wenn ein Angriff stattfindet.
Indem bekannte Angriffe gezielt gegen die Anwendungen gefahren werden. Wenn Ihre WAF ordnungsgemäß konfiguriert ist, sollte sie den Angriff erkennen und entsprechende Maßnahmen ergreifen (z. B. blockieren).
