No Tainted Love...

[Patrick Andrieu]

Hallo Alexander!

Perl-Version: 5.006001

Ui! Mottenkiste! Das wurde am 8. April 2001 (zweitausendundeins) released.

Jepp. Zu Hause habe ich 5.8.7 (Active State, da Windows-PC)...
Aber im Vergleich zum vorigen Hoster ist es schon ein Fortschritt. Dort (war: Communitech.net, Kansas, USA) war noch 5.5 wenn nicht älter. Außerdem ist der Rechner bei 1&1 schneller, die Speicherzuweisung anscheinend höher: Vieles »flutscht« nur noch, was beim alten Hoster manchmal richtig Zeit in Anspruch nahm.

[Klammer auf: Übrigens habt Ihr (Du, Struppi und Siechfred) mir den Ansporn geliefert, dass ich meine Kenntnisse nun vertiefe. Allerdings scheinen in »Programmieren mit Perl« einige Sachen veraltet zu sein, dort wird z.B. den Einsatz von Pseudohashes gelobt, was mir beim Testen eine Warnung brachte, dass diese nun »deprecated« seien... Außerdem gibt es Vieles, was ich nicht verstehe, aber das hat weniger mit Perl an sich zu tun als vielmehr damit, dass mir die Grundlagen fehlen, was die Vorgänge innerhalb des Computers angeht usw. Aber egal, schon viel gelernt, viele Ideen, was ich anders machen kann - und die Kapitel, die meinen Kopf zu rauchen bringen, kann ich später noch einmal lesen ;) :Klammer zu]

Apache/1.3.33 (Unix) auf Debian-Linux.
"Da sprach der alte Häuptling der Indianer ..." ;-)

Ja, allerdings scheint der alte Häuptling bei Webhostern noch weit verbreitet zu sein ;)
Für die lokale Umgebung arbeite ich noch mit dem Xitami (nicht lachen, der reicht mir noch vollkommen aus und man lernt, Umgebungsvariablen zu kennen!).

Im 1&1-Controlcenter gibt es zwei Utilities "Perl-Syntax-Checker"

Danke, sehr guter Tipp. Hier das Ergebnis von »tainted_test.pl" ohne -T:

Ergebnis:+ Check succeeded
    /../../../../../tainted_test.pl syntax OK
    STDOUT OK STDERR OK

und hier mit -T:

Ergebnis:- cgi: File has no correct script header
    (should be #! /usr/bin/perl)
    (no output)

Das würde bedeuten, dass es mir bei 1&1 nicht möglich ist, Taintchecks vorzunehmen und also doppelte Vorsicht bei Scripts walten lassen muss, die Eingaben von außen bearbeiten? Auf dem Xitami läuft das Script in beiden Varianten, ich könnte solche Programme also zunächst lokal testen. Außerdem läuft es auch auf der Konsole: perl -T tainted_test.pl

und "CGI-Ausgabe-Monitor", vielleicht helfen die Dir weiter. Letzterer sieht vielversprechend aus,

Hm, hier wird keine Variante bemägelt, beide gehen durch. Ich nehme an, dass das Feld "Parameter" für die Angabe eines Query Strings gedacht ist? Jedenfalls brachte hier ein -T auch keine Änderung an den Ergebnissen:

Ergebnis:+ CGI Check succeeded
    Content-Type: text/html; charset=ISO-8859-1

Tainted love!
    STDOUT OK STDERR OK

ich will jetzt aber nicht auf dem Firmenwebseiten meines Arbeitgebers rumtesten.

Sind dessen Seiten bei 1&1?

mod_perl aktiv?
Wie kann ich das überprüfen?
$ENV{'MOD_PERL'} existiert,

Ausgabe ist leer.

Im 1&1 CC einen ssh-Zugang aktivieren und perl -V ausführen.

Das überprüfe ich später im Laufe des Tages.

Was 1&1 da bloß gebastelt hat...
Irgendwelche bösen Spielchen mit redirect finden bei CGI-Aufrufen übrigens auch noch statt.

Hm ja... Zu Beginn (ich bin erst seit März dort gehostet) konnte ich keine eigene 500er-Seite generiereren lassen, trotz entsprechender Angabe in der .htaccess. Erst ein mehrmaliges Schriftwechsel mit dem Support, mehrmalig deswegen, weil der den Ticket-bearbeitende Mitarbeiter am Ende seines Wissens war und »höher« nachfragen musste, erhielt ich den Tipp, dass ich im jeweiligen Heimverzeichnis meiner Domains je eine error500.html genannte Datei ablegen musste (dann geht es auch ohne Eintrag in der .htaccess, sehr seltsam). Koscher ist die Sache immer noch nicht, denn ich sehe _nie_ den Status 500 in den Logs! Jedes kaputte Script, das die Ausgabe eines 500er Errors verursacht (die Error-Seite wird ausgeliefert), erscheint in den Logs mit einem schönen 200er. Also wird sehr wohl intern da herumgefriemelt, denke ich mal.

Viele Grüße aus Frankfurt/Main,
Patrick