Eine kurze Analyse der neuesten SQL-Injection-Schwachstelle im PHP-Framework Laravel

Laravel, das bekannte PHP-Entwicklungsframework, hat zuvor im offiziellen Blog über eine hochriskante SQL-Injection-Sicherheitslücke berichtet.

Zuallererst gehört diese Schwachstelle zur unregelmäßigen Codierung der Website. Der Beamte gab einen Hinweis:

Aber der Beamte hat es trotzdem getan. Es wurde gepatcht und kann durch ein Upgrade auf die neueste Version V5.8.7 behoben werden.

Suchen wir zunächst hier:

Illuminate\Validation\Rule

Die offiziell empfohlene Schreibmethode ist:

Rule::unique('users')->ignore($id),

Wenn die Website-Codierung den Wert von $id nicht im Voraus verarbeitet, kann der Benutzer dies tun Übergeben Sie es direkt. Die Übergabe schädlicher Daten an die Ignorierfunktion führt zu einer SQL-Injection.

Folgen wir der Funktion:

\Illuminate\Validation\Rules\Unique.php class Unique {
... public function ignore($id, $idColumn = null) { if ($id instanceof Model) { return $this->ignoreModel($id, $idColumn);
        } $this->ignore = $id; $this->idColumn = $idColumn ?? 'id'; return $this;
    }

Hier betrachten wir das Schreiben von $id nicht als Instanz. Wenn $id vom Benutzer steuerbar ist, kann $idColumn direkt als leer geschrieben werden zugewiesen Die Situation ist wie folgt:

$this->ignore = $id; $this->idColumn = 'id';

Wenn der Website-Code so aufgebaut ist, ist der vom Hacker eingegebene Wert kontrollierbar:

$id = $request->input('id');

Schließlich kommen wir hierher:

Illuminate\Validation\Rules\Unique.php public function __toString() {
        ...
        ...
    }

Wir werfen einen Blick auf die Schlüsselcodeänderungen:

Illuminate\Validation\Rules\Unique.php
V5.8.7【最新版】 public function __toString() { $this->ignore ? '"'.addslashes($this->ignore).'"' : 'NULL',
    } 
Illuminate\Validation\Rules\Unique.php
V5.8.4 public function __toString() { $this->ignore ? '"'.$this->ignore.'"' : 'NULL',
    }

Der neueste Code hier ist v5.8.7, der direkt $this->ignore zu addslashes gibt. Hier gab es vorher keinen Schutz.

Interessant ist, dass der Autor die Unterschiede verglichen hat, wobei der Beamte auch versucht hat, andere zitierte Orte herauszufiltern. Schließlich wurde bei __toString eine einheitliche Filterung durchgeführt.

Abschließend wird der folgende Code in DatabaseRule für den nachfolgenden SQL-Regelabgleich eingegeben.

Illuminate\Validation\Rules\DatabaseRule.php

Danach gab es keine weitere Verarbeitung und dann wurde eine SQL-Injection gebildet.

Weitere technische Artikel zu Laravel finden Sie in der Spalte Einführungs-Tutorial zum Laravel-Framework, um mehr darüber zu erfahren!

Das obige ist der detaillierte Inhalt vonEine kurze Analyse der neuesten SQL-Injection-Schwachstelle im PHP-Framework Laravel. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!