Einleitung

Injection-Schwachstellen gehören zu den gefährlichsten und langlebigsten Software-Sicherheitsproblemen. Sie treten auf, wenn nicht vertrauenswürdige Eingaben direkt in Abfragen, Befehle oder Code-Interpreter übergeben werden, ohne ordnungsgemäße Validierung oder Escape. Dies kann zu unbefugtem Zugriff, Datenkorruption oder einer vollständigen Systemkompromittierung führen.

Während herkömmliche SAST sich auf gängige Sprachen wie JavaScript, Python oder Java konzentrieren, erkennt die KI-gestützte Codequalitäts-Engine Aikidonun auch Injektionsschwachstellen in Sprachen, die SAST normalerweise übersehen werden, wie Perl, Haskell, Groovy, Erlang, Zig, Delphi, PowerShell, COBOL, ABAP, Visual Basic, Pascal und ColdFusion.

Diese Regel stellt sicher, dass, unabhängig davon, welche Sprache Ihr Team verwendet, unsichere Abfrage- oder Befehlskonstruktionen abgefangen werden, bevor sie in die Produktion gelangen.

Warum es wichtig ist

Injection-Schwachstellen bleiben eines der OWASP Top 10 Sicherheitsrisiken.

Sie sind leicht einzuführen, aber oft schwer durch manuelle Überprüfung zu erkennen, insbesondere in älteren oder weniger verbreiteten Sprachen.

Ohne Schutzmaßnahmen:

• Angreifer können SQL- oder OS-Befehle in dynamisch erstellte Zeichenketten injizieren.
• Sensible Daten können exfiltriert oder zerstört werden.
• Ganze Systeme können übernommen werden, wenn die Code-Ausführung möglich ist.

Durch die Durchsetzung dieser Regel muss jeder Code, der Abfragen oder Befehle erstellt, parametrisierte APIs, sichere Bibliotheken oder Escape-Funktionen verwenden, wodurch die Angriffsfläche drastisch reduziert wird.

❌ Nicht konformes Beispiel

Unten ist ein Beispiel in PowerShell dargestellt, aber das gleiche Problem tritt in vielen Sprachen auf.

# Unsicher: Benutzereingabe direkt in einen Systembefehl verkettet
$userInput = Read-Host "Benutzernamen eingeben"
Invoke-Expression ("net user " + $userInput)

Warum dies unsicher ist: Invoke-Expression führt einen dynamisch konstruierten Befehl aus.

Ein Angreifer könnte john && del C:\* /Q eingeben und destruktives Verhalten verursachen.

✅ Konformes Beispiel

# Safe: use parameterized or validated command execution
$userInput = Read-Host "Enter username"

if ($userInput -match '^[a-zA-Z0-9_-]+$') {
    Start-Process "net" -ArgumentList "user", $userInput
} else {
    Write-Host "Invalid input"
}

Warum dies sicher ist:

• Befehlsargumente werden als Liste übergeben, nicht als verketteter String.
• Die Eingabe wird mithilfe einer Whitelist-Regex validiert.
• Keine nicht vertrauenswürdigen Daten erreichen die Shell unescaped.

Probieren Sie es in Aikido Security aus

Sie können diese Regel direkt im Code-Qualitäts-ToolAikido aktivieren.

Sobald es aktiviert ist, sucht es automatisch nach Injektionsmustern in allen unterstützten Sprachen, einschließlich derjenigen ohne native SAST .

Jedes Mal, wenn eine Entwickelnde einen Pull Request öffnet:

• Das System überprüft neuen und geänderten Code.
• Es kennzeichnet jede Verwendung von String-Verkettung oder -Interpolation innerhalb von Befehls-, Abfrage- oder Interpreter-Aufrufen.
• Der Bericht hebt die genaue Zeile hervor und bietet einen kurzen Fix-Vorschlag (zum Beispiel: „Verwenden Sie parametrisierte APIs oder validierte Eingaben“).

Diese Regel läuft bei jedem PR und gewährleistet konsistenten Schutz auch in Repositories mit gemischten Sprachen.

Fazit

Dynamische String-Konstruktion ist einer der einfachsten Fehler, der zu kritischen Sicherheitsverletzungen führen kann.

Durch die Erkennung unsicherer Verkettungen und die Erzwingung sicherer Praktiken zur Abfrageerstellung verhindert diese Regel ganze Klassen von Injection-Angriffen, bevor sie die Produktion erreichen.

Unabhängig von der Sprache vereint die intelligente Analyse Aikidostatischen und KI-gestützten Schutz, um einen größeren Bereich abzudecken, als dies mit herkömmlichen Tools jemals möglich wäre.