|
Fragen und
Antworten zur CGI-Benutzung |
|
Dies ist die Liste von Fragen und Antworten zur Benutzung von
CGI-Skripten auf w3studi . Natürlich ist
die Liste nicht vollständig und wird bei neuen Fragen entsprechend
erweitert.
Grundlegendes
Spezielle Informationen zu w3studi
Sonstiges
|
|
|
|
Was
ist überhaupt "CGI"? |
|
Diese Frage wird hier nicht beantwortet. Wer nicht weiß, was in
diesem Zusammenhang mit CGI gemeint ist, der kann sich an anderer
Stelle (z.B. im WWW) darüber informieren. Gelegentlich wird an der
Fakultät auch ein Vortrag der inf.misc-Reihe diesem Thema gewidmet.
|
|
Wie
erstellt man ein CGI-Skript auf w3studi? |
|
Man nimmt ein ausführbares Programm (kompiliert oder
interpretiert), kopiert es in das eigene public_html-Verzeichnis und hängt
die Endung ".cgi" an den Dateinamen an. Danach setzt man noch die
entsprechenden Zugriffsrechte und schon ist es (theoretisch)
einsatzbereit.
|
|
Welche
Zugriffsrechte müssen gesetzt werden? |
|
- Wie bei HTML-Seiten üblich, muß im kompletten
Verzeichnispfad das execute-Recht für die Gruppe others
gesetzt sein.
- Achtung: Wenn das
Verzeichnis, in dem sich das Skript befindet, für andere
beschreibbar ist (d.h. wenn das write-Recht für die
Gruppen group oder others gesetzt ist), dann verweigert
der Web-Server aus Sicherheitsgründen die Ausführung des
Skripts.
- Außerdem benötigt die Skript-Datei noch die
folgenden Zugriffsrechte:
Interpretierte Skripte (z.B. Perl, Shell, etc.):
Lese- und Ausführrecht für den Besitzer (Shellbefehl: chmod
u+rx <Scriptdatei> )
Kompilierte Programme (z.B. C):
Ausführrecht für den Besitzer (Shellbefehl: chmod u+x
<Programmdatei> )
- Die folgenden Zugriffsrechte dürfen nicht gesetzt
sein: Schreibrecht für die Benutzergruppe oder für andere
Benutzer, SetUID- oder SetGID-Rechte
|
|
Was
sind die häufigsten Problemursachen? |
|
Die häufigsten Ursachen von Problemen mit CGI-Skripten sind
erfahrungsgemäß:
- Falsche Ausgabe-Header: die ersten Zeilen, die ein
CGI-Skript ausgibt, MÜSSEN
normalerweise folgendermaßen aussehen:
Content-type: text/html
gefolgt von ZWEI Newline-Zeichen (\n ).
Für die meisten Anwendungen sieht der Header wie eben beschrieben
aus. Wer daran etwas ändert, sollte wissen was er tut.
- Fehlerhafte Programme die schon in normaler Umgebung
nicht funktionieren. Hier ist besonders zu beachten, daß
kompilierte Programme für das richtige Zielsystem übersetzt
werden (d.h.
w3studi x86_64 GNU/Linux).
- Zugriffsrechte die falsch gesetzt wurden (siehe oben).
- Symbolic Links die als CGI-Skripte verwendet werden.
- Umgebungvariablen die in der CGI-Umgebung nicht
automatisch gesetzt werden (z.B. Bibliotheks-Pfade, etc.). Um sicher zu
sein, daß man sich in dieser Hinsicht nicht auf etwas falsches
verläßt, sollte man sich hier einmal anschauen,
welche Umgebungsvariablen bei einer CGI-Ausführung gesetzt werden.
- Unterschiede in der UserID von Skript und Verzeichnis:
wenn das CGI-Skript dem Benutzer brutzel gehört, dann
muß das Verzeichnis, in dem sich das Skript befindet, ebenfalls brutzel
gehören.
- Das Cache-Verhalten von Webbrowsern: auch wenn ein
Fehler (z.B. Zugriffsrechte) behoben wurde, kann es sein, daß der
Browser die Datei nicht neu lädt, sondern die gecachte Kopie der
Fehlermeldung erneut anzeigt. Gelegentlich zeigt auch das Dateisystem
des Rechners, auf dem sich der Webserver befindet, ein gewisses
Cache-Verhalten. Es empfiehlt sich zu Testzwecken die Datei
umzubenennen, um diese Fehlerquelle auszuschließen.
- Skripte, die auf Nicht-Unix-Rechnern geschrieben wurden,
haben gelegentlich das Problem, daß die unterschiedliche
Zeilenende-Markierung (bei Unix bestehend aus einem einfachen
Linefeed-Zeichen) den Interpreter durcheinanderbringen (Danke an Marc
für den Hinweis).
|
|
Was
ist außerdem zu beachten? |
|
Bei der Erstellung/Benutzung von CGI-Skripten sollten zudem noch die
folgenden Punkte beachtet werden:
- Die UserID.
Die Skripte laufen grundsätzlich unter der UserID des Besitzers,
d.h. ein CGI-Skript hat die gleichen Zugriffsrechte, wie der Besitzer.
Das heißt aber auch, daß alle Aktionen, die von dem Skript
ausgeführt werden (Dateien löschen und verändern, Mails
abschicken, etc.), vom Besitzer zu verantworten sind (siehe Benutzungsordnung).
- Systemsicherheit.
Aus Punkt 1 folgt, daß jeder vernünftige
CGI-Skript-Verfasser sich darum kümmern sollte, daß ein
Skript nur Dinge tut, für die es ausgelegt wurde. Es sollte z.B.
auf keinen Fall irgendeine Eingabe, die von der Browser-Seite kommt,
als Shell-Kommando bzw. Parameter für ein Shell-Kommando
verwenden. Außerdem sollte der Source-Code des Skriptes nicht von
aller Welt lesbar sein (wegen möglicher Programmierfehler).
Da die Zahl der denkbaren Sicherheitslücken in CGI-Skripten schier
unendlich groß ist, sollte man sich im Web einmal über die
am weitesten verbreiteten Programmier-Tücken informieren.
- Zombie-Programme.
CGI-Skripte werden ohne direkte Kontrolle des Programmierers gestartet.
Bei Programmierfehlern kann es schnell passieren, daß zig
unkontrollierte Programme durch Überlastung das System lahmlegen.
Man sollte deshalb sicherstellen, daß ein CGI-Skript nicht in
einer Endlos-Schleife enden kann.
- Fehler-Ausgaben. Man sollte Meldungen auf die
Fehler-Ausgabe (
stderr ) verhindern, da diese
unweigerlich im Server-Logfile landen.
|
|
Benutzung
von PHP |
|
Auf w3studi ist ein PHP-Parser installiert
(Version 5.6). PHP-Skripte werden durch die Dateinamensendung ".php"
als solche markiert, weitere Angaben im Skript (z.B. Shebang-Zeile) sind
nicht nötig.
Das Skript wird wie bei normalen CGI-Skripten unter der Benutzer-ID des
Besitzers der Skript-Datei ausgeführt. Die Hinweise zur
Systemsicherheit für CGI-Skripte sind zu beachten. Es empfiehlt
sich zudem die Lektüre des Kapitels über Sicherheit im
PHP-Handbuch.
|
|
Allgemeines
zu w3studi |
|
- Ein direkte Einloggen auf
w3studi ist
per ssh möglich.
|
|
Perl |
|
- Der Pfad zum Perl-Interpreter lautet:
/usr/bin/perl
|
|
Shells |
|
Es sind die folgenden Shells verfügbar:
- Bourne-Shell unter
/bin/sh
- tcsh unter
/usr/bin/tcsh
|
|
Ich
habe eine Sicherheitslücke entdeckt, was soll ich tun? |
|
Sicherheitslücken sind in offenen Systemen nicht vollständig
vermeidbar. w3studi ist ein solches System, das
mit der Möglichkeit, CGI- sowie PHP-Skripte unentgeltlich
ausführen zu lassen, den Wünschen der Benutzer entgegenkommt.
Wenn Du als anonymer Web-Benutzer eine Sicherheitslücke in unserem
System entdeckst, hast Du zwei Möglichkeiten:
- Du folgst den Verlockungen der dunklen
Seite, indem Du die Gelegenheit ausnutzt, um Deinen
persönlichen Machthunger zu stillen, um unberechtigt Daten zu
lesen und zu verändern oder um andere Systeme von hier aus
anzugreifen. Leute, die diesen Weg gehen, werden umgehend mit
Mundgeruch, Schweißfüßen und Haarausfall gestraft.
Fliegt der Mißbrauch auf und wird der Schuldige (in diesem Fall
DU!) gefunden, so warten auf diesen Vierteilung, Häutung und
24-Stunden erzwungene Berieselung mit Aufzeichnungen diverser
Privatfernseh-Talkshows. Handelt es sich um lokale Studenten, so sieht
die Benutzungsordnung
Maßnahmen vor, die bei der Sperrung des Rechnerzugangs beginnen.
Zudem wird es einen traurigen Webadministrator auf der Welt mehr geben
(*schniff*).
Abgesehen davon kann der WWW/CGI/PHP-Zugang bei Mißbrauch
komplett und ohne Vorwarnung für alle Benutzer gesperrt werden.
- Du erfreust Dich leise an Deinen Hacker-Fähigkeiten
und meldest die Sicherheitslücke an www@w3studi.informatik.uni-stuttgart.de.
In diesem Fall wirst Du kurzfristig als Held gefeiert, die Sonne wird
an einem kristallklaren, dunkelblauen Himmel erstrahlen, das Gras wird
wieder grün werden und für einen Augenblick wird Frieden auf
der Erde herrschen. Kein Web-Administrator muß leiden (*jubel*).
Fassen wir also zusammen: das Ergebniss von Punkt
1 besteht aus 1<n<muchos traurigen Personen,
einem schlechten Gewissen und potentiell einem offenen Webserver
weniger. Punkt 2 hingegen
verspricht ein paar Punkte für die Karma-Highscore.
Welchen Weg wählst Du...?
|