cgi-und-logfiles

CGI: Schnittstelle zwischen Webserver und externem Programm

CGI – das Common Gateway Interface – beschreibt eine Schnittstelle, über die ein Webserver ein externes Programm zur Bearbeitung einer Anfrage aufrufen und dessen Ausgabe in die Serverantwort einbeziehen kann. Damit wurde serverseitige Dynamik möglich, ohne die Programmlogik fest an eine einzelne Programmiersprache zu binden.

Eine statische HTML-Datei kann unmittelbar ausgeliefert werden. Ein klassisches CGI-Programm wird dagegen für eine Anfrage ausgeführt. Der Server stellt Requestinformationen als Meta-Variablen und gegebenenfalls einen Body über Standardinput bereit; das Programm erzeugt CGI-Antwortfelder und einen optionalen Body über Standardoutput.

Diese Einfachheit machte die technischen Abhängigkeiten deutlich sichtbar: Interpreter, Pfade, Dateirechte, Umgebung, Eingabedaten und Ausgabeformat mussten zusammenpassen. Fehler ließen sich deshalb oft auf eine konkrete Schicht zurückführen.

Zusammenhang: Shell-Accounts und Hosts beschreibt die darunterliegende Systemumgebung; auf Webentwicklung 1996 steht CGI im historischen Zusammenhang mit früher Webentwicklung.

Vom HTTP-Request zur CGI-Antwort

1. Verbindung und Request: Der Webserver liest Methode, Ziel, Header und gegebenenfalls einen Message-Body.
2. URL-Zuordnung: Serverkonfiguration entscheidet, ob das Ziel statisch, CGI oder ein anderer Handler ist.
3. Ausführungsumgebung: Server erzeugt Meta-Variablen, setzt Arbeitsverzeichnis und startet Programm beziehungsweise Interpreter.
4. Eingabe: Request-Metadaten liegen in der Umgebung; der Body wird über Standardinput bereitgestellt.
5. Anwendungslogik: Skript validiert, verarbeitet und erzeugt eine Antwort.
6. Ausgabe: CGI-Header und Body gehen über Standardoutput an den Server.
7. Diagnose: Meldungen auf Standardfehler landen je nach Serverkonfiguration im Error-Log.
8. Abschluss: Server bildet daraus die HTTP-Antwort und schreibt Zugriffs- sowie gegebenenfalls Fehlerdaten.

Der Browser spricht nicht direkt mit dem Perl-Skript. Der Webserver bleibt für Verbindung, Request-Lesen, URL-Zuordnung, Zugriffskontrolle und die endgültige HTTP-Antwort zuständig.

Vertiefung: Webentwicklung 1996 behandelt HTTP und CGI im damaligen Webkontext; Shell-Accounts und Hosts die darunterliegende Laufzeitumgebung.

Klassisches CGI, mod_cgi und dauerhafte Prozesse

Klassisches CGI startet für jeden Request ein neues Programm. Das schafft eine klare Zustandsgrenze: Der Prozess erhält genau seine Umgebung, verarbeitet genau diesen Request und endet wieder.

„Dauerhaft“ ist nicht automatisch sicherer oder einfacher. Klassisches CGI bezahlt mit Prozesskosten; persistente Systeme bezahlen mit langlebigem Zustand, Speicherverwaltung und komplexerer Isolation.

Vertiefung: Server-Härtung ordnet Prozess-, Rechte- und Betriebsgrenzen moderner Serverumgebungen ein.

Shell-Account, Serverpfade und Laufzeitumgebung

Frühe CGI-Praxis lag unmittelbar an der Server- und Benutzerumgebung. Dateien befanden sich in realen Verzeichnisstrukturen; Benutzer- und Gruppenrechte, Skriptpfade, Shebang-Zeilen, Interpreterversionen und Umgebungsvariablen konnten über Erfolg oder Fehler entscheiden.

Ein Shell-Zugang war deshalb häufig ein wichtiges Arbeitsmittel: Dateien übertragen, Rechte prüfen, Skripte direkt ausführen, Logdateien lesen, Verzeichnisse untersuchen und unterscheiden, ob ein Problem aus Programmcode, Pfad, Dateirechten oder Serverkonfiguration entstand.

• cgi-bin oder freigeschaltete CGI-Verzeichnisse: Ausführbarkeit hing von der Serverkonfiguration ab.
• Shebang: Bei direkt ausführbaren Skripten musste ein passender Interpreterpfad vorhanden sein.
• Dateirechte: Server- oder Benutzerkontext benötigten die für den jeweiligen Zugriff erforderlichen Rechte.
• Pfadlogik: relative und absolute Pfade waren häufige Fehlerquellen bei Includes, Templates oder Datendateien.
• Umgebung: REQUEST_METHOD, QUERY_STRING, CONTENT_LENGTH, REMOTE_ADDR und weitere Meta-Variablen bildeten Teile der Schnittstelle.

