perlsec - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

perlsec - Perl-Sicherheit

BESCHREIBUNG

Perl ist so konzipiert, dass es einfach ist, sicher zu programmieren, auch wenn es mit zusätzlichen
Privilegien, wie setuid- oder setgid-Programme. Im Gegensatz zu den meisten Befehlszeilen-Shells, die
basierend auf mehreren Ersetzungsdurchgängen in jeder Zeile des Skripts verwendet Perl ein more
konventionelles Bewertungsschema mit weniger versteckten Haken. Außerdem, weil die
Sprache hat mehr eingebaute Funktionalität, sie kann sich weniger auf externe (und möglicherweise
nicht vertrauenswürdige) Programme, um ihre Zwecke zu erfüllen.

SICHERHEIT VERLETZLICHKEIT KONTAKT INFORMATIONEN

Wenn Sie glauben, eine Sicherheitslücke in Perl gefunden zu haben, senden Sie bitte eine E-Mail an
[E-Mail geschützt] mit Einzelheiten. Dies weist auf ein geschlossenes Abonnement hin,
nicht archivierte Mailingliste. Bitte verwenden Sie diese Adresse nur für Sicherheitsprobleme im Perl
Kern, nicht für Module, die unabhängig auf CPAN verteilt werden.

SICHERHEIT MECHANISMEN UND SORGEN

Verderben Modus
Perl aktiviert automatisch eine Reihe spezieller Sicherheitsprüfungen, genannt verderben Modus, wenn es
erkennt, dass sein Programm mit unterschiedlichen echten und effektiven Benutzer- oder Gruppen-IDs ausgeführt wird. Die
setuid-Bit in Unix-Berechtigungen ist Modus 04000, das setgid-Bit-Modus 02000; entweder oder
eingestellt werden darf. Sie können den Taint-Modus auch explizit aktivieren, indem Sie die -T Kommandozeilen-Flag.
Diese Flagge ist starker empfohlen für Serverprogramme und alle Programme, die im Auftrag von laufen
eine andere Person, beispielsweise ein CGI-Skript. Sobald der Taint-Modus aktiviert ist, ist er für den Rest des
dein Skript.

In diesem Modus trifft Perl besondere Vorsichtsmaßnahmen, die als verderben Schecks um beides zu verhindern
offensichtliche und subtile Fallen. Einige dieser Prüfungen sind relativ einfach, wie z
dass Pfadverzeichnisse für andere nicht beschreibbar sind; vorsichtige Programmierer haben immer verwendet
Kontrollen wie diese. Andere Prüfungen werden jedoch am besten von der Sprache selbst unterstützt, und
Gerade diese Prüfungen tragen dazu bei, ein set-id-Perl-Programm sicherer zu machen
als das entsprechende C-Programm.

Sie dürfen Daten, die von außerhalb Ihres Programms stammen, nicht verwenden, um etwas anderes außerhalb zu beeinflussen
Ihr Programm - zumindest nicht aus Versehen. Alle Befehlszeilenargumente, Umgebung
Variablen, Locale-Informationen (siehe Perllocale), Ergebnisse bestimmter Systemaufrufe
("readdir()", "readlink()", die Variable von "shmread()", die von . zurückgegebenen Nachrichten
„msgrcv()“, das Passwort, die gcos- und Shell-Felder, die von den „getpwxxx()“-Aufrufen zurückgegeben werden) und
alle Dateieingaben werden als "befleckt" markiert. Verfälschte Daten dürfen nicht direkt verwendet werden oder
indirekt in jedem Befehl, der eine Sub-Shell aufruft, noch in jedem Befehl, der modifiziert
Dateien, Verzeichnisse oder Prozesse, mit die Folgende Ausnahmen:

· Argumente für "print" und "syswrite" sind nicht auf Verunreinigung geprüft.

· Symbolische Methoden

$obj->$method(@args);

und symbolische Unterreferenzen

&{$foo}(@args);
$foo->(@args);

werden nicht auf Verunreinigung geprüft. Dies erfordert besondere Sorgfalt, es sei denn, Sie möchten
externe Daten, um Ihren Kontrollfluss zu beeinflussen. Es sei denn, Sie beschränken sorgfältig, was diese
symbolische Werte sind, Menschen können Funktionen aufrufen aussen Ihr Perl-Code, wie zum Beispiel
POSIX::system, in diesem Fall können sie beliebigen externen Code ausführen.

