Comment désinfecter les variables d'environnement EDITOR, etc.

Question

J'ai le code suivant, mais je pense que j'ai besoin de désinfecter les variables d'env, mais je ne sais pas exactement comment je devrais les aseptiser. Je réalise qu'il y a probablement une limite à ce que je peux les désinfecter, mais que puis-je faire?

#!/usr/bin/perl 
use 5.012; 
use warnings; 
use autodie; 
use Env qw(EDITOR VISUAL); 
use File::Temp qw(:seekable); 

my $editor = '/usr/bin/nano'; 
if ($VISUAL) { 
    $editor = $VISUAL; 
} 
elsif ($EDITOR) { 
    $editor = $EDITOR; 
} else { 
    warn 'set VISUAL and EDITOR env variables not set falling back to nano' 
    . "\n"; 
} 

my $tmpf = File::Temp->new; 

system $editor, $tmpf->filename; 

open $tmpf, '<', $tmpf->filename; 

print while (<$tmpf>); 

Answer 1

Je n'ai jamais fait quelque chose comme ça dans les scripts CGI, donc peut-être ce n'est pas du tout ce que vous cherchez; J'espère juste que ça va aider un peu. Voici une version modifiée de la sélection de caractères autorisés que j'ai utilisé, et une suggestion de code:

my $editor = '/usr/bin/nano'; 
    my $allowed = 'a-zA-Z0-9.\-_/'; 

    # this is what I did, but you will probably not want to do this... 
    #$file =~ s/[^$allowed]//go; # Remove every character thats NOT in the OK-list 

    # check that the variables contain only allowed characters 
    if ($VISUAL =~ m/^[$allowed]+$/) { 
     $editor = $VISUAL; 
    } 
    elsif ($EDITOR =~ m/^[$allowed]+$/) { 
     $editor = $EDITOR; 
    } 
    else { 
     # message 
    } 

    # The code I have given above should also leave $editor in its default 
    # state if neither $VISUAL nor $EDITOR has been set, as the condition 
    # will not be true for empty strings/undef values. 

De toute évidence, vous ne pouvez pas modifier les variables d'environnement si vous remarquez des caractères dans ceux qui vous pensez ne devrait pas être là (par exemple caractères qui ne sont pas dans la chaîne $ allowed), mais vous pouvez vérifier la présence de tels caractères et revenir sur votre éditeur par défaut dans un tel cas. Ceci est juste mon humble suggestion; peut-être un expert sur le sujet répondra dans un moment, et vous obtiendrez sa sagesse servi sur un plateau d'argent :)

Answer 2

L'utilisation de system avec plus d'un argument ne nécessite pas de désinfecter quoi que ce soit, car aucun shell sera invoqué. Vous pourriez vouloir vérifier si l'exécutable existe d'abord mais cela compliquera inutilement votre programme, et vous devrez regarder dans $PATH. En outre, les variables environnementales comme celles-ci sont généralement fiables. Toutefois, vous voudrez peut-être appeler le statut de sortie du système. Et vous pouvez essayer d'appeler $VISUAL d'abord, et si elle échoue, appeler $EDITOR (si $VISUAL est défini, $EDITOR est supposé agir comme un repli).

Answer 3

Pourquoi avez-vous besoin de les désinfecter du tout? Quel dommage va se produire si l'utilisateur de votre script a VISUAL="rm -f" et EDITOR à quelque chose d'autre bizarre? Vous vérifiez que l'opération de l'éditeur a réussi, que le fichier a été ouvert et que son contenu a du sens après la modification, avant que vous n'ayez fait quoi que ce soit de dangereux. Mais si l'utilisateur est seulement capable d'endommager ses propres fichiers (vous n'exécutez pas un système où ils peuvent endommager vos fichiers, n'est-ce pas?), Il n'est pas nécessaire de les désinfecter. Fournir un défaut est raisonnable; circonstances locales dictent si nano est un meilleur choix que, disons, vim.

Si l'utilisateur ne peut pas endommager votre matériel en abusant de VISUAL et EDITOR, alors je ne m'inquiéterais pas trop de leur choix d'endommager leurs propres choses.

Si vous écrivez quelque chose qui fonctionnera avec des privilèges augmentés - avec des privilèges SetUID ou SetGID, par exemple - alors vous devez vous en soucier beaucoup plus. (Le code Perl manque des vérifications qui sont plus fondamentales que de se préoccuper de l'éditeur.) Oh, mais cela signifie que le script annule automatiquement les erreurs, ce qui me semble être un peu radical. que cela ne gère pas system ou exec sauf si vous avez)

Answer 4

Je pense que vous devez penser légèrement différemment à ce sujet. Après tout, votre script semble avoir besoin de l'interaction de l'utilisateur. Par conséquent, il ne serait pas déraisonnable de demander à l'utilisateur quel éditeur utiliser.Vous pouvez émettre un droit rapide avant d'exécuter l'éditeur comme dans:

Which editor would you like to use [/usr/bin/vi]?

où le défaut serait rempli de $ENV{EDITOR}, $ENV{VISUAL} ou si ni est défini, /usr/bin/nano. De cette façon, l'utilisateur peut juger si la valeur a du sens.

Si vous êtes paranoïaque sur l'endroit où $ENV{EDITOR} points, vous pourriez aussi avoir à être paranoïaque si une personne aurait pu mettre un exécutable malveillant sur le chemin de l'utilisateur et l'a nommé greateditor ou une telle.