Die Laufzeitumgebung war damit keine Nebensache, sondern Bestandteil des Programmsystems. Ein Skript, das im interaktiven Benutzerkontext funktionierte, musste unter dem tatsächlichen Webserverkontext nicht zwangsläufig dieselben Pfade, Rechte oder Umgebungswerte vorfinden.

Vertiefung: Shell-Accounts und Hosts sowie Unix und Linux im Alltag behandeln Benutzerkontexte, Shell, Dateirechte und Systemumgebung ausführlicher.

Meta-Variablen: Vertrag zwischen Server und Skript

Zusammenhang: Die Host- und Prozessumgebung hinter diesen Variablen wird auf Shell-Accounts und Hosts weitergeführt.

SCRIPT_NAME, PATH_INFO und Dateisystempfade

Bei einer URL wie /cgi-bin/item.pl/gruppe/42 bezeichnet SCRIPT_NAME typischerweise das Skript, während PATH_INFO den zusätzlichen Pfadteil enthält. Diese Trennung erlaubte früh sprechendere CGI-URLs.

PATH_INFO ist jedoch kein geprüfter lokaler Dateiname. Punkte, Schrägstriche, Kodierung und Normalisierung können zwischen URL-, Server- und Betriebssystemebene unterschiedlich behandelt werden.

• URL-Pfad dekodieren: nur nach klar definierter Reihenfolge und niemals mehrfach unkontrolliert.
• Erlaubte Segmente festlegen: interne IDs besser gegen eine Allowlist beziehungsweise ein enges Format prüfen.
• Dateipfade selbst erzeugen: keine Benutzerpfade direkt an open, unlink oder Shellkommandos weiterreichen.
• Basisverzeichnis festhalten: nach Normalisierung prüfen, dass das Ziel weiterhin innerhalb des vorgesehenen Bereichs liegt.

Header zuerst: warum kleinste Ausgabefehler alles stoppen

Einer der frühesten und wichtigsten Lerneffekte bei CGI war die Tatsache, dass die Antwort formal beginnen musste. Bei einer normalen Dokumentantwort liefert das Skript mindestens Content-Type; fehlt ein eigener Status-Header, wird üblicherweise Status 200 angenommen. Nach den Headerfeldern folgt eine leere Zeile und erst danach der optionale Message-Body.

Für heutige Systeme klingt das trivial. In der frühen Praxis war es eine konstante Fehlerquelle. Ein zusätzliches Leerzeichen an falscher Stelle, eine Warnung vor dem Header, eine kaputte Zeichenausgabe, ein Modulhinweis, ein Debug-Print zu früh – und schon war die Antwort aus Sicht des Servers beschädigt. Der Browser zeigte oft nur einen generischen Fehler. Das Error-Log hingegen war meist präziser.

Gerade daran lernte man ein frühes Gefühl für Protokolldisziplin. Das Problem war selten „CGI allgemein“. Das Problem war meistens sehr konkret: falscher Header, Header zu spät, Zeichensatzfrage, ungewollte Ausgabe, fehlende Leerzeile oder ein Skriptabbruch, bevor überhaupt ein Header zurückgegeben wurde.

Vertiefung: Webentwicklung 1996 behandelt HTTP-Antworten im historischen Webkontext; Server-Härtung heutige Header- und Serverregeln.

Dokumentantwort, Status und Redirect

Ein CGI-Skript sollte erwartbare Benutzerfehler nicht als unkontrollierten Prozessabbruch behandeln. Eine definierte 4xx-Antwort ist diagnostisch und betrieblich klarer als ein generischer 500er.

GET, POST und die tatsächliche Eingaberealität

GET und POST unterscheiden sich zunächst durch ihre HTTP-Semantik. GET ist für das Abrufen einer Ressource definiert und gilt als sichere Methode. POST übergibt eine Darstellung an die Zielressource, damit diese sie gemäß ihrer eigenen Semantik verarbeitet.

Bei klassischen HTML-Formularen mit method="get" werden die Formulardaten in den Query-Teil der Ziel-URL codiert. Bei method="post" werden Formulardaten typischerweise im Request-Body übertragen. Ein Body schafft jedoch ohne TLS keine Vertraulichkeit und darf nicht mit einer Sicherheitsfunktion verwechselt werden.