· Hash-Schlüssel sind niemals verdorben.

Aus Effizienzgründen vertritt Perl eine konservative Sicht darauf, ob Daten verfälscht sind. Wenn ein
Ausdruck enthält verfälschte Daten, kann jeder Unterausdruck als verfälscht betrachtet werden, auch wenn der
Der Wert des Unterausdrucks selbst wird von den gefärbten Daten nicht beeinflusst.

Da mit jedem Skalarwert Verunreinigung verbunden ist, können einige Elemente eines Arrays oder
Hash kann verdorben sein und andere nicht. Die Schlüssel eines Hashs sind niemals verdorben.

Beispielsweise:

$arg = verschieben; # $arg ist verdorben
$versteckt = $arg . 'Bar'; # $hid ist auch verdorben
$zeile = <>; # Verdorben
$line = ; # Auch verdorben
öffne FOO, "/home/me/bar" oder stirb $!;
$line = ; # Immer noch verdorben
$pfad = $ENV{'PFAD'}; # Befleckt, aber siehe unten
$daten = 'abc'; # Nicht verdorben

system "echo $arg"; # Unsicher
System "/bin/echo", $arg; # Gilt als unsicher
# (Perl weiß nichts davon /bin/echo)
system "echo $hid"; # Unsicher
System "echo $data"; # Unsicher bis PATH gesetzt

$pfad = $ENV{'PFAD'}; # $path jetzt verdorben

$ENV{'PFAD'} = '/Behälter:/ usr / bin';
@ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'} löschen;

$pfad = $ENV{'PFAD'}; # $path jetzt NICHT verdorben
System "echo $data"; # Ist jetzt sicher!

open(FOO, "< $arg"); # OK - schreibgeschützte Datei
open(FOO, "> $arg"); # Nicht OK - versuche zu schreiben

open(FOO,"echo $arg|"); # Nicht ok
open(FOO,"-|")
oder exec 'echo', $arg; # Auch nicht in Ordnung

$schrei = `echo $arg`; # Verunsichert, $shout jetzt verdorben

entlinke $data, $arg; # Unsicher
umask $arg; # Unsicher

exec "echo $arg"; # Unsicher
exec "echo", $arg; # Unsicher
exec "sh", '-c', $arg; # Sehr unsicher!

@files = <*.c>; # unsicher (verwendet readdir() oder ähnliches)
@files = glob('*.c'); # unsicher (verwendet readdir() oder ähnliches)

# In beiden Fällen sind die Ergebnisse von glob verfälscht, da die Liste der
# Dateinamen kommen von außerhalb des Programms.

$schlecht = ($arg, 23); # $bad wird verdorben
$arg, `wahr`; # unsicher (obwohl es nicht wirklich ist)

Wenn Sie versuchen, etwas Unsicheres zu tun, erhalten Sie einen schwerwiegenden Fehler, der so etwas sagt wie
"Unsichere Abhängigkeit" oder "Unsicheres $ENV{PATH}".

Die Ausnahme vom Prinzip "ein verdorbener Wert verdirbt den ganzen Ausdruck" ist mit
der ternäre Bedingungsoperator "?:". Da Code mit einer ternären Bedingung

$result = $tainted_value ? "Unbefleckt" : "Auch unbefleckt";

ist effektiv

if ( $tainted_value ) {
$result = "Unbefleckt";
} Else {
$result = "Auch unbefleckt";
}

Es macht keinen Sinn, dass $result verdorben ist.

Waschen und Erkennung Verdorben Datum
Um zu testen, ob eine Variable verfälschte Daten enthält und deren Verwendung somit eine
Meldung "Unsichere Abhängigkeit" können Sie die Funktion "tainted()" des Scalar::Util verwenden
-Modul, verfügbar in Ihrem CPAN-Spiegel in der Nähe und in Perl ab dem
Version 5.8.0. Oder Sie können die folgende Funktion "is_tainted()" verwenden.

sub is_tainted {
lokales $@; # Verschmutzen Sie nicht den Wert des Anrufers.
Rückkehr ! eval { eval("#" . substr(join("", @_), 0, 0)); 1};
}

