perlsec - En ligne dans le Cloud

PROGRAMME:

Nom

perlsec - Sécurité Perl

DESCRIPTION

Perl est conçu pour faciliter la programmation en toute sécurité, même lors de l'exécution avec des
privilèges, comme les programmes setuid ou setgid. Contrairement à la plupart des shells de ligne de commande, qui sont
basé sur plusieurs passes de substitution sur chaque ligne du script, Perl utilise une méthode plus
schéma d'évaluation conventionnel avec moins d'accrocs cachés. De plus, parce que le
le langage a plus de fonctionnalités intégrées, il peut moins dépendre de l'extérieur (et peut-être
indignes de confiance) pour accomplir ses objectifs.

SÛRETÉ gestion des vulnérabilités CONTACT INFORMATION

Si vous pensez avoir trouvé une faille de sécurité dans Perl, veuillez envoyer un e-mail
[email protected] avec des détails. Cela indique un abonnement fermé,
liste de diffusion non archivée. Veuillez n'utiliser cette adresse que pour des problèmes de sécurité dans Perl
core, pas pour les modules distribués indépendamment sur CPAN.

SÛRETÉ MÉCANISMES ET Préoccupations

Entacher mode
Perl active automatiquement un ensemble de contrôles de sécurité spéciaux, appelés entacher mode, quand cela
détecte son programme en cours d'exécution avec différents ID d'utilisateur ou de groupe réels et effectifs. le
setuid bit dans les autorisations Unix est le mode 04000, le setgid bit mode 02000 ; L'un ou l'autre ou les deux
peut être réglé. Vous pouvez également activer explicitement le mode de rejet en utilisant le -T indicateur de ligne de commande.
Ce drapeau est fortement suggéré pour les programmes serveur et tout programme exécuté au nom de
quelqu'un d'autre, comme un script CGI. Une fois que le mode de contamination est activé, il est activé pour le reste de
votre scénario.

Dans ce mode, Perl prend des précautions spéciales appelées entacher chèques pour empêcher les deux
pièges évidents et subtils. Certaines de ces vérifications sont raisonnablement simples, comme la vérification
que les répertoires de chemin ne sont pas accessibles en écriture par d'autres ; les programmeurs prudents ont toujours utilisé
des chèques comme ceux-ci. D'autres vérifications, cependant, sont mieux supportées par la langue elle-même, et
ce sont ces vérifications en particulier qui contribuent à rendre un programme Perl set-id plus sécurisé
que le programme C correspondant.

Vous ne pouvez pas utiliser des données provenant de l'extérieur de votre programme pour affecter autre chose à l'extérieur
votre programme - du moins, pas par accident. Tous les arguments de ligne de commande, environnement
variables, informations locales (voir perllocale), résultats de certains appels système
("readdir()", "readlink()", la variable de "shmread()", les messages renvoyés par
"msgrcv()", les champs mot de passe, gcos et shell renvoyés par les appels "getpwxxx()"), et
toutes les entrées de fichiers sont marquées comme « entachées ». Les données corrompues ne peuvent pas être utilisées directement ou
indirectement dans toute commande qui invoque un sous-shell, ni dans aucune commande qui modifie
fichiers, répertoires ou processus, avec le Abonnement exceptions:

· Les arguments pour "print" et "syswrite" sont pas vérifié pour la souillure.

· Méthodes symboliques

$obj->$method(@args);

et sous-références symboliques

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

ne sont pas vérifiés pour la souillure. Cela nécessite une prudence supplémentaire à moins que vous ne vouliez
données externes pour affecter votre flux de contrôle. À moins que vous ne limitiez soigneusement ce que ces
les valeurs symboliques sont, les gens sont capables d'appeler des fonctions au contrôle votre code Perl, tel que
POSIX::system, auquel cas ils sont capables d'exécuter du code externe arbitraire.

· Les clés de hachage sont jamais entaché.

Pour des raisons d'efficacité, Perl adopte une vision prudente quant à savoir si les données sont corrompues. Si un
expression contient des données corrompues, toute sous-expression peut être considérée comme corrompue, même si la
La valeur de la sous-expression n'est pas elle-même affectée par les données entachées.

Étant donné que l'altération est associée à chaque valeur scalaire, certains éléments d'un tableau ou
le haschich peut être contaminé et d'autres non. Les clés d'un hachage sont jamais entaché.