Entscheidend bleibt die serverseitige Verarbeitung. Prozentkodierung, Zeichensätze, Mehrfachwerte, Zeilenumbrüche und Grenzfälle müssen nach klaren Regeln behandelt werden. Methode und Transportform ersetzen keine Validierung.

Zusammenhang: Webentwicklung 1996 ordnet frühe Formulare, HTTP und CGI historisch ein; Server-Härtung behandelt heutige Betriebsgrenzen.

application/x-www-form-urlencoded und multipart/form-data

Das Skript darf nicht unabhängig vom CONTENT_TYPE denselben Parser verwenden. Besonders Multipart-Daten sollten mit einer bewährten Bibliothek verarbeitet werden; selbstgeschriebene Boundary-Parser sind fehleranfällig.

Dekodierung, Mehrfachwerte und Zeichensätze

Ein Parametername kann mehrfach vorkommen: tag=unix&tag=perl. Ein Parser muss deshalb festlegen, ob er eine Liste, den ersten oder den letzten Wert liefert. Stillschweigende Unterschiede zwischen Bibliotheken können Sicherheitsprüfungen und Anwendungslogik auseinanderlaufen lassen.

• Rohdaten zuerst begrenzen: maximale Body- und Feldgröße vor vollständiger Verarbeitung festlegen.
• Einmal dekodieren: mehrfache Prozentdekodierung kann Prüfungen umgehen.
• Namen und Werte trennen: für jedes Feld ein erwartetes Format und eine maximale Länge definieren.
• Mehrfachwerte bewusst behandeln: keine zufällige „erste oder letzte gewinnt“-Logik.
• Unicode normalisieren, wenn fachlich nötig: sichtbare Gleichheit und Bytegleichheit sind nicht dasselbe.
• Ausgabekontext beachten: Validierung ersetzt nicht HTML-, Header-, Shell- oder Datenbank-spezifisches Escaping.

Perl-CGI in der frühen Praxis

Frühes CGI war oft praktisch gleichbedeutend mit Perl. Nicht weil Perl die einzige Möglichkeit gewesen wäre, sondern weil es auf vielen Systemen vorhanden, textstark, pragmatisch und gut genug für genau diese Übergangsschicht war. Formulare lesen, Strings zerlegen, Mail zusammensetzen, Dateien öffnen, Datum und Zeit formatieren, kleinere Zustände verwalten – all das ließ sich in Perl mit vergleichsweise wenig Aufwand umsetzen.

Gleichzeitig war Perl kein Schutzraum. Wenn das Skript schlampig war, war das Ergebnis schlampig. Wenn Variablen unklar geführt wurden, wurde die Fehleranalyse unangenehm. Wenn reguläre Ausdrücke schlecht saßen oder Eingaben blind übernommen wurden, entstanden echte Probleme. Gerade deshalb war frühe Perl-Praxis für viele lehrreich: nicht wegen Eleganz im akademischen Sinn, sondern weil sich die Folgen jeder Nachlässigkeit unmittelbar zeigten.

Wer mit Perl-CGI arbeitete, lernte außerdem etwas Wichtiges über Webdynamik: Der eigentliche Aufwand lag selten im sichtbaren HTML. Der Aufwand lag in korrekter Übergabe, validen Zuständen und reproduzierbarer Fehlersuche. Genau deshalb waren Access- und Error-Logs kein Nebenthema, sondern permanenter Bestandteil der Arbeit.

Perl-Skripte nachvollziehbar und defensiv halten

• strict und warnings: machen Variablenfehler und verdächtige Zustände früher sichtbar.
• Taint Mode: kann über -T zusätzliche Prüfungen für fremd beeinflusste Daten aktivieren, ist aber kein Ersatz für Validierung oder ein Berechtigungsmodell.
• Expliziter PATH: externe Programme nicht über eine unkontrollierte Suchumgebung finden lassen.
• Dreiargumentiges open: Modus und Dateiname getrennt halten; Benutzerdaten nicht als implizite Pipe-Syntax interpretieren lassen.
• List-Form statt Shell: externe Programme möglichst ohne Shell und mit getrennten Argumenten aufrufen.
• Ausgabe kontextgerecht codieren: HTML, Mailheader, Dateiname und Shellargument brauchen unterschiedliche Regeln.

Formulare, Mail-Skripte und die Realität dahinter

