ScriptBlogger

In unserem News Script gibt es folgende Zeile:

$query = getenv('QUERY_STRING');

Auf dem Server des Kunden blieb $query jedoch leer. Die Ausgabe der Umgebungsvariable per echo funktionierte jedoch:

<?php echo getenv('QUERY_STRING'); ?>

Dank der Alternative $_SERVER['QUERY_STRING'] war das nicht weiter dramatisch. Merkwürdig ist es aber schon.

Wir wurden letztens mit der Installation des Comment Scripts beauftragt. Beim Aufruf der Seite kam mir diese recht bekannt vor. Kurz nach dem Namen gesucht und tatsächlich. Der Kunde hatte vor rund einem halben Jahr schon einmal den Installationsservice für dasselbe Script bestellt.

Nachdem ich das seinerzeit installierte Script erneut hochgeladen hatte, funktionierte das Script sofort wieder. Die Datenbanktabellen waren also noch da. Im Admin-Bereich wartete jedoch eine Überraschung: Über 8.000 Spam-Kommentare. Kein Wunder, dass der Kunde die Notbremse gezogen hatte.

Ein Blick in die Einstellungen zeigte allerdings, dass keine der Anti-Spam-Einstellungen aktiv waren. Kein Akismet, keine Wörter-Blacklist, keine IP-Blacklist.

Zwei Dinge lernen wir daraus. Erstens, ohne Spam-Blocker geht heutzutage gar nichts. Und zweitens, man sollte sich nicht darauf verlassen, dass der Kunde sich um solche Sachen kümmert. Bei den folgenden Installationsaufträgen machen wir die entsprechenden Einstellungen wohl am besten gleich mit. :-)

Finstere Gestalten treiben sich seit jeher auf unseren Kurz-URL-Seiten herum. Spammer, Phisher - das ganze Pack. Jetzt ist mal wieder einer völlig durchgedreht. Vor wenigen Wochen waren rund 20.000 URLs in der Datenbank. Kunden unseres Kurz-Url-Scripts hatten dasselbe Problem. Die Seite läuft schon eine Weile. Wenn's hoch kommt, kommen im Monat vielleicht 1.000 neue URLs hinzu.

Ein Blick in den Admin-Bereich der Seite zeigte jetzt, dass da einer Kurz-URLs ohne Ende produziert hat. Um das gesamte Ausmaß zu überblicken und in einem Rutsch zu entsorgen, haben wir mal einen Blick direkt auf die Datenbank geworfen:

SELECT *
FROM `twurl_url`
WHERE `url` LIKE '%redirectoffer%'
LIMIT 0 , 30

Und das Ergebnis:

Showing rows 0 - 29 (15,920 total, Query took 0.0534 sec)

Fast 16.000 URLs von dieser einen Domain. Das geht ja gar nicht. Ruckzuck alle Einträge gelöscht und die Domain auf die Blacklist gesetzt. Bis dann die nächste Domain dran ist.

Zwei Bugs haben es nötig gemacht, ein Update des Short URL Scripts zu veröffentlichen. Folgende Änderungen bringt es mit sich:

• Bugfix: Löschen einer URL mit dem Identifier 0 ist jetzt möglich (Admin-Bereich)
• Bugfix: Löschen der Suche ist jetzt möglich (Admin-Bereich)
• Nach dem Erstellen einer Kurz-URL wird ein Twitter-Link angezeigt

Es ist immer interessant zu lesen, was andere über die eigenen Produkte schreiben. In diesem Fall geht es um das Kurz-URL-Script und seinen Admin-Bereich:

This script will cost you $29, but it has a powerful back-end admin area and numerous robust features.

So etwas liest man natürlich gern, obwohl wir es sicherlich etwas zurückhaltender formuliert hätten. ;-)

Unsere Kunden haben nach neuen Funktionen gerufen und wir haben diese Rufe erhört. Folgende neue Funktionen hat unser Short URL Script ab heute:

• Einfache API mit welcher extern auf das Script zugegriffen und kurze URLs generiert werden können
• Twitter-Bookmarklet, das die kurze URL direkt zu Twitter weiterleitet
• URL-Längenstatistik: sagt nach dem erstellen der kurzen URL wie lang die ursprüngliche URL war und wie lang die neue URL ist
• Der Schrägstrich am Ende fällt jetzt standardmäßig weg