Par exemple :

$arg = décalage ; # $arg est corrompu
$caché = $arg . 'bar'; # $hid est également corrompu
$ligne = <> ; # Entaché
$ligne = ; # Également entaché
ouvrez FOO, "/home/me/bar" ou die $!;
$ligne = ; # Toujours entaché
$chemin = $ENV{'CHEMIN'} ; # Entaché, mais voir ci-dessous
$données = 'abc'; # Non contaminé

système "écho $arg" ; # Peu sûr
système "/bin/écho", $arg; # Considéré comme non sécurisé
# (Perl ne connaît pas /bin/écho)
système "écho $hid" ; # Peu sûr
système "echo $data" ; # Non sécurisé jusqu'à ce que PATH soit défini

$chemin = $ENV{'CHEMIN'} ; # $path maintenant corrompu

$ENV{'CHEMIN'} = '/ bin:/ usr / bin';
supprimer @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'} ;

$chemin = $ENV{'CHEMIN'} ; # $path maintenant NON corrompu
système "echo $data" ; # Est sécurisé maintenant !

open(FOO, "< $arg"); # OK - fichier en lecture seule
open(FOO, "> $arg"); # Pas OK - essayer d'écrire

open(FOO,"écho $arg|"); # Pas d'accord
ouvrir(FOO,"-|")
ou exec 'echo', $arg; # Pas d'accord non plus

$crier = `écho $arg`; # Insécurisé, $crier maintenant entaché

dissocier $data, $arg ; # Peu sûr
umask $arg; # Peu sûr

exec "écho $arg" ; # Peu sûr
exec "écho", $arg; # Peu sûr
exec "sh", '-c', $arg; # Très peu sûr !

@fichiers = <*.c> ; # non sécurisé (utilise readdir() ou similaire)
@files = glob('*.c'); # non sécurisé (utilise readdir() ou similaire)

# Dans les deux cas, les résultats de glob sont entachés, car la liste des
# les noms de fichiers proviennent de l'extérieur du programme.

$mauvais = ($arg, 23); # $bad sera corrompu
$arg, « vrai » ; # Insécurisé (même si ce n'est pas vraiment le cas)

Si vous essayez de faire quelque chose qui n'est pas sûr, vous obtiendrez une erreur fatale disant quelque chose comme
"Dépendance non sécurisée" ou "$ENV{PATH} non sécurisé".

L'exception au principe « une valeur entachée entache toute l'expression » est avec
l'opérateur conditionnel ternaire "?:". Puisque le code avec un conditionnel ternaire

$résultat = $valeur_contaminée ? "Untainted" : "Aussi untainted" ;

est effectivement

si ( $valeur_contaminée ) {
$result = "Untainted" ;
} Else {
$result = "Aussi non contaminé" ;
}

cela n'a pas de sens que $result soit entaché.

Blanchiment et de Détecter Entaché Date
Pour tester si une variable contient des données entachées, et dont l'utilisation déclencherait ainsi une
Message "Dépendance non sécurisée", vous pouvez utiliser la fonction "taillée()" du Scalar::Util
module, disponible dans votre miroir CPAN à proximité, et inclus dans Perl à partir du
version 5.8.0. Ou vous pourrez peut-être utiliser la fonction "is_tainted()" suivante.

le sous-est_souillé {
$@ local ; # Ne polluez pas la valeur de l'appelant.
retourner ! eval { eval("#" . substr(join("", @_), 0, 0)); 1 };
}

Cette fonction utilise le fait que la présence de données corrompues n'importe où dans un
expression rend l'expression entière entachée. Ce serait inefficace pour chaque
opérateur pour tester chaque argument pour la souillure. Au lieu de cela, le légèrement plus efficace et
approche conservatrice est utilisée que si une valeur corrompue a été consultée dans le même
expression, toute l'expression est considérée comme entachée.