Diese Funktion macht sich die Tatsache zunutze, dass das Vorhandensein verfälschter Daten überall innerhalb eines
Ausdruck macht den gesamten Ausdruck verdorben. Es wäre für jeden ineffizient
Operator, um jedes Argument auf Verdorbenheit zu testen. Stattdessen sind die etwas effizienteren und
Es wird ein konservativer Ansatz verwendet, bei dem auf einen verdorbenen Wert innerhalb desselben zugegriffen wurde
Ausdruck wird der gesamte Ausdruck als verdorben betrachtet.

Aber das Testen auf Verdorbenheit bringt Sie nur so weit. Manchmal musst du nur deine löschen
Verunreinigung der Daten. Werte können unbefleckt sein, indem sie als Schlüssel in einem Hash verwendet werden; Andernfalls
Die einzige Möglichkeit, den Verfärbungsmechanismus zu umgehen, besteht darin, auf Untermuster von einem regulären zu verweisen
Ausdruck übereinstimmen. Perl geht davon aus, dass, wenn Sie mit $1, $2 usw. auf einen Teilstring verweisen, in a
nicht verfälschendes Muster, dass Sie wussten, was Sie taten, als Sie dieses Muster schrieben. Dass
bedeutet, ein bisschen nachzudenken - entferne nicht einfach blind alles, oder du besiegst die
gesamten Mechanismus. Es ist besser zu überprüfen, ob die Variable nur gute Zeichen hat (für
bestimmte Werte von "gut"), anstatt zu prüfen, ob es irgendwelche schlechten Zeichen enthält. Das ist
weil es viel zu leicht ist, schlechte Charaktere zu übersehen, an die Sie nie gedacht haben.

Hier ist ein Test, um sicherzustellen, dass die Daten nur "Wort"-Zeichen enthalten
(Alphabetik, Numerik und Unterstrich), einen Bindestrich, ein At-Zeichen oder einen Punkt.

if ($daten =~ /^([-\@\w.]+)$/) {
$daten = $1; # $data jetzt unbefleckt
} Else {
die "Fehlerhafte Daten in '$data'"; # protokolliere das irgendwo
}

Dies ist ziemlich sicher, da "/\w+/" normalerweise nicht mit Shell-Metazeichen übereinstimmt
Punkt, Bindestrich oder bei der Shell etwas Besonderes bedeuten. Gebrauch von "/.+/" hätte
war theoretisch unsicher, weil es alles durchlässt, aber Perl sucht nicht nach
das. Die Lektion ist, dass Sie beim Entfärben äußerst vorsichtig mit Ihrem
Muster. Das Waschen von Daten mit regulären Ausdrücken ist die einzige Mechanismus zum Entfärben
schmutzige Daten, es sei denn, Sie verwenden die unten beschriebene Strategie, um ein untergeordnetes Kind abzuspalten
Privileg.

Das Beispiel entfärbt $data nicht, wenn "Gebietsschema verwenden" aktiviert ist, da die Zeichen
mit "\w" übereinstimmen, werden durch das Gebietsschema bestimmt. Perl betrachtet Locale-Definitionen als
nicht vertrauenswürdig, weil sie Daten von außerhalb des Programms enthalten. Wenn Sie a . schreiben
länderspezifisches Programm und möchten Daten mit einem regulären Ausdruck waschen, der "\w" enthält,
Setzen Sie im selben Block "kein Gebietsschema" vor den Ausdruck. Siehe "SICHERHEIT" in perlocale
für weitere Diskussionen und Beispiele.

Switches On die "#!" Line
Wenn Sie ein Skript ausführbar machen, um es als Befehl nutzbar zu machen, muss das System
übergibt Schalter aus dem #!-Skript des Skripts an Perl. Leitung. Perl überprüft, ob jede Befehlszeile
Schalter, die einem setuid- (oder setgid-)Skript zugewiesen werden, stimmen tatsächlich mit denen überein, die auf dem #! Leitung.
Einige Unix- und Unix-ähnliche Umgebungen erlegen dem #! Linie, also kannst du
müssen in solchen Systemen so etwas wie "-wU" anstelle von "-w -U" verwenden. (Dieses Problem
sollte nur in Unix- oder Unix-ähnlichen Umgebungen auftreten, die #! und setuid oder setgid
Skripte.)

