In diesem Code wird auf die Onlinebanking Software Hibiscus mittels der dortigen XML-RPC Schnittstelle zugegriffen. Dafür wird die Bibliothek XML-RPC for PHP verwendet. Natürlich ist der Quellcode mitlerweile veraltet. Auch ist er nicht mit der aktuellen Hibiscus Version getestet. Und die Bibliothek ist sicherlich auch weiter gepflegt worden. Und so kann es passieren, dass beim Beispielcode Fehler beim Anlegen von Überweisungen auftreten. Doch wie damit umgehen?

Dies hat wohl dazu geführt das viele Leute die hier den Beitrag gelesen haben und sich den Quellcode gezogen haben sich nicht an mich direkt als Autor sondern an den Autor von Hibiscus gewandt. Auch in den Kommentaren ist nicht viel zu finden. So habe ich erst seit einigen Tagen die Gelegenheit mich mit dem Problem zu beschäftigen.

Leider muss ich anfügen. Nun kann wohl Hibiscus selber am wenigsten was dafür, wenn die in PHP eingesetzte XML-RPC Bibliothek einen Fehler hat. Sie kann wohl offensichtlich nicht mit Namespaces umgehen, die RPC-Response enthält aber solche. Das zeigt die Antwort auch an, es handelt sich um die XML-RPC implementierung von Apache. Es kann also zu einem Fehler kommen. Und dafür ist der Autor von Hibiscus nicht der naheliegenste Ansprechpartner. Wenn man Beispielcode nimmt, dann sollte man diesen als praktische Gelegenheit begreifen, ihn zu lesen und zu verstehen. Dazu gehört auch der Umgang mit Fehlern darin. Eigentlich sogar ein willkommener Anlass solch ein Fehler, stellt er doch quasi eine Prüfung dar, ob man verstanden hat wie es funktioniert, wenn man den Fehler löst. Ein einfaches Copy and Paste gibt einem diese Sicherheit nicht, sondern lässt einen in dem trügerischen Gefühl, ein schnelles Ergebnis erzielt zu haben. Dabei entzieht sich dieses Ergebnis der vollen eigenen Kontrolle.

Aber was tun? Da es sich bei allen Komponenten um quelloffene, Freie Software handelt drängen sich zwei Lösungen auf: Eine konkrete, der Fix oder Workaround, und eine strategischere, das Feature. Der Produzent sollte natürlich auch eingebunden sein, allerdings rate ich sehr dazu, Entwickler in freien Projekten nicht mit unausgegorenen Emails zu belästigen. Das stellt man am besten dadurch sicher, erstmal selber zu schauen, was der Auslöser des Fehlers ist. Vielleicht liegt der ja auch bei einem selber. Und was auch nervig ist: Wenn ein Benutzer einfach mal eine Mail an alle Adressen schickt die er hier oder da findet und meint: das könnte schon passen, was kümmerts mich, wenn ich andere für mich denken lassen kann.

Eine Entwicklerin, die auf einen Fehler stösst, fängt automatisch an, ihn zu analysieren.

Eine Entwicklerin, die auf einen Fehler stösst, fängt automatisch an, ihn zu analysieren. Ist die Fehlerursache bekannt, so kann sie gefixt werden. Dazu muss man meist sogar nur wenig Ahnung haben, was ein Programm da gerade macht. Ein komplettes Verständnis aller Komponenten und Hintergründe ist sicherlich hilfreich aber nicht zwingend. Heraus kommt dann ein Workaround evtl. wie dieser hier:

Das wäre also ein Fix oder Workaround. Wie alles sind natürlich auch Fehler relativ. Konkret ist mit einem Workaround also geholfen. Und zwar schnell und einfach. Steht es hingegen an, sich um den Kern des Problems zu kümmern, so ist ein wenig mehr Arbeit und Genauigkeit von Nöten. Hier ist der Fix aber nicht umsonst, hat er doch geholfen, den Fehler einzugrenzen und die Funktionsfähigkeit wieder herzustellen.

