impressum userpages infos anfang
w3studi Navigation


    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:
  1. 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).
     
  2. 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.
     
  3. 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.
     
  4. 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:
  1. 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.

  2. 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...?


Letzte Änderung am 18. April 2016 - Impressum