Verderben Modus und @INK
Wenn der Taint-Modus ("-T") aktiv ist, wird das "." Verzeichnis wird aus @INC entfernt und die
Die Umgebungsvariablen "PERL5LIB" und "PERLLIB" werden von Perl ignoriert. Du kannst noch anpassen
@INC von außerhalb des Programms, indem Sie die Befehlszeilenoption "-I" verwenden, wie in . erklärt
perlrun. Die beiden Umgebungsvariablen werden ignoriert, da sie verdeckt sind und ein Benutzer
Das Ausführen eines Programms könnte nicht wissen, dass sie gesetzt sind, während die Option "-I" eindeutig ist
sichtbar und daher erlaubt.

Eine andere Möglichkeit, @INC zu ändern, ohne das Programm zu ändern, besteht darin, das Pragma "lib" zu verwenden.
z.B:

perl -Mlib=/foo Programm

Der Vorteil der Verwendung von "-Mlib=/foo" gegenüber "-I/foo" besteht darin, dass ersteres automatisch will
Entfernen Sie alle duplizierten Verzeichnisse, während letztere dies nicht tun.

Beachten Sie, dass das folgende Problem gemeldet wird, wenn @INC eine gefärbte Zeichenfolge hinzugefügt wird:

Unsichere Abhängigkeit in require beim Ausführen mit -T-Schalter

Reinigung Up Ihr Path
Für "Unsichere $ENV{PATH}"-Nachrichten müssen Sie $ENV{'PATH'} auf einen bekannten Wert setzen und
jedes Verzeichnis im Pfad muss absolut sein und darf nicht von anderen als seinem Besitzer beschrieben werden und
Gruppe. Sie werden vielleicht überrascht sein, diese Nachricht zu erhalten, selbst wenn der Pfadname zu Ihrer ausführbaren Datei
ist voll qualifiziert. Das ist nicht generiert, weil Sie keinen vollständigen Pfad zum angegeben haben
Programm; Stattdessen wird es generiert, weil Sie Ihre PATH-Umgebungsvariable nie festlegen, oder
Sie haben es nicht auf etwas Sicheres eingestellt. Da Perl nicht garantieren kann, dass die
Die fragliche ausführbare Datei wird sich nicht selbst umdrehen und ein anderes Programm ausführen
das von Ihrem PATH abhängig ist, stellt sicher, dass Sie den PATH festlegen.

Der PATH ist nicht die einzige Umgebungsvariable, die Probleme verursachen kann. Weil einige
Shells können die Variablen IFS, CDPATH, ENV und BASH_ENV verwenden, Perl prüft, ob dies der Fall ist
beim Starten von Unterprozessen entweder leer oder unbefleckt. Vielleicht möchten Sie etwas hinzufügen wie
dies zu Ihren Setid- und Taint-Checking-Skripten.

lösche @ENV{qw(IFS CDPATH ENV BASH_ENV)}; # %ENV sicherer machen

Es ist auch möglich, mit anderen Operationen in Schwierigkeiten zu geraten, denen es egal ist, ob sie
verdorbene Werte verwenden. Nutzen Sie die Dateitests mit Bedacht im Umgang mit jedem Benutzer-
gelieferten Dateinamen. Wenn möglich, öffnen Sie und so nachdem jedes Special richtig fallen lassen
Benutzer- (oder Gruppen-!) Berechtigungen. Perl hindert Sie nicht daran, fehlerhafte Dateinamen für zu öffnen
lesen, also seien Sie vorsichtig, was Sie ausdrucken. Der Verfärbungsmechanismus soll verhindern, dass
dumme Fehler, nicht um die Notwendigkeit des Nachdenkens zu beseitigen.

Perl ruft die Shell nicht auf, um Wildcards zu erweitern, wenn Sie "system" und "exec" übergeben.
explizite Parameterlisten anstelle von Strings mit möglichen Shell-Wildcards darin.
Leider bieten die Funktionen "Öffnen", "Glob" und "Backtick" keine solche Alternative
Aufrufkonvention, so dass mehr Täuschung erforderlich ist.

