deserialize Verwendung - so mach ich das sicher bei mir

[BugBuster]

Hi,
ich habe grad mal geschaut wie ich das in einer meinen Erweiterungen benutz habe und denke, als Erweiterungsentwickler kann man sich zumindest auf diese Art aktuell absichern.

#Serialisieren, verschlüsseln mit dem Encryption Key der Contao Installation, Base64 kodieren um Sonderzeichen zu killen, da bei mir als GET Parameter verwendet
$strEnrcypt = base64_encode( Encryption::encrypt( serialize( array( $title,$row['id'] ) ) ) );
    
#das ganze wieder rückwärts
$arrDecrypt = deserialize( Encryption::decrypt( base64_decode( Input::get('crcst') ) ) ); 

Allerdings gibt es wohl Provider, welche die PHP mcrypt Erweiterung nicht installiert haben. (wird von der Encryption Klasse verwendet)
Dafür habe ich dann noch ein Abfrage eingebaut und verwende eine eigene Klasse für die Verschlüssung, auch mit hilfe des Encryption Key der Contao Installation.


Andere Ideen? Dann her damit. Obige Lösung ist wie gesagt schon vor der Entdeckung der Lücke entstanden.

[BugBuster]

Noch mal kurz zur Erläuterung warum ich das verschlüsselt habe.
In meinem speziellem Fall wird eine PHP direkt aufgerufen per Browser, der per GET eine Aufgabe übergeben wird.
Damit nun nicht jeder einfach "Jobs" da hinschicken kann, habe ich das verschlüsselt.

Das wird in anderen Erweiterungen nicht der Fall sein, und da würden sicherlich die Änderungen die noch für Contao kommen sollen ausreichend Abhilfe schaffen.

[xtra]

Damit nun nicht jeder einfach "Jobs" da hinschicken kann, habe ich das verschlüsselt.

Was abgesehen von der deserialize Problematik nochmal eine ganz andere Sicherheitslycke aufwerfen wyrde.

Abgesehen davon, was spricht in deinem Falle dagegen json_encode und json_decode zu verwenden?

[BugBuster]

Und da gibts die Probleme nicht? Kenn mich mit json nicht aus, aber wäre auch ne Alternative.

[psren]

Nein die gibt es dann nicht. Es geht nur um die __wakeup() Methode die bei unserialize aufgerufen wird wenn ich das richtig verstanden habe.
(Bzw. die wird bei unserialize automatisch ausgeführt)


Bitte korrigiert mich wenn ich falsch liege.

[Spooky]

Naja, aber der destructor zB würde ja trotzdem aufgerufen werden, hätte ich mir zumindest gedacht. Dieser Artikel schreibt auch, dass man stattdessen die JSON Funktionen nehmen sollen, aber warum gerade die keine Object Injection verursacht, verstehe ich auch nicht. Oder ist das nur der Fall wenn man immer json_decode( ..., true ); verwendet (und bei json_decode( ... ); wäre eine Object Injection wieder möglich).

Davon abgesehen ist json_encode und _decode angeblich schneller als serialize und unserialize und verbraucht auch weniger Platz.

[psren]

Naja, aber der destructor zB würde ja trotzdem aufgerufen werden, hätte ich mir zumindest gedacht.

Ich meine dass theoretisch jede Methode missbraucht werden könnte. Bin mir aber nicht ganz sicher.

aber warum gerade die ([...] JSON [...]) keine Object Injection verursacht, verstehe ich auch nicht

Weil es keine PHP-Objekte gibt. serialisierte Objekte werden mit unserialize sozusagen wieder zum Leben erweckt. Das sind dann PHP-Objekte.
Bei JSON ist es ein einfacher String. wenn du json_decode wird es zu einem Array und nicht zu einem Objekt (Naja... bis auf JSON-Objekte die werden zu einer Std-Objekt). Der zweite Parameter macht alles zu einem Array.

[Spooky]

Aaah, got it now .

[xtra]

Nein die gibt es dann nicht. Es geht nur um die __wakeup() Methode die bei unserialize aufgerufen wird wenn ich das richtig verstanden habe. (Bzw. die wird bei unserialize automatisch ausgeführt)
Bitte korrigiert mich wenn ich falsch liege.

Mach ich
__wakeup wird automatisch ausgefyhrt, korrekt. __destruct hingegen auch jedesmal, selbst wenn die __wakeup einen Fehler melden sollte.

Ich meine dass theoretisch jede Methode missbraucht werden könnte. Bin mir aber nicht ganz sicher.

Nein, nur __wakeup und __destruct sind anfaellig.

Weil es keine PHP-Objekte gibt. serialisierte Objekte werden mit unserialize sozusagen wieder zum Leben erweckt. Das sind dann PHP-Objekte.
Bei JSON ist es ein einfacher String. wenn du json_decode wird es zu einem Array und nicht zu einem Objekt (Naja... bis auf JSON-Objekte die werden zu einer Std-Objekt). Der zweite Parameter macht alles zu einem Array.

Exakt das behebt die Problematik.
json_encode und json_decode sind keine PHP nativen Serialisierungsmechanismen, hierbei kann man eigentlich alles aufzaehlen was man mag, XML, json, sogar die guten alten .ini Dateien kann man nehmen oder eine simple Textdatei.
Dann braucht man jedoch eine Programmlogik, welche Objekte aus diesen Daten erzeugt und in dieses Format umwandelt. Diese Methoden myssten dann aber noch sicher stellen, dass nicht einfach ein boeser Bube da was reintun kann, was das System kaputt macht (Stichwort: input validation).
Dies kann die Methode unserialize jedoch nicht, sondern sie erzeugt, gutglaeubig wie sie ist, einfach stupide die Objekte wie sie in den Eingabedaten stehen und ruft dann auch noch die __wakeup Methode auf um Bescheid zu sagen, dass das Objekt nun deserialisiert wurde.

json_decode erzeugt nun aber maximal stdClass Objekte, welche weder __destruct noch __wakeup implementieren und somit nicht per se anfaellig sind, sofern man die Daten dann nicht auch einfach ungefiltert weiter verwendet.

Gruss
Chris

[psren]

Nein, nur __wakeup und __destruct sind anfaellig.

Und das macht nix?

$objUnserialized = unserialize($serializedStringWithisThisMethodDangerousMethod);
$objUnserialized->isThisMethodDangerous(); 

Sorry für die vielleicht dumme Frage aber mit serialisierten Objekten habe ich mich nicht wirklich auseinandergesetzt.

[Spooky]

$objUnserialized->isThisMethodDangerous(); wird ja nicht automatisch aufgerufen. Nur __wakeup() und __destruct() werden aufgerufen, wenn man ein Object so injected.

[psren]

$objUnserialized->isThisMethodDangerous(); wird ja nicht automatisch aufgerufen.

Ich weiß. Aber falls irgendwo im Code eine Methode aufgerufen wird könnte man die nutzen?

(Wie gesagt als Frage, weil ich von serialisierten Objekten wenig Plan habe)