Für viele war CGI zuerst über Formulare sichtbar. Kontaktformulare, einfache Bestellanfragen, Gästebuch-Einträge, kleine Suchmasken oder Konfigurationsübergaben – all das lief im Kern auf dieselbe Frage hinaus: Wie kommen Benutzereingaben kontrolliert auf dem Server an und was passiert dann damit? Browserseitige Pflichtfelder und JavaScript waren dabei nur Bedienhilfe; die maßgebliche Prüfung musste serverseitig erfolgen.

In der frühen Praxis war das häufig ein Mail-Skript. Der Browser schickte ein Formular, CGI nahm Felder entgegen, prüfte sie mehr oder weniger gut und setzte daraus eine E-Mail oder eine lokale Datendatei zusammen. Technisch simpel, praktisch aber voller Fallstricke: fehlende Feldprüfung, ungefilterte Sonderzeichen, kaputte Newlines, Header-Manipulation, falsche Rechte auf temporären Dateien oder ein Sendmail-Aufruf, der lokal anders funktionierte als gedacht.

• Pflichtfelder: nicht nur im Browser markieren, sondern serverseitig wirklich prüfen.
• Zeilenumbrüche: harmlose Textfelder konnten Mails und Dateiformate schnell unlesbar machen, wenn man sie blind übernahm.
• Mailversand: Empfänger fest konfigurieren, Headerzeilenumbrüche aus Benutzereingaben ablehnen und möglichst eine Mailbibliothek statt zusammengesetzter Shellbefehle verwenden.
• Missbrauchsschutz: Größen-, Zeit- und Frequenzgrenzen sowie nachvollziehbare Fehlerantworten einplanen.
• Dankeseiten und Redirects: mussten als HTTP-Antwort technisch ebenso korrekt gebaut werden wie jede normale HTML-Seite.

Gerade daran trennte sich frühe Webromantik von tatsächlicher Webarbeit. Ein Formular war eben nicht „fertig“, nur weil es hübsch erschien. Es war erst dann brauchbar, wenn Eingaben sauber entgegengenommen, protokolliert, geprüft und nachvollziehbar verarbeitet wurden.

Zusammenhang: Formulare berühren Eingabeverarbeitung, Mailtransport und Datenschutz. Die datenschutzrechtliche Rolle der aktuellen Archivdomain steht in Datenschutz; technische Sicherheitsgrenzen auf Server-Härtung.

Dateien, Sperren, temporäre Daten und atomare Updates

Gästebücher, Zähler und einfache Formularablagen schrieben häufig direkt in Dateien. Genau dort entstanden Nebenläufigkeits- und Rechteprobleme: zwei gleichzeitige Prozesse konnten denselben Stand lesen und einander anschließend überschreiben.

• Sperren: bei gemeinsam veränderten Dateien passende exklusive beziehungsweise gemeinsame Locks verwenden.
• Temporäre Dateien: sicher erzeugen, nicht aus erratbaren Namen im allgemein beschreibbaren Verzeichnis zusammensetzen.
• Atomarer Austausch: vollständigen neuen Stand schreiben, synchronisieren und anschließend innerhalb desselben Dateisystems umbenennen.
• Umask und Rechte: neu erzeugte Dateien nur den tatsächlich benötigten Konten zugänglich machen.
• Keine Webauslieferung: Rohdaten, Mailwarteschlangen und Zustandsdateien außerhalb öffentlich erreichbarer Verzeichnisse halten.
• Symlinks beachten: privilegierte oder anders berechtigte Prozesse dürfen nicht auf vom Angreifer umleitbare Pfade schreiben.

Ein erfolgreiches open bedeutete noch nicht, dass ein Mehrbenutzerbetrieb korrekt war. CGI machte Nebenläufigkeit selbst bei kleinen Seiten zu einer realen Systemfrage.

Vertiefung: Datensicherung und Backups behandelt Wiederherstellung, Zustandskopien und den Erhalt wichtiger Dateien.

Prozessstart, Interpreterkosten und Ressourcen

Bei klassischem CGI werden Interpreter, Module und Programmlogik für jeden Request neu gestartet. Für gelegentliche Formulare war das oft akzeptabel; bei hohem Verkehr oder großen Abhängigkeiten wurde es teuer.

Access-Log: wer kam, wann und womit

Das Access-Log war die rohe Spur des Verkehrs. Dort stand nicht die philosophische Bedeutung eines Zugriffs, sondern ganz praktisch: wann etwas angefordert wurde, von welcher direkten Netzwerkadresse, mit welcher Methode, auf welches Ziel, mit welchem finalen Statuscode, in welcher Größe und – je nach Format – mit welchem Referer oder User-Agent. Hinter Proxy oder Loadbalancer ist die protokollierte Gegenstelle nicht automatisch der ursprüngliche Benutzer.

