LLM-Red-Teaming vs. Penetrationstest für Webanwendungen: Was jeweils abgedeckt wird, Kosten und wann Sie beides brauchen

Dies sind die Richtwerte, die auf unserer Seite zu Cybersecurity-Leistungen veröffentlicht sind. Der endgültige Preis hängt vom Umfang ab, und jedes Projekt beginnt mit der Vereinbarung, was innerhalb und außerhalb des Testumfangs liegt.

Was ein Pentest einer Webanwendung abdeckt

Ein Pentest einer Webanwendung ist ein autorisierter Versuch, in Ihre laufende Anwendung einzudringen – im Black-Box-, Grey-Box- oder White-Box-Verfahren, je nachdem, wie viel Zugriff die Tester erhalten. Der typische Umfang orientiert sich an den OWASP Top 10: fehlerhafte Zugriffskontrolle, Injection, Authentifizierungsfehler, unsichere Konfiguration, verwundbare Komponenten und ähnliche Probleme.

Er beantwortet Fragen wie: Kann ein Kunde die Daten eines anderen lesen? Kann ein normaler Nutzer Admin-Funktionen erreichen? Kann eine Eingabe ihren vorgesehenen Zweck verlassen? Sind Geheimnisse oder Debug-Schnittstellen offengelegt? Das Ergebnis ist ein schriftlicher Bericht mit nachgewiesenen Befunden, Schweregrad und Empfehlungen zur Behebung, und er sollte einen erneuten Test einschließen, nachdem Sie die Funde behoben haben.

Wenn Sie noch am Anfang stehen und verstehen möchten, welche Prüfung zu Ihnen passt, lesen Sie unseren Vergleich von technischen Audits, Penetrationstests und Code-Reviews.

Was LLM Red Teaming abdeckt

Beim LLM Red Teaming gelten das Modell und alles, was daran angebunden ist, als Ziel. Die wichtigsten Angriffstypen sind:

• Direkte Prompt Injection: Ein Nutzer schreibt Anweisungen, die Ihren System-Prompt außer Kraft setzen sollen („Ignoriere deine vorherigen Anweisungen“).
• Indirekte Prompt Injection: Feindselige Anweisungen, versteckt in einer Webseite, einem Dokument, einer E-Mail oder einem Tool-Ergebnis, die das Modell im Auftrag eines Nutzers liest.
• Jailbreaks: Das Modell dazu bringen, seine Sicherheits- und Richtliniengrenzen zu überschreiten.
• Datenextraktion: Das Modell dazu bringen, seinen Prompt, Daten anderer Nutzer oder Inhalte preiszugeben, mit denen es trainiert wurde oder die es abruft.
• Model Denial of Service: Prompts, die darauf ausgelegt sind, übermäßig viel Rechenleistung oder Kosten zu verursachen.
• Retrieval Poisoning: Inhalte in Dokumenten platzieren, die Ihr Retrieval-System (RAG) durchsucht, sodass das Modell sie wiederholt oder darauf reagiert.
• Tool-Missbrauch durch Agenten: Einen Agenten dazu überreden, ein mächtiges Tool aufzurufen – etwa E-Mails zu versenden, Rückerstattungen auszulösen oder Datensätze zu löschen –, und zwar mit vom Angreifer kontrollierten Eingaben.
• Rechteausweitung über MCP-Server und Plugins: Ein angebundenes Tool nutzen, um an Daten oder Aktionen zu gelangen, auf die der Nutzer keinen Zugriff haben sollte.
• Lieferkettenrisiken: Schädliche Prompts, Modelle oder Tools von Drittanbietern.

Der Bericht zeigt, welche davon gegen Ihr Produkt funktionieren, wie ein Angreifer sie verketten würde und was zu ändern ist. Viele KI-Produkte im Produktivbetrieb sind gleichzeitig für mehrere dieser Angriffe anfällig, oft weil jede einzelne Funktion für sich vernünftig war.

Wo sich beide überschneiden