Perl bietet eine einigermaßen sichere Möglichkeit, eine Datei oder Pipe von einer setuid oder setgid aus zu öffnen
Programm: Erstellen Sie einfach einen untergeordneten Prozess mit eingeschränkten Rechten, für den die Drecksarbeit erledigt wird
Sie. Verzweigen Sie zuerst ein Kind mit der speziellen "offenen" Syntax, die das Eltern- und
Kind durch eine Pfeife. Jetzt setzt das Kind seinen ID-Satz und alle anderen prozessbezogenen Attribute zurück.
wie Umgebungsvariablen, umasks, aktuelle Arbeitsverzeichnisse, zurück zu den Originalen oder
bekannte sichere Werte. Dann wird der untergeordnete Prozess, der keine Sonderrechte mehr hat,
führt das "Öffnen" oder einen anderen Systemaufruf aus. Schließlich übergibt das Kind die Daten, die es verwaltet hat
Zugriff auf die Eltern zurück. Weil die Datei oder Pipe während der Ausführung im Kind geöffnet wurde
unter weniger Privilegien als die Eltern, ist es nicht wahrscheinlich, dass es dazu gebracht wird, etwas zu tun
sollte nicht.

Hier ist eine Möglichkeit, Backticks einigermaßen sicher auszuführen. Beachten Sie, dass "exec" nicht mit aufgerufen wird
eine Schnur, die die Schale ausdehnen könnte. Dies ist bei weitem der beste Weg, um etwas zu nennen, das
kann Shell-Escapes ausgesetzt sein: Rufen Sie die Shell einfach nie auf.

Benutze Englisch;
sterben "Can't Fork: $!" außer definiert($pid = open(KID, "-|"));
if ($pid) { # Elternteil
während ( ) {
# etwas tun
}
KID schließen;
} Else {
mein @temp = ($EUID, $EGID);
meine $orig_uid = $UID;
mein $orig_gid = $GID;
$EUID = $UID;
$EGID = $GID;
# Berechtigungen verwerfen
$UID = $orig_uid;
$GID = $orig_gid;
# Achte darauf, dass die Privaten wirklich weg sind
($EUID, $EGID) = @temp;
sterben "Kann Privilegien nicht verlieren"
außer $UID == $EUID && $GID eq $EGID;
$ENV{PATH} = "/Behälter:/ usr / bin"; # Minimaler PFAD.
# Ziehen Sie in Erwägung, die Umwelt noch stärker zu desinfizieren.
exec 'myprog', 'arg1', 'arg2'
or die "kann myprog nicht ausführen: $!";
}

Eine ähnliche Strategie würde für die Wildcard-Erweiterung über "glob" funktionieren, obwohl Sie verwenden können
"readdir" stattdessen.

Taint Checking ist am nützlichsten, wenn Sie sich selbst vertrauen, kein a . geschrieben zu haben
Programm zum Verschenken der Farm, du vertraust nicht unbedingt denen, die sie am Ende nutzen, nicht
zu versuchen, es dazu zu bringen, etwas Schlechtes zu tun. Das ist die Art von Sicherheitsüberprüfung
nützlich für Set-ID-Programme und Programme, die im Namen einer anderen Person gestartet wurden, wie CGI
Programme.

Dies ist jedoch etwas ganz anderes, als dem Autor des Codes nicht einmal zu vertrauen, dass er es nicht versucht
etwas Böses tun. So viel Vertrauen braucht es, wenn dir jemand ein Programm überreicht
Sie haben es noch nie gesehen und sagt: "Hier, führen Sie das aus." Für diese Art von Sicherheit könnten Sie
das Safe-Modul ausprobieren möchten, das standardmäßig in der Perl-Distribution enthalten ist. Dies
Modul ermöglicht es dem Programmierer, spezielle Fächer einzurichten, in denen alle Systemoperationen
sind gefangen und der Namespace-Zugriff wird sorgfältig kontrolliert. Sicher sollte nicht in Betracht gezogen werden
aber kugelsicher: es wird den fremden Code nicht daran hindern, Endlosschleifen aufzubauen,
Gigabyte Speicher zuweisen oder sogar Perl-Bugs missbrauchen, um den Host-Interpreter zum Absturz zu bringen
oder sich unvorhersehbar verhalten. Auf jeden Fall ist es besser, vollständig zu vermeiden, wenn Sie es sind
wirklich besorgt um die Sicherheit.

