ScriptBlogger

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?

Was PHP-Scripte mit Kuchen zu tun haben? Frage eines Kunden im Support-Forum:

Exporting to multiple Google Calendars would be the icing on the cake as this can be configured for SMS alerting, etc.

Unsere Antwort:

No icing, I'm afraid. Just the bare cake. ;-)

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.

Letztens haben wir von überängstlichen Webspace-Providern berichtet. Heute hatten haben wir das andere Extrem.

Für eine Kundin sollten wir ein Script installieren und benötigten dafür eine MySQL-Datenbank. Zunächst fehlten die Zugangsdaten, weshalb wir die Kundin baten, sich mit ihrem Webspace-Provider in Verbindung zu setzen. Als Antwort kam eine URL in folgender Art:

http://www.example.com/cpanel/phpmyadmin/

Das wird uns nicht viel nützen, dachten wir uns, denn bei keinem Webhoster kann man über phpMyAdmin Datenbanken erstellen. Das läuft üblicherweise über das Control-Panel des jeweiligen Webspace-Kontos.

Weit gefehlt. Wir hatten tatsächlich root-Zugriff auf den MySQL-Server. Haben wir also das gemacht, was wir schon lange nicht mehr getan haben: Nämlich Datenbank und Benutzer direkt über die Konfigurationsdatenbank von MySQL erstellt. War auch mal wieder schön. ;-)

Gestern fragte ein Interessent an, ob er denn Rabatt bekäme, wenn er gleich sechs unserer Scripte auf einmal kaufte. Der volle Preis wäre ihm zu teuer. Na klar, sagten wir und boten ihm 30% Nachlass an. Statt der 174 US-Dollar wären dass (rund) 120 US-Dollar gewesen.

Das war ihm noch zu teuer, weswegen er nur noch drei Scripte wollte. Für 50 US-Dollar. Nun ja. Eigentlich ist es doch so, dass man um so mehr Rabatt gibt, je mehr der Kunde ordert, oder? Der Mensch aber wollte mehr Rabatt für weniger Scripte haben. War ihm vielleicht gar nicht bewusst.

Auf unser Gegenangebot, die 30% für die sechs Scripte auch für die drei Scripte zu gewähren, ging der - mittlerweile - Kunde dann ein.

Manchmal kommt man sich wirklich vor, wie auf einem Basar. ;-)

Wiederkehrende Kunden werden bei uns üblicherweise bevorzugt behandelt. Leider war in der letzten Woche die Zeit recht knapp, so dass die Fertigstellung eines Auftrags einige Tage auf sich warten ließ. Zu recht hakte der Kunde nach:

Falls die Verzögerung lediglich aus irgendwelchen Umständen ihrerseits resultiert: Kein Problem, es gibt ja keine Deadline.

Ich bitte Sie in diesem Fall höflich um einige Baldrian-Tropfen in Form eines kurzen mails.

:-)

Jeder hat sein Päckchen zu tragen, so scheint's. Vor einer Weile hatte jemand unseren Installationsservice bestellt, aber auf den Fragebogen nicht geantwortet. Tage darauf kam dann folgendes Schreiben (sinngemäß wiedergeben):

Wir haben vor einigen Wochen die Lizenz für Ihre Softwarelösung erworben. Leider haben Sie den Fragebogen immer noch nicht erhalten, da unser Webdesigner die Zugangsdaten nicht rausrückt. Nach erneuter Anfrage meinerseits wie diese Verzögerung zustande kommt hat er mich darüber Informiert, das er ebenfalls in der Lage wäre die Applikation nach unseren Wünschen zu installieren.

Deshalb meine Frage: Wäre es möglich den Installationsservice nicht in Anspruch zu nehmen und nur die Lizenz zu erwerben? Ich habe natürlich schon alles bezahlt. Nur um den Hausfrieden wieder herzustellen.

Ist ja schlimmer als bei Kleinkindern. :-(

Wenn Anwender einen Fehler machen, kommt's mitunter vor, dass sie extreme Demut zeigen. Ein Beispiel. :-)

Yes, I'm an idiot. I'll crawl back to my corner now. :-D Thanks!

Schrieb letztens ein Kunde, dass er sein Problem gelöst hatte, und:

Everything is working great now. :)

Thanks a bunch! this was the best $29 I have spent in a long time.

:-)

Da ist aber jemand wütend. Und blind, vor allen Dingen. Neulich kam mal wieder was über dieses Kontaktformular.

Sehr geehrte Damen und Herren,

am XX.XX.2008 habe ich mich über eine Mitarbeiterin Frau Xxxxxxxx beschwert. Dieses Schreiben wurde mehrmals gefaxt und ich habe darauf überhaupt noch keine Antwort erhalten.

Mit freundlichen Grüßen

Yyyyyy Zzzzzzz

Ich hatte für einen Kunden eine spezielle Funktion eingebaut. Der Kunde scheint zufrieden damit zu sein.

too good at what you do... hats off to you Ralf!

too bad I can't send you a box of chocolates :-)

Ein Nutzer hatte Fragen zur Kodierung der Website-Inhalte. Nach der Umstellung auf UTF-8 wurde der Text nicht mehr korrekt dargestellt. Auf diesen Umstand wies der Nutzer hin:

The text in the page is in Hebrew, in case you wonder... Look at the comments and see the weird characters (although Hebrew is also weird characters, this is not Hebrew in the comments :-D )

:-D

Damit durch die eher negativen Berichte in der Vergangenheit keine Missverständnisse aufkommen; die meisten unserer Kunden sind nett zu uns. :-) Zum Beispiel:

You've been very patient with my inexperience. Thank you for that. You've gone above and beyond the call of duty.

Oder auch:

By the way, your script is really great, thank you!