Zum Hauptinhalt springen

PHP · SAST

PHP-SAST, das vollständig offline läuft

Auditieren Sie Laravel, Symfony, WordPress und Legacy-PHP auf SQL-Injection, XSS, File Inclusion und Konfigurations-Drift — ohne Code in eine Drittanbieter-Cloud hochzuladen.

Geprüfte Frameworks & Bibliotheken

Wir testen die Abdeckung über Fixtures auf diesen Frameworks. Neue Muster werden in jedem Builtin-Regel-Release ergänzt.

Laravel Symfony WordPress Drupal CodeIgniter Yii CakePHP Slim Phalcon Doctrine Eloquent PDO mysqli Composer PHPMailer Twig Blade

Häufigste erkannte CWE-Klassen

Diese CWE-Klassen treten in modernen Codebasen dieser Sprache am häufigsten auf. StaticCodeAudit liefert dedizierte Regeln für jede, gemappt auf OWASP Top 10 / ISO 27001 / ASVS, sofern relevant.

CWE-89

SQL-Injection

mysql_query("... " . $_GET['id']), $pdo->query() mit Concat, Laravel DB::raw() mit User-Input, WordPress $wpdb->query mit nicht-escapeden Variablen.

Erkannt von SCA-Regel: sql_injection_concat

CWE-79

Cross-Site Scripting (XSS)

echo $_GET['name'] ohne htmlspecialchars, Twig {{ var|raw }}, WordPress esc_attr bei User-Daten fehlt.

Erkannt von SCA-Regel: xss_raw_html

CWE-78

OS-Befehlsinjektion

system($cmd), exec(), shell_exec(), passthru() mit User-Input. PHPs Shell-Funktionen interpretieren standardmäßig Metazeichen.

Erkannt von SCA-Regel: command_injection_php

CWE-98

File Inclusion (RFI/LFI)

include $_GET['page'] oder require mit user-kontrollierten Pfaden. Erlaubt beliebiges Datei-Lesen, manchmal Remote Code Execution.

Erkannt von SCA-Regel: path_traversal_os_join

CWE-502

Unsichere Deserialisierung

unserialize($_GET['data']) auf User-Input. PHPs native Serialisierung ist ein bekannter Gadget-Vektor (phpggc).

Erkannt von SCA-Regel: unsafe_deserialization

CWE-798

Hartkodierte Zugangsdaten

DB-Zugangsdaten in commitetem config.php, WordPress wp-config.php in öffentlichem Repo, API-Keys als Konstanten.

Erkannt von SCA-Regel: hardcoded_secret

Verwundbar vs. sicher — drei kurze Beispiele

CWE-89 Erkannt von SCA-Regel: sql_injection_concat
❌ Verwundbar
// Verwundbar — direkte Konkatenation
$sql = "SELECT * FROM users WHERE id = " . $_GET['id'];
$result = $mysqli->query($sql);
✅ Sicher
// Sicher — Prepared Statement
$stmt = $mysqli->prepare("SELECT * FROM users WHERE id = ?");
$stmt->bind_param("i", $_GET['id']);
$stmt->execute();
CWE-79 Erkannt von SCA-Regel: xss_raw_html
❌ Verwundbar
// Verwundbar — rohes echo
echo "<p>Hello, " . $_GET['name'] . "</p>";
✅ Sicher
// Sicher — htmlspecialchars mit ENT_QUOTES + UTF-8
echo "<p>Hello, " . htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8') . "</p>";
CWE-78 Erkannt von SCA-Regel: command_injection_php
❌ Verwundbar
// Verwundbar — Shell-Metazeichen-Missbrauch
system("convert " . $_FILES['img']['tmp_name'] . " /var/thumb.jpg");
✅ Sicher
// Sicher — escapeshellarg + 2-Arg-Form
$src = escapeshellarg($_FILES['img']['tmp_name']);
system("convert {$src} /var/thumb.jpg");

Was StaticCodeAudit erkennt (diese Sprache)

  • SQL-Injection in PDO-Concat, mysqli ohne Prepared Statements, Laravel DB::raw, WordPress $wpdb-Concat
  • XSS via rohes echo, Twig |raw, fehlende htmlspecialchars / esc_attr
  • Befehlsinjektion in system, exec, shell_exec, passthru, popen
  • File Inclusion (LFI/RFI) via include, require auf user-kontrollierten Pfaden
  • Unsichere Deserialisierung via unserialize auf User-Daten
  • Hartkodierte Zugangsdaten in committeter config.php, wp-config.php, .env
  • Unsichere Session-Konfiguration (session.cookie_secure, session.cookie_httponly aus)
  • Open Redirect via header("Location: " . $_GET['url'])
  • Path Traversal in file_get_contents, fopen mit User-Pfaden
  • Unsichere Krypto (MD5/SHA1, mcrypt veraltet, hartkodierte Keys/IVs)
  • Fehlendes CSRF-Token bei POST-Endpoints
  • PHP-Fehleranzeige in Produktion aktiviert (display_errors=On)
  • Veraltete APIs (mysql_*, ereg, split, php-fpm pm.user=root)
  • CI/CD-Fehlkonfigurationen (.gitlab-ci, GitHub Actions, Composer-Scripts)

