Ungetesteter KI-Sicherheitsfix

Was ist Ungetesteter KI-Sicherheitsfix?

Ein KI-Coding-Assistent hat für eine SQL-Injection einen Fix vorgeschlagen, eine Regex-Denylist, und erklärt, der Endpunkt sei jetzt sicher. Die offensichtliche Payload wurde mit 400 abgewiesen, also wurde das Ticket geschlossen. Noch in derselben Woche kam eine mit Kommentaren zerlegte Variante mühelos am Filter vorbei und zog die komplette Kundentabelle ab. Sie nehmen den selbstsicher präsentierten Diff des Assistenten an, verfolgen die Umgehung im API Tester, ersetzen die Denylist durch eine parametrisierte Abfrage und beweisen den Fix, indem Sie genau den Angriff wiederholen. Die Lehre daraus: Verifizieren Sie einen Sicherheitsfix mit dem Angriff, nicht mit der Selbstsicherheit des Assistenten.

Was Sie lernen in Ungetesteter KI-Sicherheitsfix

• Erklären, warum die Selbstsicherheit, mit der ein KI-Assistent einen Fix für sicher erklärt, kein Beweis für dessen Sicherheit ist
• Zeigen, warum eine Denylist eine Abfrage nicht absichern kann: Es gibt immer eine weitere Kodierung einer schädlichen Eingabe, die sie nie erfasst hat
• Einen Sicherheitsfix verifizieren, indem man genau den Angriff reproduziert, den er verhindern soll, und bestätigt, dass dieser scheitert
• Eingabefilterung durch eine parametrisierte Abfrage ersetzen, damit der Wert als Daten gebunden wird und nie als SQL geparst werden kann
• Erkennen, dass Entwickler auch für Code verantwortlich sind, den sie von einem Assistenten angenommen, aber nie geprüft haben

Ungetesteter KI-Sicherheitsfix — Trainingsschritte

1. Ein Scanner-Befund

   Ein statischer Codescan hat im Endpunkt der Kundensuche eine SQL-Injection gemeldet. Der Befund landet in Jotvane, dem Issue-Tracker des Teams, in Alices Warteschlange.

2. Die anfällige Abfrage

   Alice öffnet die gemeldete Datei. Der Suchwert landet direkt im SQL-Text.

3. Wo es schiefgeht

   Der Wert von q wird in den Abfragetext eingefügt. Was auch immer der Aufrufer sendet, wird damit Teil der SQL-Anweisung.

4. Den Assistenten um einen Fix bitten

   Alice öffnet den Assistenten und bittet ihn, die Injection zu beheben.

5. Ein selbstsicherer Fix

   Der Assistent liest die Datei und sucht nach vorhandenen Hilfsfunktionen zur Bereinigung. Dann schlägt er einen Filter vor, der gefährliche Muster aus der Eingabe herausfiltert, und erklärt, der Endpunkt sei jetzt sicher.

6. Den Fix annehmen

   Claude hat eine Änderung vorgeschlagen und erklärt, sie sei sicher. Alice liest, was Claude tatsächlich geändert hat, und nimmt dann den Diff an. Der Filter landet im Code, und die Randleiste markiert die neuen Zeilen violett und gestrichelt: von Claude geschrieben, noch von keinem Menschen geprüft. Die Herkunftsleiste zeigt den Stand der Datei: mehrere Zeilen vom Assistenten geschrieben, keine davon geprüft. Die Selbstsicherheit des Assistenten ist kein Review und auch kein Test.

7. Die offensichtliche Payload

   Alice schickt die klassische Injection an den Endpunkt. Der Filter weist sie mit 400 ab. Das Problem scheint behoben.

8. Den Befund schließen

   Die offensichtliche Payload ist abgeprallt, der Befund scheint also erledigt. Alice vermerkt das Ergebnis im Issue und markiert es als gelöst. Etwas anderes hat niemand ausprobiert.

9. Am Filter vorbei

   Bob testet denselben Endpunkt. Eine Denylist sucht nach festen Mustern, also zerlegt er das Muster mit Inline-Kommentaren. Die Datenbank behandelt die Kommentare wie Leerzeichen und führt die Injection trotzdem aus.

10. Die komplette Tabelle

    Die mit Kommentaren zerlegte Eingabe ist durch den Filter gerutscht, und die Injection hat die gesamte Kundentabelle geliefert: Namen, E-Mail-Adressen, Telefonnummern, Geburtsdaten. Der Fix, der „jetzt sicher“ sein sollte, wurde nie gegen etwas anderes getestet als die offensichtliche Zeichenfolge.