Sicherheit Fehler
Abgesehen von den offensichtlichen Problemen, die sich daraus ergeben, dass Systemen besondere Privilegien gewährt werden,
flexibel wie Skripte, auf vielen Unix-Versionen sind Set-ID-Skripte von Natur aus unsicher
von Anfang an. Das Problem ist eine Racebedingung im Kernel. Zwischen der Zeit
der Kernel öffnet die Datei, um zu sehen, welcher Interpreter ausgeführt werden soll und wann die (now-set-id)
Interpreter dreht sich um und öffnet die Datei erneut, um sie zu interpretieren, die fragliche Datei kann
geändert haben, insbesondere wenn Sie symbolische Links auf Ihrem System haben.

Glücklicherweise kann dieses Kernel-"Feature" manchmal deaktiviert werden. Leider gibt es
zwei Möglichkeiten, es zu deaktivieren. Das System kann Skripte mit jedem gesetzten ID-Bit einfach verbieten,
was nicht viel hilft. Alternativ kann es die Set-ID-Bits in Skripten einfach ignorieren.

Wenn die Kernel-Set-ID-Skriptfunktion jedoch nicht deaktiviert ist, wird sich Perl laut beschweren
dass Ihr Set-ID-Skript unsicher ist. Sie müssen entweder die Kernel-Set-ID deaktivieren
Skriptfunktion, oder fügen Sie einen C-Wrapper um das Skript. AC-Wrapper ist nur ein kompilierter
Programm, das nichts anderes tut, als Ihr Perl-Programm aufzurufen. Kompilierte Programme sind nicht
unterliegt dem Kernel-Bug, der set-id-Skripte heimsucht. Hier ist ein einfacher Wrapper, geschrieben
in C:

#define REAL_PATH "/Pfad/zu/Skript"
Haupt(ac, av)
Zeichen **av;
{
execv (REAL_PATH, av);
}

Kompilieren Sie diesen Wrapper in eine ausführbare Binärdatei und machen Sie dann it anstatt dein Skript
setuid oder setgid.

In den letzten Jahren haben Anbieter damit begonnen, Systeme bereitzustellen, die frei von diesem inhärenten Sicherheitsfehler sind.
Wenn der Kernel auf solchen Systemen den Namen des set-id-Skripts zum Öffnen an die
Interpreter, anstatt einen Pfadnamen zu verwenden, der der Einmischung unterliegt, geht er stattdessen durch
/dev/fd/3. Dies ist eine spezielle Datei, die bereits im Skript geöffnet ist, sodass keine
Race Condition für die Ausnutzung böser Skripte. Auf diesen Systemen sollte Perl kompiliert werden
mit "-DSETUID_SCRIPTS_ARE_SECURE_NOW". Die Einrichtung Programm, das Perl erstellt, versucht,
finden Sie dies selbst heraus, Sie sollten dies also nie selbst angeben müssen. Die meisten
Moderne Versionen von SysVr4 und BSD 4.4 verwenden diesen Ansatz, um das Kernel-Rennen zu vermeiden
Zustand.

Schützen Ihr Programme
Es gibt eine Reihe von Möglichkeiten, den Quellcode für Ihre Perl-Programme zu verbergen, mit unterschiedlichen Ebenen
von "Sicherheit".

Zuallererst aber du kann nicht Leseberechtigung wegnehmen, weil der Quellcode muss
lesbar sein, um kompiliert und interpretiert zu werden. (Das bedeutet nicht, dass ein CGI
Die Quelle des Skripts ist jedoch für Leute im Web lesbar.) Sie müssen also die
Berechtigungen auf dem sozialfreundlichen 0755-Niveau. Dadurch können Benutzer auf Ihrem lokalen System
sehe nur deine Quelle.

Manche Leute betrachten dies fälschlicherweise als Sicherheitsproblem. Wenn Ihr Programm unsicher ist
Dinge und verlässt sich darauf, dass die Leute nicht wissen, wie sie diese Unsicherheiten ausnutzen können, ist es nicht
sicher. Oftmals ist es jemandem möglich, die unsicheren Dinge festzustellen und auszunutzen
sie, ohne die Quelle anzuzeigen. Sicherheit durch Dunkelheit, der Name für das Verstecken Ihres
Fehler zu beheben, anstatt sie zu beheben, ist in der Tat wenig Sicherheit.