Neugierig, wie die Erkennungsqualität tatsächlich gemessen wird? Sehen Sie sich die vollständige sprachübergreifende Benchmark-Methodik an (OWASP Benchmark, NIST Juliet, Precision/Recall/F1 pro Sprache) →

CVE Test Suite — Laravel und PHP-stdlib

StaticCodeAudit wurde gegen eine reale CVE Test Suite gemessen: 45 Fälle, rekonstruiert aus veröffentlichten, historischen CVEs über 8 Frameworks und 5 Sprachen. Laravel und die PHP-Standardbibliothek sind beide dabei.

80,0%
Bester F1 (Laravel)
100%
Bester Recall
45
CVE Test Suite (gesamt, alle Sprachen)

Nach Framework, aus CVE rekonstruiert

80,0%
Laravel (aus CVE rekonstruiert)
72,7%
PHP-stdlib (aus CVE rekonstruiert)

Laravel erreicht 100% Precision bei 66,7% Recall; PHP-stdlib erreicht 80,0% Precision bei 66,7% Recall — solide, nicht perfekt: einige echte historische CVEs bei beiden rutschen noch durch. Vollständige sprachübergreifende Aufschlüsselung (auch wo ASP.NET und Express schlechter abschneiden) auf der <a href="/de/language-benchmarks.php" class="text-primary font-semibold hover:underline">Sprachbenchmark-Seite</a>.

Echte Schwachstellen passen selten in eine einzige Datei

Laravel-Anwendungen verteilen die Logik auf mehrere Schichten: ein Controller empfängt die Anfrage, ein Model oder Query-Builder baut die Abfrage. Ein Scanner, der jeweils nur eine Datei sieht, verbindet die beiden nie — er sieht die Nutzereingabe in OrderController.php und den Datenbankaufruf in Order.php, aber nie die Verbindung dazwischen. StaticCodeAudit verfolgt die Daten über Dateigrenzen hinweg.

OrderController.php
public function show(Request $request)
{
    $id = $request->query('id');
    return Order::find($id);
}
Order.php
public static function find($id)
{
    return DB::select(
        "SELECT * FROM orders WHERE id = $id"
    );
}

id stammt aus dem Query-String im Controller und erreicht die rohe SQL-Abfrage eine Datei später unverändert — StaticCodeAudit meldet dies genau in der Zeile, in der die Abfrage ausgeführt wird.

Wie schneidet das im Vergleich zu Psalm oder Semgrep ab?

Psalms Taint-Analyse-Modus und Semgrep sind die zwei Tools, die als Erstes genannt werden, wenn ein PHP-Team nach einem kostenlosen Security-Scanner sucht. Beide sind legitim, und viele Teams nutzen bereits eines davon — hier ein ehrlicher Vergleich, keine Abwertung.

Psalm (Taint-Modus)

Kostenlos, Open Source

Statischer Analyzer, primär für Typprüfung gebaut, mit einem optionalen Taint-Analyse-Modus, der Nutzereingaben bis zu gefährlichen Sinks verfolgt (SQLi, XSS, Command Injection). Solide Engine, aber der Security-Modus braucht explizite Konfiguration und Typ-Annotationen, um wirksam zu sein, und Findings sind standardmäßig nicht auf CWE/ISO 27001/ASVS gemappt.

Semgrep (Community)

Kostenlos, Open-Source-Kern

Pattern-Matching-Engine, die viele Sprachen abdeckt, darunter PHP, mit einem großen offenen Regel-Register. Der kostenlose Tier deckt die meisten Alltagsregeln ab; dateiübergreifendes Taint-Tracking, Compliance-Reporting und einige Enterprise-Integrationen sind Semgreps kostenpflichtigen Tiers vorbehalten.

Vollständiger Vergleich StaticCodeAudit vs. Semgrep →

Keines der beiden wird durch die Installation von StaticCodeAudit ersetzt — wenn Psalm bereits das abdeckt, was Ihr Team braucht, nutzen Sie es weiter. Was StaticCodeAudit hinzufügt: Findings, die bereits auf CWE/OWASP/ISO 27001/ASVS/NIST CSF gemappt sind (ein Finding, das direkt in eine Audit-Akte passt, nicht nur eine Regel-ID), Taint-Tracking, das ohne vorherige Typ-Annotationsarbeit sofort funktioniert, und 7 weitere Sprachen, die von derselben Binary abgedeckt werden — kein separater Scanner pro Sprache zu konfigurieren. Viele Teams nutzen beides.

Auditieren Sie Ihren Code

Auditieren Sie Laravel, Symfony, WordPress und Legacy-PHP auf SQL-Injection, XSS, File Inclusion und Konfigurations-Drift — ohne Code in eine Drittanbieter-Cloud hochzuladen.

Demo-Binary herunterladen Geführte Demo buchen