2020-01-16T13:59:14 GwenDragon

Niemals sollte sin Perl-Programm externen Variablen und Parametern vertrauen.
Interessant dazu: https://media.ccc.de/v/32c3-7130-the_perl_jam_2

Den CCC-Vortrag habe ich mir gerade angeguckt und war ziemlich enttäuscht. Der geht schon sehr auf Effekt aus und vermeidet jegliche Hinweise, wie man's richtig macht. Eine Sprache wie Perl, die einerseits mächtig ist und es andererseits einfach macht, Code zu schreiben, macht es eben auch leicht, unsicheren Code zu schreiben. Wenn Du Dir eine Kettensäge kaufst und Dir damit ins Bein sägst - ist dann die Kettensäge schuld? Henry Spencer war wohl der erste, der Perl als die "Swiss Army Chainsaw of scripting" bezeichnet hat...

2020-01-16T13:59:14 GwenDragon

Wenn eins es sicher will:
- nutzt den Schalter -t im Shebang (das aktviert den Taint-Mode)
- prüft per regex was in @ARGV drin steht
- sinnvollerweise nie so eben mal mit <> einlesen

Ich halte auch das Taint-Checking für eine hilfreiche Komponente, obwohl ich schon viel Zeit drauf verbraten habe, "false positives" (also Programmabstürze wegen Insecure dependency ohne wirkliche Unsicherheit) zu jagen. Es wird noch wirksamer mit -T anstelle von -t. Was man dazu wissen sollte und was leider nicht alles in perlsec steht:

• Taint-Mode nur in Shebang reicht nicht immer. Beim Aufruf von der Kommandozeile muss auch perl -T scriptname gestartet werden (auch im Crontab-Eintrag!). Wenn wie bei Apache und mod_cgi das Skript selbst ausführbar gemacht und direkt als scriptname gestartet wird, dann muss im Shebang der absolute Pfad zu Perl drinstehen. Das kann man dann nicht mehr so einfach mit perlbrew für verschiedene Perl-Versionen entwickeln und testen, die Variante #!/usr/bin/env -S perl -T tut's aber.
• Taint-Mode sollte man auf jeden Fall auch bei Unit Tests einschalten. Das ist leider manchmal mühsam, weil man bei Testdaten normalerweise drauf pfeift, ob sie sicher sind.
• Manche CPAN-Module (zum Beispiel Plack) funktionieren einfach nicht mit Taint-Mode. Wenn man die trotzdem braucht oder verwenden will, kann man -T nicht verwenden, Unit Tests mit Taint-Prüfung werden noch wichtiger.
• Im Taint-Mode ist die gesamte Umgebung %ENV "tainted". Das heißt, dass zum Beispiel die Umgebungsvariable PERL5LIB nicht ausgewertet wird, deswegen verträgt es sich unter anderem nicht mit local::lib.
• Auch $ENV{HOME}, $ENV{PWD} und das Ergebnis von Cwd::getcwd sind "tainted", was zu Ärger mit verwendeten CPAN-Modulen führen kann. In eigenem Code kann man das aktuelle Verzeichnis taint-sicher mit File::Spec->curdir() ermitteln.
• File::Temp verhält sich auch "anders", weil normalerweise die Default-Directories in Umgebungsvariablen stehen. Und die sind "tainted", werden also ignoriert.
• "Untainted" heißt nicht "sicher" - es ist nur eine der Komponenten. Aber das hat GwenDragon auch schon geschrieben: Traue keinen externen Parametern.

Sicherheit ist nicht ganz einfach. Wichtig für das richtige Augenmaß ist die Frage: Für wen schreibe ich den Code? Komponenten, die auf einem Webserver im Internet laufen oder die als Produkt verkauft werden sollen, müssen auch gegen clevere Verbrecher gewappnet sein. Was nur bei mir daheim und für mich läuft, darf auch mal lax sein, wenn's nur schnell fertig ist. Dass beides mit Perl möglich ist, betrachte ich als eine der Stärken von Perl.