Für frühe Webarbeit war das enorm nützlich. Man sah, ob eine Seite wirklich aufgerufen wurde, ob ein CGI-Endpunkt 200 oder 500 lieferte, ob ein Formular mit GET statt POST ankam, ob ein Bot über alte Pfade lief oder ob jemand immer wieder dieselbe defekte URL abfragte. Das Access-Log war damit kein Statistikspielzeug, sondern Betriebsprotokoll.

Gerade in Kombination mit dem Error-Log wurde daraus eine brauchbare Arbeitsmethode: Im Access-Log sah man, dass etwas passiert war. Im Error-Log sah man oft, warum es scheiterte.

Vertiefung: Shell-Accounts und Hosts ordnet Logs in die Hostpraxis ein; Server-Härtung behandelt Protokollierung als Teil des Serverbetriebs.

Common Log Format und Combined Log Format

Apache kann das Zugriffsformat über LogFormat festlegen. Das klassische Common Log Format enthält Gegenstelle, Identität, Benutzer, Zeitpunkt, Requestzeile, finalen Status und übertragene Bytes.

Das Combined Log Format ergänzt Referer und User-Agent:

Logfelder sind Beobachtungen, keine automatisch verifizierten Tatsachen. Referer und User-Agent stammen gewöhnlich direkt aus Client-Headern.

Statuscodes als erste Klassifikation

Ein 200er beweist nur, dass der Server eine erfolgreiche Antwort geliefert hat. Er beweist nicht, dass eine Mail zugestellt, ein Datensatz dauerhaft geschrieben oder eine fachliche Transaktion korrekt abgeschlossen wurde.

Error-Log: wo die Wahrheit über Fehler stand

Das Error-Log war für CGI meistens der eigentliche Arbeitsplatz. Browserfehler waren oft unpräzise. Eine leere Seite, ein 500 Internal Server Error oder einfach nur eine kaputte Antwort sagten wenig. Das Error-Log dagegen sagte häufig das Entscheidende: Syntaxfehler, fehlende Module, falscher Interpreterpfad, unzulässige Rechte, Header-Probleme, Warnungen vor dem Header, Datei nicht gefunden, uninitialisierte Variablen oder Shell-Aufrufe, die nicht durchliefen.

Wer ernsthaft mit CGI arbeitete, gewöhnte sich früh an diese Reihenfolge: Nicht zuerst den Browser anstarren, sondern das Error-Log lesen. Dort lag meistens die eigentliche Wahrheit. Und wenn dort nichts stand, war das auch eine Information – dann musste man die Logkonfiguration, die Rechte oder den tatsächlichen Ausführungspfad prüfen.

Vertiefung: Die systematische Hostdiagnose wird auf Shell-Accounts und Hosts weitergeführt.

STDERR, Warnungen und Request-Zuordnung

Ein CGI-Programm sollte Diagnosemeldungen auf Standardfehler und die eigentliche CGI-Antwort auf Standardoutput schreiben. Vermischen sich beide Kanäle, können Warnungen vor dem Header eine ansonsten richtige Antwort zerstören.

• Kontext protokollieren: Skript, Phase, Fehlerklasse und eine nicht geheime Request-Kennung.
• Keine Passwörter: Authentisierungsdaten, vollständige Formulare und Session-Geheimnisse nicht in Diagnosemeldungen schreiben.
• Zeit korrelieren: Access- und Error-Log nach Zeitpunkt, Prozess-/Thread- und Request-Kennung verbinden.
• Benutzerfehler trennen: erwartbare 4xx-Fälle nicht als unverständliche Perl-Warnung behandeln.

IP-Adressen, URLs und Formulardaten nicht gedankenlos sammeln

Access- und Anwendungslogs können IP-Adressen, Zeitpunkte, aufgerufene Pfade, Query-Strings, Referer, User-Agent, Benutzernamen und fachliche Vorgänge zusammenführen. Schon eine URL kann Suchbegriffe, interne IDs oder persönliche Angaben enthalten.

• Zweck festlegen: Betrieb, Sicherheit und Fehleranalyse von bloßer Neugier trennen.
• Query-Strings prüfen: Passwörter, Tokens und persönliche Inhalte gehören nicht in URLs.
• Felder minimieren: nur protokollieren, was für den definierten Zweck benötigt wird.
• Zugriff begrenzen: Logs nicht als allgemein lesbare Textdateien behandeln.
• Aufbewahrung begrenzen: Rotation und Löschung nach nachvollziehbarem Plan.
• Export bereinigen: Beispieldaten und Archivkopien anonymisieren beziehungsweise pseudonymisieren.