Die Überschneidung ist größer, als sie aussieht. Sobald ein KI-Agent Tools aufrufen kann, wird eine Prompt Injection zu einem Problem der Zugriffskontrolle: Das Modell ist ein neuer, leicht zu überredender Nutzer in Ihrem System. Wenn es die Datensätze eines Kunden lesen oder eine Zahlung auslösen kann, gilt alles, was ein Webanwendungs-Pentest zu Berechtigungen prüft, nun auch für das, was das Modell tun darf.

Es funktioniert auch umgekehrt. Die Ausgabe eines Modells ist nicht vertrauenswürdiger Text. Wenn Ihre Oberfläche sie unbedacht darstellt, kann eine klassische Web-Schwachstelle wie Cross-Site-Scripting über das Modell eingeschleust werden. Ein gutes Red Team schließt entlang dieser Pfade auch konventionelle Prüfungen ein.

Brauchen Sie einen von beiden oder beide?

• Eine normale Webanwendung ohne KI-Funktionen: ein Pentest der Webanwendung, sobald die Grundlagen behoben sind.
• Ein Chatbot, der nur aus öffentlichen Inhalten antwortet: geringeres Risiko, aber testen Sie Prompt-Leaks, Missbrauch und Kostenlimits und prüfen Sie auch die Web-Schicht.
• Ein Assistent mit Zugriff auf private oder Kundendaten: beide. Datenabfluss über das Modell ist der Fehler, der sich am teuersten erklären lässt.
• Ein Agent, der über Tools oder MCP-Server Aktionen ausführt: beide, mit den Tool-Berechtigungen als zentralem Schwerpunkt.
• Ein Retrieval-Produkt (RAG) über viele Quellen: beide, plus besondere Aufmerksamkeit dafür, wer Dokumente zum Index hinzufügen darf.

Wenn das Budget knapp ist, beginnen Sie damit, drei Dinge aufzulisten: welche Daten das Modell sehen kann, welche Aktionen es ausführen kann und wer mit ihm sprechen darf. Je mehr davon, desto dringender das Testen.

Das Risiko vor dem Test senken

Prompt Injection lässt sich heute nicht vollständig ausschließen. Gutes Design geht daher davon aus, dass das Modell manchmal getäuscht wird, und begrenzt den Schaden:

1. Geben Sie Tools möglichst geringe Rechte und beschränken Sie sie pro Nutzer, niemals mit einem mächtigen gemeinsamen Schlüssel.
2. Verlangen Sie eine menschliche Bestätigung für destruktive oder hochwertige Aktionen.
3. Behandeln Sie die Modellausgabe als nicht vertrauenswürdig und validieren oder kodieren Sie sie, bevor sie eine Oberfläche, eine Datenbank oder ein anderes System erreicht.
4. Trennen Sie Anweisungen und nicht vertrauenswürdige Inhalte, wo Ihre Architektur es erlaubt, und vermeiden Sie Geheimnisse in Prompts.
5. Protokollieren Sie Tool-Aufrufe und setzen Sie Rate- und Ausgabenlimits, damit Missbrauch sichtbar und begrenzt ist.

Diese Maßnahmen von Anfang an einzubauen, ist viel günstiger, als sie nach einem Befund nachzurüsten. So gehen wir vor, wenn wir KI-Agenten und MCP-Server entwickeln.

Was Sie von einem Projekt erwarten können

Ein seriöser Anbieter vereinbart Umfang und Einsatzregeln im Voraus, testet nur, was Sie autorisieren, und liefert einen schriftlichen Bericht, der sowohl für Ingenieure als auch für Entscheidungsträger verfasst ist. Auf Korrekturen sollte ein erneuter Test folgen, damit Sie deren Wirksamkeit belegen können. Seien Sie vorsichtig bei jedem, der verspricht, Ihr KI-Produkt sei „vollständig sicher“; das ehrliche Ergebnis ist ein klareres Bild, weniger ausnutzbare Pfade und Nachweise, die Sie mit Kunden teilen können.

Bei KI-gebauten Apps, die auf den Launch zugehen, empfehlen wir üblicherweise diese Reihenfolge: ein technisches Audit, dann Korrekturen, dann formale Tests. Unsere Checkliste zur Produktionsreife ist ein guter Ausgangspunkt.