Mais tester la souillure ne vous mène pas loin. Parfois, vous n'avez qu'à vider votre
l'altération des données. Les valeurs peuvent être intactes en les utilisant comme clés dans un hachage ; autrement
le seul moyen de contourner le mécanisme d'altération est de référencer des sous-modèles à partir d'un
correspondance d'expressions. Perl suppose que si vous référencez une sous-chaîne en utilisant $1, $2, etc. dans un
modèle non altérant, que vous saviez ce que vous faisiez lorsque vous avez écrit ce modèle. Cette
signifie utiliser un peu de réflexion - ne vous contentez pas de nettoyer aveuglément quoi que ce soit, ou vous vaincrez le
tout le mécanisme. Il vaut mieux vérifier que la variable n'a que de bons caractères (par
certaines valeurs de "bon") plutôt que de vérifier s'il a des mauvais caractères. C'est
parce qu'il est beaucoup trop facile de rater de mauvais personnages auxquels vous n'avez jamais pensé.

Voici un test pour s'assurer que les données ne contiennent que des caractères "mot"
(alphabétiques, chiffres et traits de soulignement), un trait d'union, un arobase ou un point.

si ($données =~ /^([-\@\w.]+)$/) {
$données = 1 $ ; # $data maintenant intact
} Else {
die "Données incorrectes dans '$data'" ; # enregistre ceci quelque part
}

C'est assez sûr car "/\w+/" ne correspond normalement pas aux métacaractères du shell, ni
point, tiret ou à va signifier quelque chose de spécial pour la coque. Utilisation de "/.+/" aurait
n'était pas sûr en théorie car il laisse tout passer, mais Perl ne vérifie pas
cette. La leçon est que lors de la décontamination, vous devez être extrêmement prudent avec votre
motifs. Le blanchiment des données à l'aide d'expressions régulières est le uniquement mécanisme de décontamination
données sales, à moins que vous n'utilisiez la stratégie détaillée ci-dessous pour créer un enfant de moindre
privilège.

L'exemple n'efface pas $data si "use locale" est en vigueur, car les caractères
correspondant à "\w" sont déterminés par les paramètres régionaux. Perl considère que les définitions de locales sont
indignes de confiance car ils contiennent des données extérieures au programme. Si vous écrivez un
programme prenant en compte les paramètres régionaux et que vous souhaitez blanchir des données avec une expression régulière contenant "\w",
mettre "pas de locale" avant l'expression dans le même bloc. Voir "SÉCURITÉ" dans perllocale
pour une discussion plus approfondie et des exemples.

Interrupteurs On le "# !" Line
Lorsque vous rendez un script exécutable, afin de le rendre utilisable comme commande, le système
passera les commutateurs à perl à partir du # ! ligne. Perl vérifie que toute ligne de commande
les commutateurs donnés à un script setuid (ou setgid) correspondent en fait à ceux définis sur le #! ligne.
Certains environnements Unix et de type Unix imposent une limite d'un commutateur sur le # ! ligne, vous pouvez donc
besoin d'utiliser quelque chose comme "-wU" au lieu de "-w -U" sous de tels systèmes. (Ce problème
ne devrait apparaître que dans les environnements Unix ou de type Unix qui prennent en charge #! et setuid ou setgid
scénarios.)

Entacher mode et de @INC
Lorsque le mode de contamination ("-T") est activé, le "." est supprimé de @INC, et le
les variables d'environnement "PERL5LIB" et "PERLLIB" sont ignorées par Perl. Vous pouvez toujours régler
@INC depuis l'extérieur du programme en utilisant l'option de ligne de commande "-I" comme expliqué dans
perlrun. Les deux variables d'environnement sont ignorées car elles sont masquées, et un utilisateur
l'exécution d'un programme peut ignorer qu'ils sont définis, alors que l'option "-I" est clairement
visible et donc autorisée.

Une autre façon de modifier @INC sans modifier le programme, est d'utiliser le pragma "lib",
par exemple:

programme perl -Mlib=/foo

L'avantage d'utiliser "-Mlib=/foo" sur "-I/foo", est que le premier sera automatiquement
supprimez tous les répertoires dupliqués, alors que ce dernier ne le fera pas.

Notez que si une chaîne corrompue est ajoutée à @INC, le problème suivant sera signalé :

Dépendance non sécurisée dans require lors de l'exécution avec le commutateur -T