Die konkrete rechtliche Bewertung gehört in die aktuelle Datenschutz- und Betriebsdokumentation der Domain, nicht in eine historische CGI-Anleitung.

Aktuelle Einordnung: Angaben zur Datenverarbeitung auf sslxy.de stehen in der Datenschutzerklärung. Historische Logpraxis wird hier davon getrennt dokumentiert.

Logs selbst sind eine Eingabeschnittstelle

Requestziele und Header können vom Client beeinflusst sein. Rohlogs können deshalb Steuerzeichen, täuschende Zeilenumbrüche, Terminalsequenzen oder absichtlich irreführende Texte enthalten.

• Rohlogs vorsichtig anzeigen: nicht blind in privilegierte Terminal- oder HTML-Ausgaben übernehmen.
• Strukturiert parsen: Felder nicht nur an Leerzeichen zerlegen, wenn Anführungszeichen und Escape-Regeln beteiligt sind.
• Untrusted markieren: Referer, User-Agent, Host und Query bleiben fremde Daten.
• Geheimnisse redigieren: Tokens, Session-IDs und Passwörter vor zentraler Sammlung entfernen.
• Integrität schützen: Logverzeichnisse dürfen nicht durch Web- oder Skriptbenutzer beliebig austauschbar sein.

Vertiefung: Server-Härtung behandelt Logverzeichnisse, Rechte, Integrität und sichere Betriebsgrenzen ausführlicher.

Rotation, Wiederöffnung und Aufbewahrung

Ein laufender Webserver hält Logdateien geöffnet. Nur eine Datei umzubenennen oder zu löschen garantiert deshalb nicht, dass der Prozess sofort in eine neue Datei schreibt.

1. Rotieren: aktuelle Datei nach festem Größen- oder Zeitplan umbenennen beziehungsweise über ein Rotationsprogramm führen.
2. Neu öffnen: Webserver kontrolliert beziehungsweise „graceful“ zum Wiederöffnen der Logs veranlassen.
3. Komprimieren: erst geschlossene ältere Dateien komprimieren.
4. Rechte erhalten: neue Logdateien mit korrektem Eigentümer und restriktivem Modus erzeugen.
5. Aufbewahren und löschen: Betriebs-, Sicherheits- und Datenschutzanforderungen gemeinsam berücksichtigen.
6. Rotation überwachen: volles Dateisystem und stillstehende Rotation selbst protokollieren oder alarmieren.

Apache kann Logs auch an ein Rotationsprogramm weiterleiten. Dieses Modell vermeidet manuelle Signalfolgen, erhöht aber die Abhängigkeit von einem weiteren laufenden Prozess.

Zusammenhang: Logrotation gehört zum Serverbetrieb; langfristige Erhaltung und Wiederherstellung werden auf Datensicherung und Backups weitergeführt.

Debugging ohne Komfortschicht

Frühe CGI-Arbeit bedeutete oft Debugging ohne die Bequemlichkeiten späterer Entwicklungsumgebungen. Kein hübscher Live-Inspector, kein eingebauter Stacktrace im Browser, kein vollintegriertes Observability-System. Stattdessen: Skript lokal aus der Shell aufrufen, Testparameter manuell setzen, Header-Ausgaben kontrollieren, temporäre Debug-Ausgaben einbauen, Logdateien lesen und dann die Kette aus Request, Skript und Antwort gedanklich sauber nachverfolgen.

Gerade diese Reduktion hatte einen Vorteil: Man lernte, die Schichten zu trennen. Läuft das Skript überhaupt? Kommt der Interpreter hoch? Sind die Variablen gesetzt? Ist die Methode korrekt? Ist die Content-Length als Bytezahl plausibel und innerhalb des Limits? Kommt vor dem Header ungewollte Ausgabe? Ist ein Dateipfad relativ falsch? Ist ein Modul vorhanden? Jede Frage griff in eine andere Ebene – und genau so musste man sie behandeln.

„Debugging hieß oft nicht, auf eine IDE zu warten. Es hieß lesen, was wirklich passiert war.“

Zusammenhang: Shell-Accounts und Hosts, Webentwicklung 1996 und Software- und Tool-Alltag zeigen dieselbe Diagnosehaltung aus unterschiedlichen Perspektiven.

CGI ohne Browser reproduzierbar testen

Ein Skript kann in einer kontrollierten Shellumgebung mit denselben Kernvariablen und Eingabebytes getestet werden. Dadurch trennt man Parser- und Programmlogik vom Webserver.