Sie können versuchen, die Verschlüsselung über Quellfilter zu verwenden (Filter::* von CPAN, oder
Filter::Util::Call und Filter::Simple seit Perl 5.8). Aber Cracker können es vielleicht
es entschlüsseln. Sie können versuchen, den unten beschriebenen Bytecode-Compiler und -Interpreter zu verwenden, aber
Cracker könnten es dekompilieren. Sie können versuchen, den nativen Code-Compiler zu verwenden
unten beschrieben, aber Cracker können es möglicherweise zerlegen. Diese posieren unterschiedlich stark
für Leute schwierig, die an Ihren Code gelangen möchten, aber niemand kann ihn endgültig verbergen
(Dies gilt für jede Sprache, nicht nur für Perl).

Wenn Sie sich Sorgen machen, dass die Leute von Ihrem Code profitieren, dann ist das Fazit:
nichts als eine restriktive Lizenz gibt Ihnen Rechtssicherheit. Lizenzieren Sie Ihre Software und
würzen Sie es mit drohenden Aussagen wie "Dies ist unveröffentlichte proprietäre Software von
XYZ Corp. Ihr Zugriff darauf gibt Ihnen nicht die Erlaubnis, es zu verwenden bla bla bla."
sollten Sie einen Anwalt aufsuchen, um sicherzustellen, dass der Wortlaut Ihrer Lizenz vor Gericht Bestand hat.

Unicode
Unicode ist eine neue und komplexe Technologie und man kann gewisse Sicherheiten leicht übersehen
Tücken. Siehe perluniintro für eine Übersicht und perlunicode für Details und "Sicherheit"
Implikationen von Unicode" in perlunicode insbesondere für Sicherheitsimplikationen.

Algorithmisch Komplexität Anschläge
Bestimmte interne Algorithmen, die bei der Implementierung von Perl verwendet werden, können angegriffen werden, indem Sie
die Eingabe sorgfältig, um entweder viel Zeit oder Platz oder beides zu verbrauchen. Das kann
führen in die sogenannte Verleugnung of Service (DoS)-Attacken.

· Hash-Algorithmus - Hash-Algorithmen, wie sie in Perl verwendet werden, sind bekannt als
anfällig für Kollisionsangriffe auf ihre Hash-Funktion. Solche Angriffe beinhalten
Konstruieren eines Satzes von Schlüsseln, die in denselben Eimer kollidieren, was ineffiziente
Verhalten. Solche Angriffe hängen oft davon ab, den Seed der verwendeten Hash-Funktion zu entdecken
um die Schlüssel den Eimern zuzuordnen. Dieser Samen wird dann verwendet, um einen Schlüsselsatz brutal zu erzwingen, der
verwendet werden, um einen Denial-of-Service-Angriff zu starten. In Perl 5.8.1 wurden Änderungen eingeführt an
härten Sie Perl gegen solche Angriffe ab, und später in Perl 5.18.0 waren diese Funktionen
verbessert und zusätzliche Schutzfunktionen hinzugefügt.

Zum Zeitpunkt der Erstellung dieses Artikels gilt Perl 5.18.0 als gut gehärtet gegen
Angriffe mit algorithmischer Komplexität auf seine Hash-Implementierung. Dies ist vor allem zu verdanken
Die folgenden Maßnahmen schwächen Angriffe ab:

Hash-Seed-Randomisierung
Um es unmöglich zu machen, zu wissen, welcher Seed ein Angriffsschlüsselsatz generieren soll
denn dieser Seed wird beim Prozessstart zufällig initialisiert. Dies kann überschrieben werden
unter Verwendung der Umgebungsvariablen PERL_HASH_SEED, siehe "PERL_HASH_SEED" in perlrun.
Diese Umgebungsvariable steuert, wie Elemente tatsächlich gespeichert werden, nicht wie sie sind
dargestellt über "Schlüssel", "Werte" und "jeweils".

Hash-Traversal-Randomisierung
Unabhängig davon, welcher Seed in der Hash-Funktion verwendet wird, "Schlüssel", "Werte" und
"each" gibt Elemente in einer zufälligen Reihenfolge pro Hash zurück. Ändern eines Hashs durch Einfügen
ändert die Iterationsreihenfolge dieses Hashs. Dieses Verhalten kann überschrieben werden durch
mit "hash_traversal_mask()" von Hash::Util oder mit den PERL_PERTURB_KEYS
Umgebungsvariable, siehe "PERL_PERTURB_KEYS" in perlrun. Beachten Sie, dass diese Funktion
steuert die "sichtbare" Reihenfolge der Schlüssel und nicht die tatsächliche Reihenfolge, in der sie gespeichert werden
in.

