KrakenD + Coraza API Demo

Diese Demo zeigt, wie eine veröffentlichte API über ein Gateway bereitgestellt, durch eine Web Application Firewall geprüft und auf einem VPS verständlich visualisiert werden kann.

1. Aufgabenverteilung

Eine Anfrage aus dem Browser geht nicht direkt zur eigentlichen Anwendung. Sie läuft durch mehrere Stationen, die jeweils eine klare Rolle haben.

Browser

Startpunkt der Anfrage. Ein Nutzer klickt auf einen Button oder ruft eine URL auf.

Client

Caddy

Nimmt die Anfrage entgegen und leitet sie intern weiter.

Reverse Proxy

Coraza

Prüft die Anfrage auf verdächtige Muster und kann sie blockieren.

WAF

KrakenD

Stellt API-Endpunkte bereit und routet sie an interne Services.

API Gateway

Mock API

Liefert die eigentlichen Demo-Daten wie Produkte und published_date.

Backend
Aktueller Aufbau: Vor dieser Demo sitzt auf dem VPS bereits Traefik als äußerer Reverse Proxy. Danach geht die Anfrage zu Caddy mit Coraza, dann zu KrakenD und zuletzt zur internen Mock API.

2. Interaktive Demo

Klicke auf einen Button. Die Demo zeigt die technische Antwort und erklärt gleichzeitig, welche Komponente welche Aufgabe übernommen hat.

Admin-Bereich öffnen

3. Ergebnis und Erklärung

Adresszeile im Browser: Die URL oben im Browser bleibt normalerweise https://demo.aufeni.com/. Die Buttons rufen die API im Hintergrund per JavaScript auf.
Tatsächlich aufgerufene API-Adresse:
Noch keine Anfrage ausgeführt.

Technische Antwort

Noch keine Anfrage ausgeführt.

Was ist passiert?

Bereit für die Demo

Starte mit API-Info laden. Dann siehst du das Veröffentlichungsdatum der API und den Weg der Anfrage durch die Architektur.

4. Was bedeuten die HTTP-Statuscodes?

Jede HTTP-Antwort enthält einen Statuscode. Er sagt dem Browser oder API-Client, ob die Anfrage erfolgreich war oder warum sie nicht verarbeitet wurde.

HTTP/2 200 OK

Die Anfrage war erfolgreich. In dieser Demo bedeutet das: Die Anfrage wurde erlaubt, von KrakenD geroutet und vom Backend beantwortet.

HTTP/2 403 Forbidden

Die Anfrage wurde verstanden, aber verweigert. In dieser Demo bedeutet das: Coraza hat den Request als verdächtig erkannt und blockiert.

HTTP/2 404 Not Found

Die angefragte Ressource wurde nicht gefunden. Das passiert zum Beispiel, wenn ein Pfad nicht existiert.

HTTP/2 500 Internal Server Error

Auf Serverseite ist ein unerwarteter Fehler passiert. Das hatten wir kurz beim ersten Produkt-Endpunkt, weil KrakenD ein JSON-Objekt erwartete, aber die Mock API ein JSON-Array geliefert hatte.

Hinweis: HTTP/2 beschreibt die verwendete HTTP-Protokollversion. 200, 403, 404 oder 500 sind die eigentlichen Statuscodes.

5. Was bedeutet der SQL-Injection-Angriffsparameter?

Der Button SQL-Injection simulieren sendet absichtlich diesen Parameter: 

q=' OR 1=1

Das ist ein klassisches Muster, das bei einer SQL Injection vorkommen kann. Die Idee dahinter: Ein Angreifer versucht, eine Datenbankabfrage so zu manipulieren, dass eine Bedingung immer wahr wird.

Beispielhaft gedacht: Wenn eine Anwendung intern prüft Benutzername stimmt UND Passwort stimmt, könnte ein Angreifer versuchen, durch eingeschleuste Logik wie OR 1=1 die Abfrage künstlich wahr zu machen.

Wichtig: In dieser Demo gibt es keine echte Datenbank und es wird kein echter Schaden verursacht. Der Parameter dient nur dazu zu zeigen, dass Coraza ein verdächtiges Muster erkennt und blockieren kann.

6. Zweites Angriffsmuster: DROP TABLE

Der zweite rote Button sendet dieses Testmuster: 

q=DROP TABLE users

DROP TABLE ist ein SQL-Befehl, der in einer echten Datenbank eine Tabelle löschen würde. users steht hier beispielhaft für eine Benutzertabelle.

Auch hier gilt: In dieser Demo wird nichts gelöscht. Es gibt keine echte Datenbank. Das Muster dient nur als leicht verständliches Beispiel für einen verdächtigen Datenbankbefehl in einer HTTP-Anfrage.

7. Warum kann es mehrere WAF-Schichten geben?

Frühe WAF-Schicht

Eine WAF kann sehr weit vorne in der Infrastruktur sitzen. Dann blockiert sie verdächtige Anfragen, bevor sie tiefere Systeme erreichen.

Vorteil: Ein Angreifer kommt weniger weit in die Infrastruktur hinein.

Service-nahe WAF-Schicht

Eine weitere WAF kann näher an einem bestimmten Service sitzen. Dort kann sie spezifischer prüfen, was für genau diesen Service erlaubt ist.

Vorteil: Die Regeln können enger auf den jeweiligen Dienst zugeschnitten werden.

Beispiel: Eine äußere WAF könnte allgemeine Angriffe blockieren. Eine zweite WAF hinter dem Gateway könnte zusätzlich spezielle Regeln für eine einzelne API anwenden. Andersherum kann man eine äußere Schicht auch bewusst nur weiterleiten lassen und die strengere Prüfung service-näher durchführen.
Kernaussage: Es können auch zwei WAF-Schichten hintereinander sinnvoll sein. Eine äußere WAF kann allgemeine Angriffe früh abfangen. Eine zweite, service-nähere WAF kann gezielt Regeln für eine bestimmte API oder Anwendung anwenden. Welche Schicht wie streng prüft, ist eine Architekturentscheidung: Je früher blockiert wird, desto weniger weit kommt ein Angreifer. Je näher am Service geprüft wird, desto spezifischer können die Regeln sein.

8. Merkhilfe

Caddy ist hier der interne Eingang zur Demo-Anwendung.

Coraza ist die WAF-Schicht, die verdächtige HTTP-Anfragen blockieren kann.

KrakenD ist das API-Gateway, das öffentliche API-Pfade auf interne Services abbildet.

Mock API ist der interne Service, der die eigentlichen Daten liefert.

Authentik oder Keycloak können später den Admin-Bereich per Login schützen.