Der Test muss mit derselben Interpreterversion, demselben Benutzerkontext, denselben Dateirechten und möglichst derselben Umgebung erfolgen. Ein Skript, das als eigener Shell-Benutzer funktioniert, kann unter dem Webserverkonto weiterhin an Rechten oder Pfaden scheitern.

Prüfreihenfolge

1. Syntax: Interpreter-Compilecheck ohne Requestdaten.
2. Header: erste Bytes der Ausgabe kontrollieren.
3. GET: einfacher bekannter Query-String.
4. POST: Body, Content-Type und exakte Bytezahl.
5. Grenzfälle: leere, doppelte, zu lange und ungültig codierte Werte.
6. Serverlauf: erst danach über reale URL und Logs prüfen.

Vertiefung: Unix und Linux im Alltag behandelt Shell- und Systemarbeit; Shell-Accounts und Hosts den historischen Hostkontext.

Frühe Sicherheitsprobleme und unzureichend abgesicherte Skripte

Frühes CGI war praktisch, brachte aber auch zahlreiche unzureichend abgesicherte Lösungen hervor. Gerade Mail-Skripte, Gästebücher, Suchmasken, Dateioperationen oder Shell-nahe Hilfsskripte wurden oft schnell geschrieben und schlecht abgesichert. Das war nicht nur ein historisches Qualitätsproblem. Ein CGI-Programm kann grundsätzlich mit allen Rechten des ausführenden Serverkontos auf Systemressourcen zugreifen, die dieses Konto erreichen darf.

Typische Probleme waren ungeprüfte Eingaben, blindes Durchreichen an Shell-Aufrufe, Header-Injection in Mail-Skripten, Dateipfade mit unzureichender Kontrolle, schreibbare Verzeichnisse ohne klare Trennung oder schlicht ein zu großes Vertrauen in das, was „der Benutzer schon nicht absichtlich falsch machen wird“.

• Serverseitige Eingabeprüfung: Syntax und fachliche Bedeutung möglichst früh und positiv gegen erwartete Formate prüfen.
• Shell-Nähe vermeiden: strukturierte APIs und argumentgetrennte Prozessaufrufe statt zusammengesetzter Kommandozeilen verwenden.
• Ausgabe codieren: fremde Texte niemals ungefiltert in HTML, Header, JavaScript oder Logs einbauen.
• Offene Formmail-Skripte: beliebige Empfänger und Header machten sie zu Spam-Werkzeugen.
• Rechte minimieren: Skripte und Daten mit dem kleinsten erforderlichen Benutzer- und Dateizugriff betreiben.
• Abhängigkeiten pflegen: Interpreter, Module und Webserver nicht als eingefrorene historische Insel öffentlich betreiben.

Genau deshalb blieb von dieser Zeit nicht nur Webromantik, sondern auch ein dauerhafter Reflex: lieber weniger Dynamik, wenn sie nicht wirklich gebraucht wird; lieber klare serverseitige Prüfung; lieber statische Auslieferung dort, wo keine Prozesslogik nötig ist. Die praktische Erfahrung mit CGI-Fehlern zeigte unmittelbar, dass zusätzliche Dynamik auch zusätzliche Angriffs- und Fehlerflächen erzeugt.

Vertiefung: Server-Härtung behandelt die serverseitige Schutzebene; SSL und Zertifikate die Transportverschlüsselung.

Typische Angriffsklassen eines CGI-Endpunkts

Zusammenhang: Die Angriffsklassen stehen nicht isoliert von Serverrechten und Netzwerkgrenzen. Dazu gehören Server-Härtung und Netzwerk und Heimvernetzung.

Größen-, Zeit- und Prozessgrenzen

Ein CGI-Skript muss nicht kompromittiert sein, um einen Server zu überlasten. Eine formal gültige Eingabe kann zu groß, zu langsam oder zu rechenintensiv sein.

• Request-Zeile und Header: serverseitige Längen- und Feldzahlgrenzen.
• Request-Body: Maximalgröße vor dem Einlesen und zusätzlich pro Feld beziehungsweise Upload.
• Request-Lesezeit: langsame Clients nicht unbegrenzt Ressourcen binden lassen.
• Skriptlaufzeit: externe Programme, Netzwerkzugriffe und Parser mit Timeouts versehen.
• Ausgabegröße: keine unbegrenzten Dumps oder Endlosschleifen in der Response.
• Parallelität: Prozesszahl, Warteschlangen und Dateisperren überwachen.

Limits gehören auf mehrere Ebenen: Webserver, Betriebssystem, CGI-Programm und gegebenenfalls nachgelagerter Dienst.