Nettoyage Up Votre Chemin
Pour les messages "Insecure $ENV{PATH}", vous devez définir $ENV{'PATH'} sur une valeur connue, et
chaque répertoire du chemin doit être absolu et non accessible en écriture par d'autres que son propriétaire et
grouper. Vous pourriez être surpris de recevoir ce message même si le chemin d'accès à votre exécutable
est pleinement qualifié. C'est pas généré parce que vous n'avez pas fourni un chemin complet vers le
programme; à la place, il est généré parce que vous ne définissez jamais votre variable d'environnement PATH, ou
vous ne l'avez pas défini sur quelque chose de sûr. Parce que Perl ne peut pas garantir que le
l'exécutable en question ne va pas lui-même se retourner et exécuter un autre programme
qui dépend de votre PATH, il s'assure que vous définissez le PATH.

Le PATH n'est pas la seule variable d'environnement qui peut causer des problèmes. Parce que certains
les shells peuvent utiliser les variables IFS, CDPATH, ENV et BASH_ENV, Perl vérifie qu'elles sont
soit vide ou intact lors du démarrage des sous-processus. Vous pouvez ajouter quelque chose comme
ceci à vos scripts setid et de vérification de souillure.

supprimer @ENV{qw(IFS CDPATH ENV BASH_ENV)} ; # Rendre %ENV plus sûr

Il est également possible d'avoir des ennuis avec d'autres opérations qui ne se soucient pas de savoir si elles
utiliser des valeurs corrompues. Utiliser judicieusement les tests de fichiers pour traiter avec n'importe quel utilisateur -
noms de fichiers fournis. Lorsque cela est possible, faites des ouvertures et telles après en laissant tomber correctement tout spécial
privilèges d'utilisateur (ou de groupe !). Perl ne vous empêche pas d'ouvrir des noms de fichiers corrompus pour
lecture, alors faites attention à ce que vous imprimez. Le mécanisme d'altération est destiné à empêcher
erreurs stupides, pour ne pas supprimer le besoin de réfléchir.

Perl n'appelle pas le shell pour développer les caractères génériques lorsque vous passez "system" et "exec"
des listes de paramètres explicites au lieu de chaînes contenant des caractères génériques de shell possibles.
Malheureusement, les fonctions "open", "glob" et backtick ne fournissent pas une telle alternative
convention d'appel, donc plus de subterfuge sera nécessaire.

Perl fournit un moyen raisonnablement sûr d'ouvrir un fichier ou un tube à partir d'un setuid ou d'un setgid
programme : créez simplement un processus enfant avec des privilèges réduits qui fait le sale boulot pour
vous. Tout d'abord, forkez un enfant en utilisant la syntaxe "open" spéciale qui relie le parent et
enfant par un tuyau. Maintenant, l'enfant réinitialise son jeu d'ID et tout autre attribut par processus,
comme les variables d'environnement, les umasks, les répertoires de travail actuels, le retour aux originaux ou
valeurs sûres connues. Ensuite, le processus fils, qui n'a plus de permissions spéciales,
fait le « open » ou un autre appel système. Enfin, l'enfant transmet les données qu'il a réussi à
l'accès revient au parent. Parce que le fichier ou le tube a été ouvert dans l'enfant lors de l'exécution
sous moins de privilèges que le parent, il n'est pas susceptible d'être amené à faire quelque chose qu'il
ne devrait pas.

Voici un moyen de faire des backticks de manière raisonnablement sûre. Remarquez comment le "exec" n'est pas appelé avec
une chaîne que la coquille pourrait étendre. C'est de loin la meilleure façon d'appeler quelque chose qui
peuvent être soumis à des échappements de shell : n'appelez simplement jamais le shell.

utiliser l'anglais;
die "Impossible de bifurquer : $ !" sauf si défini($pid = open(KID, "-|"));
si ($pid) { # parent
tandis que ( ) {
# faire quelque chose
}
fermer KID ;
} Else {
mon @temp = ($EUID, $EGID);
mon $orig_uid = $UID;
mon $orig_gid = $GID ;
$EUID = $UID ;
$EGID = $GID ;
# Supprimer les privilèges
$UID = $orig_uid ;
$GID = $orig_gid ;
# Assurez-vous que les privilèges ont vraiment disparu
($EUID, $EGID) = @temp ;
die "Impossible de supprimer les privilèges"
sauf si $UID == $EUID && $GID eq $EGID;
$ENV{CHEMIN} = "/ bin:/ usr / bin"; # CHEMIN minimal.
# Pensez à assainir encore plus l'environnement.
exec 'myprog', 'arg1', 'arg2'
ou die "can't exec myprog: $!";
}

