hallo erstmal,
ich bastele gerade an einem erweiterten gästebuch und hätte als hobby-programmierer mal eine verständnisfrage zur sicherheit von scripts: an welchem punkt interpretiert ein web-server eigentlich genau evtl. vorhandene („böswillige“) befehle aus einem eingabeformular- sofort, wenn er die daten erhält (und in seiner umgebungsvariablen speichert) oder erst, wenn dieser string zu weiterverarbeitungszwecken zerlegt wird?
greetings
bernd
an welchem punkt interpretiert ein
web-server eigentlich genau evtl. vorhandene („böswillige“)
befehle aus einem eingabeformular- sofort, wenn er die daten
erhält (und in seiner umgebungsvariablen speichert) oder erst,
wenn dieser string zu weiterverarbeitungszwecken zerlegt wird?
Prinzipiell interpretiert der Server – solange der HTTP-teil mal vernünftig funktioniert – nicht allzuviel an den Formulardaten, das erledigen dann die Scripts dahinter. Der Trick bei Attacken besteht darin, eine Zeichenkette zu verschicken, die dann ein ausnutzbares Fehlverhalten provoziert. So könnte z.B. wenn dein Script irgendeine Eingabe ohne weitere Vorsichtsmaßnahmen in eine Datenbank schickt jemand auf die Idee kommen, diese Eingabe so zu gestalten, dass dadurch eine ganz andere Abfrage als ursprünglich geplant (z.B. DROP) abgearbeitet wird.
hallo nicos,
Formulardaten, das erledigen dann die Scripts dahinter.
mal konkret (wobei ich hoffe, dass das nicht so einfach funktioniert 
hieße das also, wenn jemand z.b. rmdir als namen angibt, interessiert das den server erstmal nicht, es würde dann im zweifelsfall das script-verzeichnis löschen (?)
wie man wohl sieht, frage ich mich, an welcher stelle ein filter am sinnvollsten einzubauen ist. würde bei einem konstrukt wie
$name=param(‚name‘);
ein evtl. vorhandener befehl schon ausgeführt?
greetings
bernd
wie man wohl sieht, frage ich mich, an welcher stelle ein
filter am sinnvollsten einzubauen ist. würde bei einem
konstrukt wie
$name=param(‚name‘);
ein evtl. vorhandener befehl schon ausgeführt?
Nein, der würde erst ausgeführt, wenn du dann intelligenterweise noch irgendwas wie system($name) hinterherschieben würdest. Du musst immer bedenken, was mit den Daten passiert. Solange du nur irgendwelche Stringoperationen damit machst, passiert nichts. Kritisch wird es, wenn die Daten in irgendeiner Art an den Rest vom System wandern. Deshalb musst du sämtliche Benutzerdaten immer behandeln wie Giftmüll, wenn du sie z.B. für Datenbankabfragen oder Systembefehle verwenden willst.
Wo wir schon bei Befehlen sind: nehmen wir mal an, du benutzt ls, um an irgendwelche Verzeichniseinträge ranzukommen. Der Benutzer kann über ein Formular in der Variablen „filter“ die Suche einschränken, z.B. mit „a*“ nach allen mit a beginnenden Dateinamen suchen. Der naive Ansatz wäre dann ( Kinder, versucht das nie zuhause! ):
my $filter = param( 'filter' );
# jetzt basteln wir uns irgendwas, um die Ausgabe von ls aufzufangen
# ...
system( "ls -l $filter" );
# ...
So weit so gut. Jetzt schicken wir da mal probehalber als Filter den String „. ; rm -rf .“ rein. Panik bricht aus.
Aus genau dem Grund bietet z.B. DBI das Konstrukt mit nachträglich eingefügten Parametern, die dann entsprechend vorbehandelt werden. Wenn du externe Bibliotheken verwendest solltest du dich immer kundig machen, welche Schnittstellen in dieser Hinsicht als „sicher“ gelten und welche man nur mit Daten fütter sollte, über die man die volle Kontrolle hat.
ok-
jetzt seh ich schon klarer- besten dank für die gründlichen ausführungen.
greetz
bernd
Ganz interessant ist in diesem Zusammenhang auch die Kommandozeilen-Option „-T“.
In deinem Script beispielsweise durch
#!/usr/bin/perl -T
aktiviert, wirft sie jedesmal mit einem Error um sich, wenn du Benutzereingaben ungefiltert weiterverwendest.
Mehr dazu mit perldoc perlsec oder unter http://perldoc.perl.org/perlsec.html
Dennis