Alles unter Kontrolle mit einer Parameter Kontrollstruktur

Der Aufruf gleichnamiger Funktionen stellt ein erhebliches Sicherheitsproblem dar

Stellen Sie sich vor, Sie hätten verschiedene Namen ihrer serverseitigen Funktionen auf Parameter abgebildet:

Dann würde ein Klick auf einen der obenstehende Links die dem Parameternamen entsprechende Funktion aufrufen! Das Problem: Jeder kann auf diese Art und Weise Ihre Funktionen per HTTP aufrufen!

Besser also eine Parameter-Kontrollstruktur:


if($self->param('insert)){}  
elsif($self->param('edit)){}  
elsif($self->param('delete)){}  
elsif($self->param('update)){}  
elsif($self->param('rmrecursive)){} 
else{ die "Unbekannter Parameter!\n" }

Und darüber hinausgehend, den Pool der erlaubten Parameter einschränken und kontrollieren:

    # Nur bestimmte Parameter erlauben
    my %valipar = ();
    my @inpar = $self->param;
    @valipar{@inpar} = @inpar;
    # erlaubte Parameter löschen
    delete @valipar{qw(find week year)};
    # was übrigbleibt ist bad request
    return $self->noparam
        if keys %valipar;

Was Funktionsnamen betrifft, gilt das natürlich auch für Module. Das heißt, daß zum URL gehörige Klassen nicht über HTTP als Parameter benannt und übergeben werden. Sonst kann es nämlich passieren, daß ein Benutzer eine ganz andere Klasse bzw. Modul vorgibt und schon macht Ihre Anwendung was ganz anderes, auf jeden Fall nicht mehr das was sie soll!

Konstrukte wie untenstehend:

my $coderef = require "Modulname laut Parameter";
$coderef->();

sind als besonders kritisch einzuschätzen, weil sie den Namespace erweitern. Die von einem Benutzer vorgegebene Klasse liefert eine Codereferenz, welche unmittelbar ausgeführt wird! Von solchen Konstrukten ist dringend abzuraten zumal sich sowas recht einfach vermeiden lässt durch eine interne Konfiguration.


Anbieter: nmq​rstx-18­@yahoo.de, die Seite verwendet funktionsbedingt einen Session-Cookie und ist Bestandteil meines nach modernen Aspekten in Perl entwickelten Frameworks.