Une stratégie similaire fonctionnerait pour l'expansion des caractères génériques via "glob", bien que vous puissiez utiliser
"readdir" à la place.

La vérification des altérations est particulièrement utile lorsque, même si vous vous faites confiance pour ne pas avoir écrit de
programme pour donner la ferme, vous ne faites pas nécessairement confiance à ceux qui finissent par l'utiliser pas
pour essayer de l'amener à faire quelque chose de mal. C'est le genre de contrôle de sécurité qui est
utile pour les programmes set-id et les programmes lancés au nom de quelqu'un d'autre, comme CGI
programmes.

C'est assez différent, cependant, de ne même pas faire confiance à l'auteur du code pour ne pas essayer
faire quelque chose de mal. C'est le genre de confiance nécessaire quand quelqu'un vous remet un programme
vous n'avez jamais vu auparavant et dit: "Tiens, lance ça." Pour ce genre de sécurité, vous pourriez
voulez découvrir le module Safe, inclus en standard dans la distribution Perl. Cette
module permet au programmeur de mettre en place des compartiments spéciaux dans lesquels toutes les opérations du système
sont piégés et l'accès à l'espace de noms est soigneusement contrôlé. La sécurité ne doit pas être considérée
à l'épreuve des balles, cependant : cela n'empêchera pas le code étranger de mettre en place des boucles infinies,
allouer des gigaoctets de mémoire, ou même abuser des bogues perl pour faire planter l'interpréteur hôte
ou se comporter de manière imprévisible. Dans tous les cas, il vaut mieux éviter complètement si vous êtes
vraiment soucieux de la sécurité.

Sécurité Bugs
Au-delà des problèmes évidents qui découlent de l'octroi de privilèges spéciaux aux systèmes
flexibles en tant que scripts, sur de nombreuses versions d'Unix, les scripts set-id sont intrinsèquement non sécurisés
depuis le début. Le problème est une condition de concurrence dans le noyau. Entre le temps
le noyau ouvre le fichier pour voir quel interpréteur exécuter et quand le (now-set-id)
l'interprète se retourne et rouvre le fichier pour l'interpréter, le fichier en question peut
ont changé, surtout si vous avez des liens symboliques sur votre système.

Heureusement, cette "fonctionnalité" du noyau peut parfois être désactivée. Malheureusement, il y a
deux façons de le désactiver. Le système peut simplement interdire les scripts avec n'importe quel bit set-id défini,
ce qui n'aide pas beaucoup. Alternativement, il peut simplement ignorer les bits set-id sur les scripts.

Cependant, si la fonction de script set-id du noyau n'est pas désactivée, Perl se plaindra bruyamment
que votre script set-id n'est pas sécurisé. Vous devrez soit désactiver le noyau set-id
fonction de script, ou mettez un wrapper C autour du script. Le wrapper AC est juste un compilé
programme qui ne fait rien d'autre que d'appeler votre programme Perl. Les programmes compilés ne sont pas
sujet au bogue du noyau qui affecte les scripts set-id. Voici une enveloppe simple, écrite
en C:

#define REAL_PATH "/chemin/vers/script"
principal(ac, av)
char **moyenne;
{
execv(REAL_PATH, av);
}

Compilez ce wrapper dans un exécutable binaire, puis faites it plutôt que votre script
setuid ou setgid.

Ces dernières années, les fournisseurs ont commencé à fournir des systèmes exempts de ce bogue de sécurité inhérent.
Sur de tels systèmes, lorsque le noyau passe le nom du script set-id à ouvrir au
interpréteur, plutôt que d'utiliser un nom de chemin sujet à ingérence, il passe à la place
/dev/fd/3. Il s'agit d'un fichier spécial déjà ouvert sur le script, de sorte qu'il ne peut y avoir aucun
condition de course pour les scripts maléfiques à exploiter. Sur ces systèmes, Perl doit être compilé
avec "-DSETUID_SCRIPTS_ARE_SECURE_NOW". le Configurez programme qui construit Perl essaie de
comprendre cela par vous-même, vous ne devriez donc jamais avoir à le spécifier vous-même. Plus
les versions modernes de SysVr4 et BSD 4.4 utilisent cette approche pour éviter la course au noyau
état.

Protéger Votre Programmes
Il existe plusieurs manières de cacher la source à vos programmes Perl, avec différents niveaux
de "sécurité".