So stellt sich erstmal die Frage warum genau der Fehler zu Tage tritt und warum der Fix nun funktioniert. Die Eingrenzung des Fehlers auf seine ausschlaggebende Ursache. Bei diesem Beispiel ist es relativ einfach mit der Fehlerursache. Auch das Protokoll von XML-RPC ist relativ offen, den es basiert auf (recht einfachen) XML Dokumenten, die per HTTP ausgetauscht werden. So ist zum debuggen mittels PHP das XML der Antwort einsehbar indem der String ausgegeben wird:

Der Fehler tritt hier auf, weil die PHP XML-RPC Bibliothek nichts mit dem Rückgabewert “<ex:nil/>” anfangen kann. Nun stellt sich die Frage, wie damit umgehen? Wo genau liegt der Fehler, in der PHP-Bibliothek oder in der Implementierung in der Java-Bibliothek von Apache? Wenns um Bibliotheken geht ist das oft ein Zeichen dafür, dass es sich hier um eine grundlegendere Frage handelt. Und das eine Lösung aufwendiger und auch problematischer sein kann. Dies aus zwei Gründen:

Zum einen werden Bibliotheken von vielen Programiererinnen und Anwendern in unterschiedlichen Anwendungen genutzt dessen allen Bedürfnisse eine Bibliothek unter einen Hut bekommen muss. Eine “Fehlerbehebung” die zu nicht erwartenen Ergebnissen führt kann zum Beispiel bestehende Anwendungen gefährden.

Zum anderen, weil wenn ein Fehler gefunden wird, ein Fehlerbericht an das Projekt der Bibliothek gemacht werden sollte. Dazu muss erstmal rausgefunden werden, wie dies gemacht wird und es ist oft nicht klar, wie schnell ein Fehler im Projekt behoben wird, nachdem er gemeldet wird.

Mein Code, Dein Code, unser Code.

In der Programmierung spricht man hier oft vom “Upstream”. Ich erstelle für die lokale Kopie meiner Bibliothek einen Patch, der das gewünschte Feature implementiert. Das Feature für die PHP-Bibliothek ausführlich formuliert wäre hier: Die Unterstützung des ex:nil Rückgabewertes zwecks Kompabilität zur Apache XML-RPC Implementierung.

Läuft der Patch bei mir und bin ich sicher, dass das auch für andere AnwenderInnen der Bibliothek Sinn macht, upstreame ich den Patch, in dem ich den dem Bibliotheksprojekt zur Verfügung stelle. Meist wird darüber diskutiert was für und was gegen den Patch spricht und der Patch entsprechend modifziert resp. erweitert. Wird der Patch akzeptiert, landet er meist im nächsten Release des Projektes.

Keep Up the Upstream.

Damit ist dann allen geholfen. Übrigens sind viele Entwicklerinnen dann für Feedback dankbar, wenn es um eine reale Fehlerlösung geht. So hat der Entwickler im Hibiscus Projekt sicherlich kein Interesse daran, PHP-Programmierern bei der Fehlersuche zu helfen, selbst wenn er ein ganz lieber ist und es mit den Anfragen auch generell recht freundlich hält. Hätte die Schnittstelle auf seiner Seite einen Fehler würden sich warscheinlich schon recht viele Leute beschwert haben… . Das XML-RPC for PHP Projekt hingegen hat aber vielleicht ein echtes Interesse daran, die Bibliothek kompatibel mit der Apache Implementierung zu halten. Jeder Fehler ist eine Chance ein Programm zu verbessern. Keep Up the Upstream.

ESAPI definiert Sicherheitsmaßnahmen, die eine Webanwendungen gegen typische Angriffe wie Cross-Site-Scripting und SQL-Injection schützen.

Ein erster Termin ist mit Mai 2009 angegeben. Dabei handelt es sich um eine Portierung der JAVA Referenzimplementierung. Mehr Infos auch im Blog von Andrew van der Stock.