Bucket-Order-Störung
Wenn Artikel in einem bestimmten Hash-Bucket kollidieren, werden sie in der Reihenfolge in der Kette gespeichert
ist in Perl 5.18 nicht mehr vorhersehbar. Dies hat die Absicht, es schwieriger zu machen
eine Kollision zu beobachten. Dieses Verhalten kann überschrieben werden, indem Sie die
Umgebungsvariable PERL_PERTURB_KEYS, siehe "PERL_PERTURB_KEYS" in perlrun.

Neue Standard-Hash-Funktion
Die Standard-Hash-Funktion wurde mit der Absicht modifiziert, es schwieriger zu machen
um den Hash-Samen abzuleiten.

Alternative Hash-Funktionen
Der Quellcode enthält mehrere Hash-Algorithmen zur Auswahl. Während wir
glauben, dass der Standard-Perl-Hash robust gegen Angriffe ist, haben wir den Hash aufgenommen
Siphash als Fallback-Option nutzen. Zum Zeitpunkt der Veröffentlichung von Perl 5.18.0
Es wird angenommen, dass Siphash von kryptografischer Stärke ist. Dies ist nicht die Standardeinstellung, da
es ist viel langsamer als der Standard-Hash.

Ohne ein spezielles Perl zu kompilieren, gibt es keine Möglichkeit, genau das gleiche Verhalten von . zu erreichen
alle Versionen vor Perl 5.18.0. Am nächsten kommt man durch die Einstellung
PERL_PERTURB_KEYS auf 0 und Setzen von PERL_HASH_SEED auf einen bekannten Wert. Wir nicht
Empfehlen Sie diese Einstellungen aufgrund der oben genannten Sicherheitsüberlegungen für die Verwendung in der Produktion.

Perl hat niemals garantiert für Bestellung of die Hash- Tasten, und die bestellung hat schon
während der Lebensdauer von Perl 5 mehrmals geändert. Auch die Reihenfolge der Hash-Schlüssel
war und ist immer noch vom Anzeigenauftrag und der Historie betroffen
der Änderungen, die am Hash während seiner Lebensdauer vorgenommen wurden.

Beachten Sie auch, dass die Reihenfolge der Hash-Elemente zwar zufällig sein kann, diese "Pseudo-
bestellen" sollte nicht für Anwendungen wie das zufällige Mischen einer Liste verwendet werden (verwenden Sie
"List::Util::shuffle()", siehe List::Util, ein Standard-Kernmodul seit Perl
5.8.0; oder das CPAN-Modul "Algorithm::Numerical::Shuffle"), oder zum Generieren
Permutationen (verwenden Sie zB die CPAN-Module "Algorithm::Permute" oder
"Algorithm::FastPermute") oder für alle kryptografischen Anwendungen.

Gebundene Hashes können ihre eigenen Angriffe auf Reihenfolge und algorithmische Komplexität haben.

· Reguläre Ausdrücke - Perls Engine für reguläre Ausdrücke heißt NFA (Non-
deterministischer endlicher Automat), was unter anderem bedeutet, dass er eher
verbrauchen leicht viel Zeit und Platz, wenn der reguläre Ausdruck möglicherweise
gleich in mehrfacher Hinsicht. Sorgfältiges Erstellen der regulären Ausdrücke kann helfen, aber durchaus
oft kann man nicht viel machen (das Buch "Reguläre Ausdrücke beherrschen" ist
Pflichtlektüre, siehe perlfaq2). Der Platzmangel manifestiert sich durch Perl
der Speicher ausgeht.

· Sortierung - der Quicksort-Algorithmus, der in Perls vor 5.8.0 verwendet wurde, um die Sortieren()
-Funktion lässt sich sehr leicht zu Fehlverhalten austricksen, so dass sie viel Zeit in Anspruch nimmt.
Ab Perl 5.8.0 wird standardmäßig ein anderer Sortieralgorithmus, mergesort, verwendet.
Mergesort kann sich bei keiner Eingabe falsch verhalten.

Sehenhttp://www.cs.rice.edu/~scrosby/hash/> für weitere Informationen und jegliche Informatik
Lehrbuch zur algorithmischen Komplexität.

Verwenden Sie perlsec online mit den onworks.net-Diensten