Mais avant tout, vous ne peut pas retirer l'autorisation de lecture, car le code source doit
être lisible afin d'être compilé et interprété. (Cela ne veut pas dire qu'un CGI
la source du script est lisible par les internautes, cependant.) Vous devez donc laisser le
autorisations au niveau 0755 socialement convivial. Cela permet aux utilisateurs de votre système local
voir seulement votre source.

Certaines personnes considèrent à tort cela comme un problème de sécurité. Si votre programme n'est pas sécurisé
choses, et s'appuie sur des gens qui ne savent pas comment exploiter ces insécurités, ce n'est pas
sécurise. Il est souvent possible pour quelqu'un de déterminer les choses non sécurisées et d'exploiter
eux sans voir la source. La sécurité par l'obscurité, le nom pour cacher votre
bogues au lieu de les corriger, c'est en effet peu de sécurité.

Vous pouvez essayer d'utiliser le cryptage via des filtres source (Filter ::* à partir du CPAN, ou
Filter::Util::Call and Filter::Simple depuis Perl 5.8). Mais les craquelins pourraient être en mesure de
le décrypter. Vous pouvez essayer d'utiliser le compilateur et l'interpréteur de byte code décrits ci-dessous, mais
les crackers pourraient être capables de le décompiler. Vous pouvez essayer d'utiliser le compilateur de code natif
décrit ci-dessous, mais les crackers pourraient être en mesure de le démonter. Ceux-ci posent des degrés divers
de difficulté pour les personnes voulant accéder à votre code, mais personne ne peut le cacher définitivement
(c'est vrai pour tous les langages, pas seulement pour Perl).

Si vous craignez que les gens profitent de votre code, alors l'essentiel est que
rien qu'une licence restrictive vous apportera une sécurité juridique. Licence de votre logiciel et
saupoudrez-le de déclarations menaçantes comme « Ceci est un logiciel propriétaire non publié de
XYZ Corp. Votre accès à celui-ci ne vous donne pas la permission de l'utiliser blah blah blah." Vous
devriez consulter un avocat pour être sûr que le libellé de votre permis sera valable devant les tribunaux.

Unicode
Unicode est une technologie nouvelle et complexe et on peut facilement négliger certaines sécurités
pièges. Voir perluniintro pour un aperçu et perlunicode pour plus de détails, et "Sécurité
Implications of Unicode" dans perlunicode pour les implications de sécurité en particulier.

Algorithmique Complexité Attaques
Certains algorithmes internes utilisés dans l'implémentation de Perl peuvent être attaqués en choisissant
l'entrée soigneusement pour consommer de grandes quantités de temps ou d'espace ou les deux. Cela peut
conduire dans ce qu'on appelle Denial of Services (DoS) attaques.

· Algorithme de hachage - Les algorithmes de hachage comme celui utilisé dans Perl sont bien connus pour être
vulnérables aux attaques par collision sur leur fonction de hachage. De telles attaques impliquent
construire un jeu de clés qui entrent en collision dans le même seau produisant un
comportement. De telles attaques dépendent souvent de la découverte de la graine de la fonction de hachage utilisée
pour mapper les clés aux buckets. Cette graine est ensuite utilisée pour forcer brutalement un jeu de clés qui peut
être utilisé pour monter une attaque par déni de service. Dans Perl 5.8.1, des changements ont été introduits pour
durcir Perl à de telles attaques, puis plus tard dans Perl 5.18.0, ces fonctionnalités ont été
protections améliorées et supplémentaires ajoutées.

Au moment d'écrire ces lignes, Perl 5.18.0 est considéré comme bien durci contre
attaques de complexité algorithmique sur son implémentation de hachage. Ceci est dû en grande partie à
les mesures suivantes atténuent les attaques :

Randomisation de graines de haschich
Afin de rendre impossible de savoir quelle graine générer un jeu de clés d'attaque
car, cette graine est initialisée de manière aléatoire au démarrage du processus. Cela peut être outrepassé
en utilisant la variable d'environnement PERL_HASH_SEED, voir "PERL_HASH_SEED" dans perlrun.
Cette variable d'environnement contrôle la manière dont les éléments sont réellement stockés, et non la manière dont ils le sont.
présenté via "clés", "valeurs" et "chacun".

Hash Traversal Randomisation
Indépendamment de la graine utilisée dans la fonction de hachage, les « clés », les « valeurs » et
« each » renvoie les éléments dans un ordre aléatoire par hachage. Modifier un hachage par insertion
changera l'ordre d'itération de ce hachage. Ce comportement peut être annulé par
en utilisant "hash_traversal_mask()" de Hash::Util ou en utilisant PERL_PERTURB_KEYS
variable d'environnement, voir "PERL_PERTURB_KEYS" dans perlrun. Notez que cette fonctionnalité
contrôle l'ordre « visible » des clés, et non l'ordre réel dans lequel elles sont stockées
dans.

Perturbation de l'ordre de godet
Lorsque des éléments entrent en collision dans un seau de hachage donné, l'ordre dans lequel ils sont stockés dans la chaîne
n'est plus prévisible en Perl 5.18. Cela a l'intention de rendre les choses plus difficiles
d'observer une collision. Ce comportement peut être annulé en utilisant le
Variable d'environnement PERL_PERTURB_KEYS, voir "PERL_PERTURB_KEYS" dans perlrun.

Nouvelle fonction de hachage par défaut
La fonction de hachage par défaut a été modifiée dans le but de la rendre plus difficile
pour déduire la graine de hachage.

Fonctions de hachage alternatives
Le code source comprend plusieurs algorithmes de hachage parmi lesquels choisir. Alors que nous
croire que le hachage perl par défaut est robuste aux attaques, nous avons inclus le hachage
fonction Siphash comme option de repli. Au moment de la sortie de Perl 5.18.0
On pense que Siphash a une force cryptographique. Ce n'est pas la valeur par défaut car
il est beaucoup plus lent que le hachage par défaut.

Sans compiler un Perl spécial, il n'y a aucun moyen d'obtenir exactement le même comportement de
toutes les versions antérieures à Perl 5.18.0. Le plus proche peut être obtenu en définissant
PERL_PERTURB_KEYS sur 0 et en définissant PERL_HASH_SEED sur une valeur connue. Nous ne faisons pas
conseiller ces paramètres pour une utilisation en production en raison des considérations de sécurité ci-dessus.

Perl a jamais garantie tout commande of le hachage clés, et la commande a déjà
changé plusieurs fois au cours de la vie de Perl 5. En outre, l'ordre des clés de hachage
a toujours été et continue d'être affectée par l'ordre d'insertion et l'histoire
des modifications apportées au hachage au cours de sa durée de vie.

Notez également que bien que l'ordre des éléments de hachage puisse être aléatoire, ce "pseudo-
commande" devrait pas être utilisé pour des applications telles que le brassage aléatoire d'une liste (utilisez
"List::Util::shuffle()" pour cela, voir List::Util, un module de base standard depuis Perl
5.8.0 ; ou le module CPAN "Algorithm::Numerical::Shuffle"), ou pour générer
permutations (utiliser par exemple les modules CPAN "Algorithm::Permute" ou
"Algorithm::FastPermute"), ou pour toute application cryptographique.

