Antwort

In Perl gibt es zwei Syntaxformen der Konstruktion eval:

1. eval BLOCK — führt einen Codeblock als geschützten Block aus, der fatale Laufzeitfehler (runtime exceptions) abfängt. Verwendet den bestehenden Variablenbereich und erfordert keine Kompilierung des Codes zur Laufzeit.
2. eval STRING — kompiliert und führt einen String als Perl-Code zur Laufzeit aus. Kann dynamisch generierten Code ausführen und wird verwendet, um dynamische Unterprogramme zu erstellen, ist jedoch aus Sicherheitssicht riskant (kann beliebigen, potenziell gefährlichen Code ausführen, insbesondere wenn der String aus externen Daten gebildet wird).

Besonderheiten der Fehlerbehandlung:

• In beiden Fällen wird ein fataler Fehler abgefangen, und der Text des Fehlers wird in der globalen Variable $@ gespeichert (wenn ein Fehler vorlag), andernfalls ist $@ leer.
• eval BLOCK ist schneller, sicherer und vorzuziehen, wenn kein dynamischer Code ausgeführt werden muss.
• eval STRING ist praktisch für die dynamische Codeerstellung, kompiliert aber zusätzlich den String, was langsamer und potenziell gefährlicher ist.

# Beispiel für die Verwendung von eval BLOCK
my $result = eval {
    die "Error!" unless 1 + 1 == 2;
    return "OK";
};
if ($@) {
    warn "Error caught: $@";
}

# Beispiel für die Verwendung von eval STRING
my $code = '$x = 1 + 2; $x;';
my $res = eval $code;
if ($@) {
    warn "Eval string error: $@";
}

Fangfrage

Wenn dynamisch eingesetzte Variablen ohne angemessene Escaping in eval STRING eingefügt werden, können dann zusätzliche Risiken auftreten?

Ja, wenn der eingesetzte String aus Variablen gebildet wird, insbesondere aus externen Daten (z.B. Benutzereingaben), besteht die Gefahr von security/injection. Es muss immer Escaping verwendet werden oder eval STRING sollte nicht für fremde Daten verwendet werden.

my $user_code = 'system("rm -rf /");';
eval $user_code; # SEHR GEFÄHRLICH!

Beispiele für reale Fehler aufgrund fehlenden Wissens über die Feinheiten des Themas

---

Geschichte

In einem Auditskript zur Überprüfung von Parametern virtueller Maschinen wurde eval STRING verwendet, in den "aus Versehen" Daten eingefügt wurden, die aus einer externen Konfigurationsdatei gelesen wurden. Eines Tages wurde die Datei manipuliert, was zur Ausführung des Codes eines Angreifers und zur Kompromittierung des Servers führte.

---

Geschichte

Ein Entwickler umwickelte einen potenziell katastrophalen Teil des Codes in eval BLOCK und erwartete, dass es nicht nur Laufzeitfehler, sondern auch Kompilierungsfehler (z.B. Syntaxfehler) abfängt. Aber ein Syntaxfehler (z.B. ein Tippfehler im Variablennamen) wird von eval BLOCK nicht abgefangen — er führte zu einem Absturz des Prozesses.

---

Geschichte

Bei der Deserialisierung komplexer Datenstrukturen über eval STRING nach einem Dumper-Dump wurde vergessen zu überprüfen, dass der String nur gültigen Perl-Code enthält — ein Benutzer fügte durch Input Injection ausführbaren Code hinzu, was zur Ausführung schädlicher Befehle auf dem Server führte.