Warum Logdateien eine wichtige technische Schule waren

Ein wesentlicher Wert der frühen CGI-Praxis lag im Umgang mit Access- und Error-Logs. Sie machten Requests, Statuscodes, Pfade, Zeitpunkte und Fehlermeldungen direkt sichtbar und zwangen dazu, Symptome von nachweisbaren technischen Zuständen zu unterscheiden.

Dadurch entstand eine Arbeitsweise in Ereignisketten: Anfrage, Zuordnung, Prozessstart, Eingabe, Ausgabe, Status und Logeintrag. Statt einen Fehler als unspezifisches „Webproblem“ zu behandeln, ließ er sich einer bestimmten Schicht zuordnen.

Moderne Observability- und Entwicklungswerkzeuge können wesentlich mehr Kontext bereitstellen. Die grundlegende Haltung bleibt trotzdem gültig: Diagnose sollte sich auf überprüfbare Zustände stützen und nicht auf Vermutungen.

Zusammenhang: Diese Diagnosehaltung setzt sich in Webmaster-Arbeit seit 1996, der technischen Philosophie und Software- und Tool-Alltag fort.

Frühe CGI-Systeme nachvollziehbar archivieren

Ein altes Skript allein reicht nicht. Die Ausführung hing von Webserver, Interpreter, Modulen, Dateirechten, Verzeichnisstruktur, Mailtransport und Konfiguration ab.

• Quelltext: unverändertes Original und bereinigte Lesefassung getrennt sichern.
• Interpreter: Sprache, Version, Shebang und benötigte Module dokumentieren.
• Serverkonfiguration: ScriptAlias, Handler, Umgebungsvariablen, Benutzerkontext und relevante Limits erhalten.
• Dateibaum: Templates, Datendateien, Hilfsprogramme und erwartete Arbeitsverzeichnisse mit aufnehmen.
• Beispielrequests: GET-, POST- und Fehlerfälle als reproduzierbare Testdaten festhalten.
• Logs: nur notwendige Ausschnitte sichern und persönliche beziehungsweise geheime Daten vorher bereinigen.
• Mail und externe Dienste: historische Abhängigkeiten dokumentieren, aber beim Test nicht unkontrolliert real auslösen.
• Isolierte Rekonstruktion: alte Skripte in einer abgeschotteten Testumgebung statt direkt im öffentlichen Web untersuchen.

Vertiefung: Datensicherung und Backups behandelt den Erhalt technischer Datenbestände; Erste Webseiten 1995–1996 die frühe Veröffentlichungsumgebung.

Was von der CGI- und Logpraxis geblieben ist

CGI war weder in jedem Detail elegant noch für jede Lastsituation geeignet. Seine Stärke lag jedoch in der sichtbaren Kette zwischen Request, Prozessausführung und Antwort. Gerade dadurch eignete sich die Technik gut, um die beteiligten Systemschichten praktisch zu verstehen.

Webentwicklung wurde damit als Zusammenspiel von Protokoll, Prozess, Eingabe, Ausgabe, Rechten, Pfaden, Dateien, Nebenläufigkeit, Datenschutz und Fehleranalyse erfahrbar. Diese technische Transparenz erklärt einen Teil der späteren Vorliebe für statische, schlanke und nachvollziehbare Lösungen dort, wo keine serverseitige Dynamik benötigt wird.

Die Host- und Accountebene steht auf shell-accounts-und-hosts.htm. Die Entstehungszeit der frühen Webseiten wird auf erste-webseiten-1995-1996.htm dokumentiert. Der Webarbeitskontext von 1996 steht auf webdev-1996.htm; die langfristige Wartungsperspektive auf webmaster.htm.

Querverweise im SSLXY-Archiv

CGI und Logdateien liegen zwischen Webentwicklung, Hostbetrieb, Sicherheit, Datenschutz und langfristiger Wartung. Die bekannten Zielseiten sind bereits mit ihren endgültigen Dateinamen verknüpft, auch wenn einzelne Seiten erst im weiteren Neuaufbau überarbeitet werden.

• Startseite von sslxy.de
• Erste Webseiten 1995–1996
• Webentwicklung 1996
• Webmaster-Arbeit seit 1996
• Shell-Accounts und Hosts
• Server-Härtung
• SSL und Zertifikate
• Unix und Linux im Alltag
• Fernwartung und Remote-Zugriffe
• Netzwerk und Heimvernetzung
• Software- und Tool-Alltag
• Datensicherung und Backups
• Technische Philosophie
• Datenschutz auf sslxy.de