Einsatz von Reasoning Models in AutoTriage

TL;DR

Für SAST meisten SAST sind Argumentationsmodelle nicht erforderlich, aber in Randfällen wie dem Pfaddurchlauf in JavaScript erfassen sie doppelt so viele Fehlalarme.

Sind Argumentationsmodelle nur ein Hype?

„Reasoning Models“ erleben gerade einen Boom. Die großen KI-Labore liefern sich einen Kampf um die Vorherrschaft und versuchen, die Grenzen der Modellgröße und -leistung durch Skalierungsgesetze, intelligentere Vorabtrainings und Feinabstimmungen mit RLHF (Reinforcement Learning from Human Feedback) zu erweitern. Außerdem setzen sie auf Chain-of-Thought-Prompting, damit Modelle während der Inferenz „laut denken“. Dadurch können sie Nicht-KI-Systeme bei logischen Aufgaben dominieren – und gleichzeitig die Ranglisten anführen. 

Das ist beeindruckend. Aber sind sie in der Praxis wirklich nützlich? Das kommt darauf an.

Im Falle von AutoTriage* hängt vieles von der Komplexität der SAST ab.
‍
*Kurze Zusammenfassung – AutoTriage ist eine Funktion, Aikido der Aikido falsch positive SAST herausfiltert.
**Ein SAST ist eine potenzielle Schwachstelle, die im Quellcode entdeckt wurde und von einem fest programmierten Musterdetektor gemeldet wird.‍
‍

Für die meisten SAST zu teuer

AutoTriage funktioniert in zwei Schritten: Zunächst versuchen wir, die Möglichkeit einer Ausnutzbarkeit auszuschließen. Ist dies möglich, können wir ein falsches Positiv herausfiltern. Dies erfordert ein schwarz-weißes Denken hinsichtlich der Erreichbarkeit von benutzergesteuerten Variablen in Schwachstellen. Das Modell überprüft im Wesentlichen, ob die Variable tatsächlich benutzergesteuert ist und ob eine Bereinigung/Validierung/Umwandlung vorhanden ist. Und wenn es eine Form der Schadensbegrenzung gibt, wird geprüft, ob diese tatsächlich wirksam ist.

Der zweite Schritt erfolgt nur, wenn wir die Möglichkeit einer Ausnutzbarkeit im ersten Schritt nicht ausschließen können. Wir konzentrieren uns dann auf die Priorisierung. Die Priorität wird durch die Wahrscheinlichkeit definiert, dass etwas schiefgehen könnte, und durch die Schwere, wenn es schiefgehen würde. Dieser zweite Schritt ist weniger schwarz-weiß, hängt aber auch von subjektiven Einschätzungen ab – beispielsweise davon, dass eine Variable vom Benutzer gesteuert wird, wenn uns der vollständige Kontext fehlt.

Für die meisten Regeln lässt sich die Vorgehensweise in einer überschaubaren Anzahl von „Faustregeln“ zusammenfassen, sodass Argumentationsmodelle überflüssig werden: Diese weisen zwar eine ähnliche Genauigkeit auf, sind jedoch mit deutlich höheren Kosten verbunden.

Warum kleine Argumentationsmodelle funktionieren

Einige Regeln sind überraschend komplex und nicht-logische Modelle haben Schwierigkeiten, sie zu verstehen. Stellen Sie sich vor, Sie würden für jedes Wort, das Sie sagen, genau denselben mentalen Raum nutzen: Zunächst fragt Sie jemand: „Was ist 1+1?“ Dann fragt dieselbe Person Sie: „Was ist 26248 + 346237?“ Während normale Modelle mit unterschiedlichen Komplexitätsgraden zu kämpfen haben, können Modelle mit logischen Schlussfolgerungen damit umgehen, indem sie einfach mehr Wörter für komplexe Eingaben verwenden und größere Probleme in kleinere, besser zu bewältigende Teilprobleme zerlegen.

Leider sind sie aufgrund ihres höheren Tokenverbrauchs in der Regel auch teurer. Allerdings leiden Modelle, die als Schlussfolgerungsmodelle strukturiert sind, weniger unter einer Verkleinerung des Modells als Nicht-Schlussfolgerungsmodelle. Es gibt zwei Gründe, sich für größere Modelle zu entscheiden: (1) Sie verfügen über mehr Kapazität zur Speicherung von Wissen (obwohl im Falle der Einstufung von Schwachstellen ein großer Wissensbestand nicht wirklich notwendig ist). (2) Größere Modelle sind in der Regel etwas genauer pro Wort. Reasoning-Modelle können jedoch dank ihrer Reasoning-Struktur Fehler korrigieren. Trotz des höheren Token-Verbrauchs ist es in der Praxis also möglich, mit kleineren Modellen mit geringeren Kosten pro Token zu arbeiten, um den höheren Token-Verbrauch auszugleichen.

Pfaddurchquerung in JavaScript

Pfadüberquerung ist eine Regel, bei der Schlussfolgerungsmodelle ihre Stärken voll ausspielen können, da sie überraschend komplex zu triage sind. Pfadüberquerung ist eine Sicherheitslücke, durch die Endbenutzer Dateien außerhalb eines vorgesehenen Verzeichnisses lesen oder schreiben können. Stellen Sie sich beispielsweise vor, Google Drive hätte für jeden Benutzer einen eigenen Ordner in einem Dateisystem wie diesem:

GoogleDrive/userId1/
Google Drive/userId2/…