Worum geht’s? Um – mal auf gut deutsch gesagt – Informationslecks, also Infos die nun eben nicht nach Draussen drängen sollten, egal welcher Art noch Natur. Info. Data. Zeugs. Das Problem ist einfach umrissen: Wie soll sich Jemand, hier vornehm genannt Normalo von User, mit so etwas technisch-komplexen wie Computersystemen und Informatios-Technik auseinandersetzen? Gute Frage, nächste Frage. Firefox Installieren, das Noscript Plugin schleunigst nachladen (oder wie hochrangige Mozilla Entwicklerinnen sagen: “Ich würde mir wünschen, Firefox würde mit Noscript ausgeliefert werden”) und einfach ALLE Freunde, die einem bei Computer Problemen helfen wollen, im Mindesten dazu “nötigen”, selber Firefox und das Noscript Addon zu installieren, bevor Sie überhaupt auf _eigene_ Probleme eingehen.

Denn die beste Sicherheit ist es, erstmal nur ohne aktive Scripts / Javascripts und gefährliche Plugins durchs Netz surfen. Ich würde fast drauf wetten, das sich die Installation von Noscript mehr lohnt als die Installation eines Virenscanners. Auf ein Mal erscheinen Fragen wie “Warum geht Youtube nicht?” in einem ganz anderen Licht, und der Anfänger begreift schnell, das sich sein Intellekt nicht von dem eines studierten Informatikers zu unterscheiden braucht.

Wegen des guten Konzeptes und der einfachen Integration bekommt der Autor der wünschenswerter Weise sehr erfolgreichen Erweiterung (Plug-In / Add-On) Noscript beste Kritiken von Fachpresse als auch eben dem Normalo. Sowohl von Benutzer- als auch Sicherheitsts-technischen Seite. Es ist kein Zufall das der talentierte italienische Entwickler – im Übrigen propagiert er offensiv und stetig Freie Software – zwei in der Computerwissenschaft extrem wichtige Komponenten zusammen bringt. Noscript gibt es es leider nur für den Mozilla Firefox und für den HTML Webautor. Und genau deswegen zeigt es, warum der Firefox funktioniert und das Thema so wichtig ist. Die Daten auf dem eigenen Rechner sind irgendwo doch auch einfach zu wichtig um Sie mit Hinz, Kunz und Eben zu teilen. Und genau dort hilft Noscript ein bischen.

At the academy, hacker mentors lead the youngsters away from gaming sites and focus on IT challenges, rewarding their progress with rank and recognition. While keeping the kids off the cyber streets, they are simultaneously creating future mentors and potential hackers. I like the focus on moral and ethical aspects which are vital to the IT education of kids who have regular access to cyberspace.

At the same time Hackerteen also addresses the less tech savvy users and educates them about Internet related security risks such as social networking. The comic has links to the live site which makes it more interactive and forges the hybrid online and offline concept. Behind the project is 4linux with a real academy which offers real courses for real Hackerteens. The first class has already graduated. Personally I’d like to know more about the courses and possibilities of integrating them into an existing IT curriculum, I think this could easily compete with the logo turtles and be of more use.

As a parent I like the idea too, I think the next generation of viruses will breed in school yards not at the office and while I’m still struggling to get a firewall working on my sons mobile device, he has less problem getting round my parent proxy at home. This addresses the third and final target audience in my eyes, the less tech savvy parents who need an easy way to learn what the mumbo-jumbo means that the kids bring home.

While the comic is slightly out of the comic price range and the graphics themselves have room for improvement, I still think it’s worth buying for someone in one of the potential target groups. On the whole, projects like Hackerteen promote a healthy Internet culture while introducing modern concepts such as sustainable software and in doing so, help bridge IT and generation divides using the Internet as a common denominator. I think this is a great idea and look forward to the next episode.

Folien und Beispielcode

• Creational Patterns and the Registry Design Pattern (PDF 69k)
• Beispielcode und Notizen