Außerdem gibt's seit Neuestem auch einen zusätzlichen Satz Templates für das Script.

Seit zwei Monaten liegen übrigens die Verkaufszahlen für das Short URL Script weit über dem Normalen. Wir haben noch nicht herausgefunden woran das liegt, von der generellen Attraktivität des Scripts mal abgesehen. ;-) Sobald wir mehr wissen, melden wir es hier. :-)

Nachdem unser Kurz-URL-Script schon mehrere Jahre auf dem Markt ist und noch nie durch Performance-Probleme aufgefallen ist, zickt jetzt ein Webspace-Provider herum.

This script will perform just fine when there is no load on the server, but at average load you script will run poorly.

Unser Kunde wies seinen Provider darauf hin, dass seine Website kaum Besucher hat und er es für unwahrscheinlich hält, dass das Script für die Probleme verantwortlich ist. Der Webhost legt dann mit folgender Erklärung nach:

The server load is not made up only upon your site alone, but there is many sites on the same server. Some receive more hits than others. Even though your site only may receive a few hits a day, other sites my get a 1000 hits or more. The server load is affected by all sites on the server. When the server is on a normal load amount, it seems your site gets slowed down because of the script.

Zur Erinnerung. Wir sprechen hier von einem Script mit zwei Datenbanktabellen. Eine davon mit höchstens ein paar Tausend Datensätzen, die andere mit rund 20. Beim Abruf einer URL wird per ID gesucht, für die ein Index existiert.

Unser Kunde hält die Aussagen der Webspace-Firma für fragwürdig:

There is simply as a condition that is not acceptable on any internet site. I don't believe for one moment that the short URL script is the cause of the slow loading at various times.
Further I will test the site with normal long URL's and see if there is any difference. I have used Hosts for too long to buy your explanation.

Yep, wir ebenso wenig. Es gibt allerdings einen Umstand, der dem Server tatsächlich zusetzen würde und bei unseren eigenen Seiten (flaturl.com, gentleurl.net) auch tatsächlich zu Problemen geführt hat. Wenn nämlich die URLs zu Bilddateien mit Hilfe des Schort URL Script gekürzt und dann in eine Seite eingebaut wurde. In der Vergangenheit wurden diese URLs in chinesischen Foren mit hohem Besucheraufkommen oder in den Kommentaren von MySpace-Profilen eingebaut wurden. Das bedeutet, dass bei jedem Aufruf der MySpace- oder Forums-Seite auch gleichzeitig ein Aufruf zu unserer Seite gemacht wurde. Bei mehreren Requests pro Sekunde über einen längeren Zeitraum fing der Server dann an zu ächzen. Seit wir aber entsprechende Seiten per .httaccess blockieren, ist auch das kein Problem mehr.

Bei unseren Seiten flaturl.com und gentleurl.net sind derzeit zusammen knapp 40.000 URLs in den Datenbanken. Seit Beginn wurden über 10. Mio Aufrufe gezählt und täglich kommen rund 3.000 dazu, mit Spitzen von 8.000 Aufrufen. Das sind sicherlich keine rekordverdächtigen Zahlen, aber genug um zu zeigen, dass eine normale Nutzung des Scripts nicht gleich den gesamten Server aus der Puste bringt.

Unser News Script ist gar nicht mal so schlecht. Verglichen mit Wordpress und Serendipity fehlen aber noch ein paar (OK, eine Menge) Funktionen. Einen Kunden von uns ficht das nicht an:

I have WP and I really don't care for them and to me your news script is a lot better than anything out there.

Es hat sich herausgestellt, dass es entgegen früheren Erkenntnissen doch eine Sicherheitslücke in zweien unserer Scripte gab, die Cross Site Scripting erlaubte. Das Problem war $_SERVER['PHP_SELF'], das nicht genügend auf eingeschleusten JavaScript-Code geprüft worden war. Dadurch wäre es einem Angreifer zum Beispiel möglich, Zugriff auf die Session-Cookies eines Benutzers zu erlangen.

Betroffen hat es das Form Mail Script und das Voting Script. Für beide Scripte gab's natürlich sofort Updates und für den Hinweisgeber eine kostenlose Script-Lizenz.

Dass Nutzer eine bestimmte Funktion im Script nicht finden können, ist Alltag. Dass der Entwickler die Funktion nicht findet, passiert eher selten. Und doch ist es geschehen, wie folgender Forums-Dialog beweist:

Nutzer 1: I can't seem to find the config section that makes filling in an email address compulsory.

Entwickler: You mean in the admin area?

Nutzer 1: For when making a booking or registering a user [...]

Nutzer 2: i cant remember for sure but im sure this is in one of the config files

Entwickler: The e-mail fields in the admin area are not required and there is no option to change that, I'm afraid.

Nutzer 1: How about for when a new user is registering an appointment?

Entwickler: In the user front end the e-mail field is compulsory. Only in the admin area it is not.

Nutzer 2: $configuration['customer_email_required'] = true; in core.inc.php

Entwickler: Are you sure?

Nutzer 2: no im not :-( it was there before though

Entwickler: I thought so, too, first but I couldn't find it. Weird.

Nutzer 1: Not finding it eigther

Es kann kein gutes Zeichen sein, wenn Entwickler und Nutzer davon überzeugt sind, dass es eine bestimmte Funktion gäbe, diese tatsächlich aber gar nicht da ist. Halluzinationen? Gespenster? Verhexte Scripte?

Letztens im Forum:

I need my site to be PCI compliant. McAfee Secure (which used to be ScanAlert) is showing errors in index.php due to cross-site scripting.

PCI compliancy hat was mit Kreditkartendaten zu tun, die übers Web versendet werden.

Ich bin aus zwei Gründen extrem skeptisch. Erstens, ich traue automatischen Scannern nicht. Und zweitens, das Script wäre schon vor Ewigkeiten in Mailing-Listen wie Secunia oder Bugtraq erwähnt worden, gäbe es tatsächlich eine Sicherheitslücke.

Jeder kann es selbst ausprobieren. Keine der Fallbeispiele auf folgender Seite schlagen an:

http://ha.ckers.org/xss.html

Im Endeffekt ist es ganz einfach. Solange keine konkreten Hinweise kommen, können wir nichts tun. Mit vagen Aussagen kann man wenig anfangen. Sollte sich aber tatsächlich eine Sicherheitslücke finden, ist diese in Null Komma Nichts behoben. Aber bis dahin halten wir die Füße still und hoffen, dass andere Nutzer sich nicht verunsichern lassen.

Wenn ein Kunde Probleme mit seinem Script hat und die ersten ein oder zwei Tipps nicht helfen, gibt's nur eine Möglichkeit: FTP-Zugangsdaten anfordern. Das ist aber nicht immer möglich. Meist aus folgenden Gründen:

1. Der Server steht lokal beim Kunden und ist per Internet nicht zu erreichen.
2. Der Kunde testet das Script auf einem lokalen Rechner, bevor er es endgültig auf dem Server installiert.
3. Zugang zum Server ist an eine oder mehrere IP-Adressen gebunden.
4. Der Kunde möchte nicht, dass Dritte Zugang zum Server haben.
5. Der Auftraggeber des Kunden möchte nicht, dass Dritte Zugang zum Server haben, obwohl der Kunde die Daten eigentlich gern herausrücken würde.

Im Fall 1 kann man sich schon mal auf einen Schwung E-Mails einstellen, die hin und her gehen werden. Kein Argument der Welt wird das ändern können.

Im zweiten Fall hat es bisher immer geholfen, den Kunden zu bitten, das Script direkt auf dem Server zu installieren. Im Großteil der Fälle hat sich damit auch gleich das Problem gelöst. Wir haben es schon oft erlebt, dass irgendetwas mit dem lokalen System des Kunden nicht funktionierte.

Im Fall 3 kann man Glück haben und der Kunde gibt die IP, die man gerade benutzt, für den Zugriff frei. Blöd ist allerdings, wenn sich der Support über mehrere Tage zieht und der Provider einem täglich eine neue IP-Adresse zuweist.

Für die Fälle 4 und 5 gibt es einige Argumente, die fast immer ziehen.

• Man versichert, dass der Zugang zu Kunden-Servern absolute Routine ist und dass man das schon bei Hunderten Kunden gemacht hat.
• Der Kunde soll den Zugang auf das Verzeichnis beschränken, in dem das Script liegt.
• Ohne Zugang wird es Tage dauern, bis das Problem behoben ist. Instruktionen und aktualisierte Dateien per E-Mail hin- und herzusenden ist zu zeitraubend.
• Support dieser Art muss man, auf Grund des Zeitaufwands, extra in Rechnung stellen.

Vermutlich ist es der letzte Punkt, der den Ausschlag gibt. Schade eigentlich, da wir ungern mit der Kostenkeule wedeln. Support ist eigentlich im Script-Preis enthalten und die Kunden sollen sich nicht abgezockt fühlen.

Ein Script von uns funktionierte auf dem Server des Kunden nicht ganz korrekt. Es sollte E-Mails versenden, tat es aber nicht. Ein kurzer Blick in die Kristallkugel ergab, das womöglich der safe_mode daran schuld ist. Die Kristallkugel sollte recht behalten.

Seit einer Weile schreiben einige Webspace-Provider vor, dass man bei Scripten die Return-path-Kopfzeile angibt. Das macht man mit Hilfe des fünften Parameters der Funktion mail(). Ist auch nicht weiter wild. Unsere Scripte können damit umgehen.

mail(
    'empfaenger@example.com',
    'Betreff',
    'Nachricht',    
    'From: absender@example.com',
    '-fwebmaster@example.com'
    );

Ist aber der safe_mode aktiviert, ist der fünfte Parameter nicht erlaubt. Ergo werden auch keine E-Mails versendet. Das ist kein Problem, denn das Script verzichtet im safe_mode automatisch auf den fünften Parameter.

Leider hatte der Kunde noch eine Version des Scripts, in der diese Funktion fehlte. Man hätte jetzt ein Update machen können, aber der Kunde entschied kurzerhand, den safe_mode abzuschalten. Um so besser. Leider haben nur die wenigsten Anwender diese Möglichkeit.

Jetzt fing aber die Sache erst an, spannend zu werden. Den Pfad der php.ini hat der Kunde noch relativ zügig herausgefunden. Trotz Änderung und Neustart des Apache blieb jedoch der safe_mode eingeschaltet. Wenig hilfreich war auch die Tatsache, dass es mehrere php.ini an verschiedenen Orten auf dem Server gab.

Schlussendlich ließ sich die Einstellung in der Konfiguration der virtuellen Hosts finden:

/srv/www/vhosts/beispiel-domain/conf/httpd.include

Da wollte anscheinend jemand mit aller Macht sicherstellen, dass auf dem Server der safe_mode aktiviert bleibt. :-P

Kontaktformulare sind in erster Linie nützlich für Leute, die gerade kein E-Mail-Programm zur Hand haben, wenn sie Kontakt mit Website-Betreibern aufnehmen wollen. Für den Betreiber haben Formulare jedoch einen entscheidenden Nachteil. Statt, dass das E-Mail-Programm des Kontaktsuchenden die E-Mail-Adresse automatisch als Absender einträgt, muss sie händisch eingetippt werden.

Das ist nicht immer von Erfolg gekrönt und wenn Leute ihre E-Mail-Adresse falsch eintippen, heißt das Detektivarbeit für den Empfänger. Vorausgesetzt er hat den Willen zu antworten. Dann wird nach Buchstabendrehern Ausschau gehalten, Suchmaschinen bemüht, etc.

Für den Fall, dass die Suche nichts bringt, heben wir zum Beispiel immer den Rückläufer auf. Der Fragesteller könnte sich ja noch mal melden und sich beschweren, dass er keine Antwort bekommen hat. In solch einer Situation hätten wir dann wenigstens einen Beweis.

Eine Lösung wäre vermutlich, den Formularausfüller die E-Mail zweimal eintragen zu lassen und dann Script-seitig überprüfen, ob beide Felder den gleichen Wert enthalten. Nachteil: Manch einer könnte den Mehraufwand scheuen und wieder verschwinden, ohne das Formular zu Ende auszufüllen.

Wie man's also dreht und wendet, Einschränkungen wird es wohl immer geben. Oder fällt jemandem etwas besseres ein?

Vor einer Weile haben wir berichtet, dass unser Wegwerf-E-Mail-Script mit dem Herunterladen von ein paar tausend E-Mails kein Problem hatte.

Das war allerdings noch gar nichts gegen das, was wir kürzlich gesehen haben. Auf Grund technischer Probleme auf Seiten des Web-Hosters eines Kunden konnten die E-Mails einen ganzen Monat lang nicht abgerufen werden; über 80.000 hatten sich in dem Mail-Account aufgestaut. Wir können stolz berichten, dass auch das kein Problem für das Script war. :-D