Les hachages liés peuvent avoir leurs propres attaques d'ordre et de complexité algorithmique.

· Expressions régulières - Le moteur d'expressions régulières de Perl est appelé NFA (Non-
automate fini déterministe), ce qui signifie entre autres qu'il peut plutôt
consomment facilement de grandes quantités de temps et d'espace si l'expression régulière peut
correspondre de plusieurs manières. L'élaboration minutieuse des expressions régulières peut aider, mais tout à fait
souvent, il n'y a vraiment pas grand-chose à faire (le livre "Mastering Regular Expressions" est
lecture obligatoire, voir perlfaq2). Le manque d'espace se manifeste par Perl
manquer de mémoire.

· Tri - l'algorithme de tri rapide utilisé dans Perls avant 5.8.0 pour implémenter le sorte()
La fonction est très facile à tromper pour qu'elle se comporte mal, de sorte qu'elle consomme beaucoup de temps.
À partir de Perl 5.8.0, un algorithme de tri différent, mergesort, est utilisé par défaut.
Mergesort ne peut pas mal se comporter sur aucune entrée.

Voirhttp://www.cs.rice.edu/~scrosby/hash/> pour plus d'informations, et toute l'informatique
manuel sur la complexité algorithmique.

Utiliser perlsec en ligne à l'aide des services onworks.net