​Wenn Sie das nächste Mal eine Ihrer Dateien herunterladen möchten, senden Sie eine GET-Anfrage von Ihrem Browser-Client an Google Drive, z. B. mit dem Dateinamen meinHundisstSchuhe.jpg. Wenn diese Datei vorhanden ist, wird der Download sofort gestartet. Was aber, wenn Sie den folgenden Dateinamen ausprobiert haben: ../Benutzer-ID2/MeinePasswörter.txtWenn Google Drive sein Backend nicht gegen Pfadüberquerung geschützt hätte, könnten Sie möglicherweise eine „meinePasswörter.txtDatei von einem anderen Benutzer, sofern diese Datei existiert.

Verschiedene Pfad-Traversal-Angriffe

Um SAST triage zu triage , müssen wir verschiedene Fälle verstehen, in denen etwas anfällig ist oder nicht. Beginnen wir mit den einfachen Fällen und steigern wir dann schrittweise die Komplexität.

Muster 1: „../“

Das offensichtliche Problem hierbei ist das Muster „../“. Wenn Sie einen Dateipfad mit „../“ lesen oder in einen solchen schreiben, könnte dies escape beabsichtigte Verzeichnis escape und an einer Stelle gelesen/geschrieben wird, die Sie nicht beabsichtigt haben. Wenn also keine Überprüfung auf „../“ im Dateipfad erfolgt und die Datei clientseitig angegeben wird, besteht eine echte Sicherheitslücke. Im schlimmsten Fall könnten Hacker Dateien mit Anmeldedaten auf Ihrem System lesen.

Muster 2: „..\\“

Stellen Sie sich vor, Sie hätten nach „../“ gesucht, aber der Code läuft auf einem Windows-System. Dann hätten Sie erneut ein Problem, da eine Pfadüberquerung mit „..\\“-Mustern weiterhin möglich ist. So weit, so gut – zwei Faustregeln, die es zu beachten gilt, sind noch überschaubar, oder?

Muster 3: „...“

Um schöne und saubere Pfade ohne fehlende Schrägstriche zu erhalten, verwenden viele Leute Funktionen wie path.resolve() oder path.join()Hier beginnt der Spaß. Stellen Sie sich Folgendes vor:

if (userControlledSubPath.includes(‘../’) || userControlledSubPath.includes(‘..\\’)|| filename.includes(‘../’) || filename.includes(‘..\\’)) 
{	
   throw new Error(‘Path traversal attempt detected);
}‍

const filepath = path.join(HARDCODED_BASE_PATH, userControlledSubPath, filename);

return fs.readFileSync(filepath);‍

Es stellt sich heraus, dass dies immer noch anfällig ist: Wenn ein Angreifer userControlledSubPath === '..', das Pfad.join wird dies weiterhin als „ein Verzeichnis höher“ interpretiert.

Das letzte Argument in path.join() ist gegen diesen Angriff immun. Wenn ein Angreifer „..“ im letzten Argument angeben würde, würde das path.join() Die Funktion würde ein Verzeichnis anstelle eines Dateipfads zurückgeben, was zu einer ungültigen Lese-/Schreiboperation führen würde.

Muster 4: „/*“

In einem neuen Beispiel hatten wir wieder einen Test wie diesen:

if (filename.includes(‘..’)) 
{	
    throw new Error(‘Path traversal attempt detected);
}

const filepath = path.resolve(HARDCODED_BASE_PATH, filename);

return fs.readFileSync(filepath);

Das sieht sicher aus, oder? Die Überprüfung deckt die Fälle „..“, „../“ und „..\\“ ab – sehr elegant! Nun kommt die überraschende Erklärung, warum dies dennoch eine Schwachstelle darstellt. Trommelwirbel… trrrrrrrrr… Wenn ein Argument in path.resolve() beginnt mit einem Schrägstrich, ignoriert es alle vorherigen Argumente. Wenn ein Angreifer also etwas wie filename = /etc/passwd macht, dann path.resolve() den fest codierten Basispfad ignorieren und zu /etc/passwdBeängstigend, nicht wahr? Wir hätten auch nach diesem abschließenden Schrägstrich suchen sollen. Beachten Sie, dass die Verwendung von path.join() hätte es sicher gemacht.

Die Komplexität würdigen

Charlie Chaplin hat einmal gesagt: „Einfachheit ist keine einfache Sache“. Das gilt auch hier: Es gibt einfache, wirksame Abhilfemaßnahmen, aber zunächst muss man sich über die Bandbreite möglicher Angriffsvektoren im Klaren sein. Die einfachste und robusteste Abhilfemaßnahme gegen Pfadüberquerung besteht darin, zunächst den Pfad aufzulösen und zu überprüfen, ob er noch mit dem beabsichtigten Basispfad beginnt. Dieser Überprüfung kann man sich nicht entziehen.

Das AutoTriage-Team hat jedoch nicht den Luxus, sich die Abhilfemaßnahmen aussuchen zu können. Wir müssen in der Lage sein, alternative Lösungen als sicher zu kennzeichnen, damit wir Kunden nicht unnötig mit Fehlalarmen überfordern. Wir haben nun vier verschiedene Angriffsvektoren für Path Traversal gesehen, die alle mit spezifischen Prüfungen einhergehen. Für jeden dieser Angriffsvektoren muss das LLM prüfen, ob er unter allen Voraussetzungen auftreten kann, um entweder einen erfolgreichen Angriff durchzuführen oder jede Möglichkeit eines Angriffs auszuschließen.

Obwohl Reasoning-Modelle für die meisten Regeln nicht standardmäßig verwendet werden, können sie im Vergleich zu Nicht-Reasoning-Modellen für die Pfaddurchquerung in JavaScript doppelt so viele Fehlalarme sicher herausfiltern. Das ist ein entscheidender Vorteil für Rauschreduzierung.

​

​