Sicherheit und Zustand der PHP-SDK
Die SDK liest nicht vertrauenswürdige Projektdateien und kann sie bei aktivierter Behebung ändern. Behandeln Sie einen Scan als privilegierte Operation mit einem expliziten Ziel, kontrolliertem Speicher und einem Prüfpfad für jeden Fund.
Prozessglobaler Zustand
Scanner speichert seine Konfiguration und den aktuellen Bericht in statischem Zustand. Fluent Setter geben eine neue Scanner-Instanz zurück, ändern jedoch diesen prozessweiten gemeinsamen Zustand.
$first = new Scanner();
$second = $first->setPathScan('/srv/project-a');
// Both objects observe the same Scanner configuration.
Führen Sie in jedem PHP-Prozess jeweils nur einen Scan aus. Verwenden Sie einen neuen CLI-Prozess für Hintergrundjobs, gleichzeitige Anfragen oder die Mandantenisolation. Ein langlebiger Worker muss vor jedem Lauf die vollständige Konfiguration anwenden und darf keinen Zustand aus einem vorherigen Job wiederverwenden.
run() setzt den Bericht zu Beginn eines Scans zurück. Die umfassendere Scanner-Konfiguration wird dadurch nicht zurückgesetzt. Verlassen Sie sich nicht darauf, dass die Objekterstellung Standardwerte wiederherstellt.
Dateiaktionen
Das Standardverhalten bei Abfragen unterscheidet sich zwischen interaktiven und stillen Läufen. Wählen Sie in unbeaufsichtigtem Code explizit eine Aktion:
$report = (new Scanner())
->setPathScan('/srv/app')
->setSilentMode()
->setAutoSkip()
->run();
Rufen Sie bei jeder Aktion, die Dateien ändert, enableBackups() auf und setzen Sie setPathBackups() auf ein beschreibbares Verzeichnis außerhalb des Ziels. Halten Sie Quarantäne, Whitelist, Deobfuskation, Berichte, Protokolle, dauerhafte Funde und Checkpoints außerhalb des gescannten Projekts, damit der Scanner seine eigene Ausgabe nicht prüft.
Vor dem Aktivieren automatischer Bereinigung, Quarantäne oder Löschung:
- Führen Sie reine Berichtsscans mit repräsentativen Kopien der Anwendung aus.
- Prüfen Sie bei jedem Lauf
coverage,findingsunddiagnostics. - Testen Sie Sicherungs- und Wiederherstellungsverfahren unter demselben Konto, das Produktionsscans ausführt.
- Beschränken Sie den Zielpfad auf genehmigte Projektstämme.
Pfade und Berechtigungen
Übergeben Sie absolute Pfade aus vertrauenswürdiger Konfiguration. Normalisieren und autorisieren Sie aus Anfragen abgeleitete Pfade, bevor Sie setPathScan(), setPathReport() oder einen anderen Pfad-Setter aufrufen. Die SDK normalisiert Pfade mit Path::get(), die Normalisierung erzwingt jedoch nicht die Autorisierungsgrenze Ihrer Anwendung.
Führen Sie den Scanner mit den geringstmöglichen Dateisystemberechtigungen aus, die zum Lesen des Ziels und Schreiben seiner kontrollierten Ausgabe erforderlich sind. Führen Sie eine Webanfrage nicht unter einem Konto aus, das Dateien außerhalb des vorgesehenen Bereitstellungsstamms scannen oder löschen kann.
Netzwerkverhalten und Offlinebetrieb
Das Scannen des Kerncodes verwendet eingebettete Definitionen. Integritätsprüfung und Maltrail-Domänendefinitionen können ausgehendes HTTPS verwenden. Der Scanner speichert erfolgreiche Remote-Daten in einem Cache des Betriebssystems außerhalb des Scanziels.
Wenn Ihre Umgebung ausgehenden Datenverkehr blockiert, erfassen und bewahren Sie Berichtsdiagnosen auf. Ein fehlgeschlagenes Update kann zwischengespeicherte Definitionen aktiv lassen; der Bericht zeichnet verfügbare Metadaten in signature_indexes auf. Gehen Sie bei fehlender Netzwerkroute nicht von einem leeren Diagnosenarray aus.
Fehlerrichtlinie
Behandeln Sie false von run() als Betriebsfehler. Behandeln Sie unvollständige Abdeckung, Diagnosen und Warnungen als Prüfsignale. Speichern Sie den Bericht mit seinem Scanzeitstempel, der Zielidentität, der Scannerversion von Scanner::getVersion() und einer externen Jobkennung.
Die SDK stellt abgefangene Fehlermeldungen über getLastError() bereit. Protokollieren Sie diese in einem geschützten Anwendungsprotokoll. Geben Sie nicht vertrauenswürdigen Benutzern keine Zielpfade, Berichtsinhalte oder Rohfehlermeldungen preis.