Auf dem Usergruppen Treffen am 13. März 2008 habe ich einen Stand-Up-Vortrag über das Extenden von SimpleXML gehalten den ich nun mit diesem Beitrag auf unserer Homepage nachbereiten und erweitern möchte. Einfache eigene Erfahrungen mit SimpleXML sind von Vorteil zum Verständnis des Artikels.

Die Möglichkeiten

SimpleXML ist schon von Hause aus sehr simpel. Es sollte immer die aktuelle Version eingesetzt werden, da in der Geschichte dieser Erweiterung es manchmal verschiedene Interpretationen über einzelne Methoden gab, so das zwischen Bugs und Documentation Problems schon mal ein Bäumchen-Wechsel-Dich-Spielchen entstehen konnte. Dies und andere Kinderkrankheiten sind aber mitlerweile aus dem Weg geräumt und sie fallen auch nicht soviel ins Gewicht, wenn man sich die Fähigkeiten von OOP unter PHP zu Nutze macht:

1. SimpleXMLElement Extenden (Vererben)
2. SimpleXMLIterator: Der SPL-Iterator auf SimpleXML

Anm.: Den ersten Punkt habe ich auf dem Märztreffen angesprochen, der zweite Punkt wird auch nochmal auf dem Apriltreffen gezeigt, ist aber im Grunde das selbe, da es sich auch um das Extenden vom SimpleXMLElement handelt. Da der SPL Iterator so ein anschauliches Beispiel ist, habe ich ihn in die Thematik mit rein genommen.

SimpleXML Extenden (Vererben)

Das Vererben eines SimpleXMLElement funktioniert wie das Vererben jeder anderen PHP5-Klasse auch:

Soweit noch keine Magie. Die Besonderheit bei SimpleXML ist jedoch, das bei der Instanzierung, zB. in den Funktionen simplexml_load_string und simplexml_load_file, der Klassenname als zweiter Parameter optional mit angegeben werden kann. Dies hat dann den gleichen Effekt wie die Instanzierung der eigenen, abgeleiteten Klasse über das Schlüsselwort new:

Der Clou daran ist, dass sich das abgeleitete, VerySimpleXMLElement automatisch über alle Unterobjekte erstreckt. Bei der Besprechung in der Usergruppe kam die Frage auf ob das nicht bei jedem PHP5-Objekt der Fall wäre. Dies kann getrost verneint werden, den dies muss einem Objekt erst beigebracht werden. Das SimpleXMLElement kann dies von Haus aus und dies genau ist es, was das extenden so brauchbar und praktisch macht. Vielleicht auch eine Anregung für die eigene Programmierung.

Da nun auch alle Unterobjekte von der Programmierer-eigenen Klasse abstammen, können an zentraler Stelle die für die eigene Aufgaben fehlenden Routinen gesetzt werden. Zb. ein eingänglicherer Zugriff auf Attribute. Möchte ich diese zB. optional behandeln hilft eine einfache Funktion weiter:

Auf diese kann nun durchgehend zugegriffen werden. Es braucht lediglich das eigene SimpleXMLElement verwendet werden.

Als Wermutstropfen bleibt allerdings das der Constructor als auch die Magic-Methods des Overloading beim OOP leider nicht angetastet werden können. Der eine oder andere Workaround fürs letztere befindet sich in der Linksammlung am Ende des Artikels. Allerdings Geschmacksache und vielleicht ist in diesem Punkt bei der Entwicklung der SimpleXML Extension auch noch nicht aller Tage Abend.

SimpleXMLIterator: Der SPL-Iterator auf SimpleXML

Das Erklärte lässt genug Luft für eigene Laufversuche. Aber damit hört es noch nicht auf. Dass das Extenden von SimpleXML richtig Sinn machen kann, hat auch der Entwickler Markus Börger erkannt und in seine SPL-Erweiterung den SimpleXMLIterator eingebaut. Dies im anschaulichen Beispiel folgt nach der Veranstaltung im April.

Weiteres

Während des Vortrages in der Usergroup ist noch eine kleine Linksammlung zum Thema PHP und XML entstanden:

• XML for PHP developers, Part 1: The 15-minute PHP-with-XML starter (Cliff Morgan, 2007-02)
• XML for PHP developers, Part 2: Advanced XML parsing techniques (Cliff Morgan, 2007-03)
• XML for PHP developers, Part 3: Advanced techniques to read, manipulate, and write XML (Cliff Morgan, 2007-03)
• Parsing XML using SimpleXML (Tim Koschuetzki, 2007-05)

• Probleme und Wissenwertes beim Extenden von SimpleXML

  • Overloading 1: Extending SimpleXML, Issues with extending SimpleXML, Microformats extension to SimpleXML (Oliver Brown, 2005-08/2005-09)
  • Overloading 2: Extending SimpleXML (Loïc Hoguin, 2008-02)
  • How to extend SimpleXML with missing functionality (Christian Stocker, 2005-11)
  • simplexml liefert uncatchable errors (Martin, 2008-03)

PHPIDS ermöglich Entwicklern auf einfache Weise einen zusätzliche Sicherheitsebene in PHP Anwendungen zu integrieren.

Der Vortrag von Tom Klingenberg stellte die Konzepte hinter und in PHPIDS vor. Anhand von zwei Beispielen aus dem richtigen Leben wurde die Funktionsweise zusätzlich erläutert.

• PHPIDS Vortrag PHPUGFFM 14. Februar 2008 (PDF)
• PHPIDS offizielle Webseite
• PHPIDS Forum
• PHPIDS Google group
• Whitepaper in Vorbereitung

Holger asked about info for a course and Ralf is looking into turning his FH Internet course into an online Moodle course.
Here’s YAL from down south.

http://www.phpugmunich.org/index.php/ 2007/11/13/tutorials-fur-anfanger/

If you are interested in developing such materials, let me know at the next UG meeting.

1. Schutz des Web-Servers und seiner Module (außer mod_ssl) vor Angriffen auf den Server (vor allem Buffer-Overflows).
2. Kontrolle des HTTP-Protokolls (z.B. zu alte oder fehlkonfigurierte Clients auf FAQ-Seiten umleiten, Sperrung aller nicht benötigten Funktionen)
3. Generischer Schutz vor bekannten Angriffsformen (XSS-Angriffe, SQL-Injections, PHP-Code-Injections) durch ein negative Secuirity-Modell.
4. Zeitweiliges Patchen unsicherer Anwendungen bis das Problem im Code gefixt ist.
5. Nachbau der kompletten Validierung der Web-Software durch ein positive Secuirity-Modell. Hierbei wird definiert, welche Zugriffe erlaubt sind. Alle anderen Zugriffe werden verboten.
6. Kontrolle des Servers auf Angriffsmuster und auf erfolgreiche Angriffe.
7. Reaktion auf DDoS-Angriffe durch automatische Zusammenarbeit mit Paketfilter-Firewalls, Nutzung von RBL’s.

Eine Web-Application-Firewall ist wie jedes Security-Tool kein Allheilmittel. Es ist keine Software, die man einmalig konfiguriert und um die man sich weiter nicht kümmern braucht.

Mod-Security ist ohne Regelsatz vollkommen wirkungslos und nichts für Leute, die eine setup.exe brauchen. Zwar wird eine umfangreicher Regelsatz mitgeliefert. Dieser ist aber an die eigenen Bedürfnisse anzupassen. Inzwischen erfolgt dies relativ komfortabel, so dass die mitgelieferten Dateien nicht einmal mehr editiert werden müssen.

Am Sinnvollsten ist die Verwendung eines positive Secuirity-Modells. Dieses Modell hat die geringsten Performanceanforderungen. Die Schwierigkeit besteht hierbei jedoch oftmals darin, dass die Web-Schnittstelle der Anwendung nicht ausreichend beschrieben ist.

Generell muss in jedem Fall das Logfile nach false-positivs kontrolliert werden, um den Regelsatz gegebenenfalls anzupassen.

Joost Vortrag – Is TV 2.0 becoming real? – PDF zum Download