Archiv der Kategorie 'Entwicklung'

Statische Code-Analyse

Freitag, den 11. April 2014

Nobody’s perfect. Aber man kann daran arbeiten. :)

So nutzen wir für die Entwicklung unserer Anwendungen in C/C++ auch statische Code-Analyse. Nachdem clang (scan-build) und cppcheck sich die Zähne ausgebissen haben, setzen wir (leider) erst seit Kurzem auch PC-Lint ein.

Warum “leider”? Ich weiß auch nicht wie, aber irgendwie ist dieses Tool völlig an mir vorbei gegangen - vielleicht weil es an sich nur unter Windows läuft. PC-Lint ist das Urgestein für statische Analyse von C-Code, wird seit rund 30 Jahren stetig weiterentwickelt (!) und ist einfach der absolute Wahnsinn.

Nun bin ich kürzlich über einen Blogbeitrag gestolpert, wie man PC-Lint mittels wine auch unter Linux zum Laufen bekommt. Perfekt! :) Das spart den umständlichen Umweg über MinGW etc.

Natürlich braucht es eine Weile bis sich der Umgang mit PC-Lint “eingeschliffen” hat und man in den Unmengen der Logmeldungen auch die eigentlich interessanten Meldungen findet. Unsere Erfahrung ist jedenfalls, dass die Codequalität seit dem Einsatz von PC-Lint nochmals drastisch zugenommen hat - verschärfte gcc-Flags, scan-build und cppcheck waren nur ein kleiner Anfang.

Man darf sich jedenfalls nicht durch die Website von PC-Lint oder dessen Installationsprogramm abschrecken lassen - die Usability ist da wohl vor einigen Jahren stehen geblieben ;)

Authentisch

Freitag, den 7. Februar 2014

Ich find’s immer wieder toll, wenn Kunden von unserer Software begeistert sind:

SCHEIß DIE WAND AN, ist dieses Stück Software geil

Das ist doch mal ein authentisches »Customer Statement« :)

Arbeitstag

Mittwoch, den 8. Januar 2014

Eben im Gespräch mit einem Kollegen (es ging um die Aufwandsabschätzung bei einem Softwareprojekt):

Kollege: »Wie lange dauert das dann etwa?«

Ich: »Hmm… ich würde mal einen Arbeitstag dafür ansetzen.«

Kollege: »Einen Arbeitstag von Dir - 16 Stunden - oder einen von mir?«

libsepa: SEPA mit PHP, Perl, Java und C

Mittwoch, den 18. Dezember 2013

Unser neuestes Produkt ist libsepa (libsepa.com) - eine Bibliothek zur Erstellung von SEPA-Lastschriften/-Überweisungen sowie zur zuverlässigen Konvertierung und Validierung von IBAN/BIC.

libsepa ist für PHP, Perl, Java und C verfügbar und kostet nur einen einmaligen geringen Betrag (Updates sind kostenlos).

Wer also noch sein bisheriges Abrechnungssystem von DTA auf SEPA umstellen muss, der sollte einen Blick auf libsepa werfen. :-)

libsepa

SEPA

Dienstag, den 1. Oktober 2013

So, die erste Hälfte unserer Umstellung auf SEPA ist geschafft: heute gingen unsere ersten selbst erzeugten SEPA-Überweisungen heraus. Dabei handelt es sich um etwas komplexere Nachrichten (Gehaltszahlungen, VL-Beiträge, normale Zahlungen). Hat scheinbar reibungslos geklappt. :)

Nun geht’s an den nächsten Schritt: SEPA-Lastschriften. Die dazu notwendige Mandatsverwaltung usw. haben wir bereits implementiert, jetzt müssen “nur” noch die Kunden informiert werden (Prenotification).

Wir machen das übrigens mit einer eigenen Software, die in Kürze auch kommerziell erhältlich sein wird. Details folgen.

LiveConfig für eco Internet Award 2013 nominiert

Montag, den 27. Mai 2013

eco Internet AwardWir freuen uns riesig, dass unsere Controlpanel-Software LiveConfig für den begehrten eco Internet Award nominiert wurde! Mit diesem Preis zeichnet der eco - Verband der deutschen Internetwirtschaft e.V. jährlich die innovativsten Produkte und Dienstleistungen aus. In der Kategorie Hosting/Housing/Datacenter zählt LiveConfig zu den drei Besten.

Nun heißt es: abwarten und Daumen drücken - die Verleihung des Preises findet am 27. Juni im Rahmen einer feierlichen Gala in Köln statt.

Um sich bis dahin die Zeit etwas zu verkürzen empfehle ich, einen Blick auf die neue Version 1.6.2 von LiveConfig zu werfen: mit Zwei-Faktor-Authentifizierung (z.B. via Google Authenticator), einem Live-Log-Viewer, der Verwaltung globaler php.ini-Einstellung, Login für E-Mail-Endkunden und vielem mehr.

An den nächsten Features wird bereits gearbeitet. :)

Never change a running system

Mittwoch, den 3. Oktober 2012

In der Datenbank-Bibliothek, die unserem LiveConfig zugrunde liegt, gabe es eine Reihe Änderungen, die nun u.a. auch ein Profiling der Datenbankabfragen ermöglichen. Bei der Gelegenheit habe ich SQLite von v3.7.13 auf 3.7.14 aktualisiert - was zu einem kompletten Crash geführt hat.

Offenbar gibt es in SQLite 3.7.14 einen Bug im Zusammenhang mit dem optimierten Query Planner, der aufgrund einer Nullpointer-Dereference zu einem SEGFAULT führt. Ein einfacher Aufruf von “ANALYZE” in der Datenbank beseitigt das Problem (zumindest vorerst).

Meldung an die Mailingliste ist schon raus. :)

[Update] Nun gibt’s ein offizielles Trouble Ticket dazu…

Klartext-Passwörter

Freitag, den 13. Juli 2012

Es war nun einige Wochen lang recht still hier im Blog, ich habe mir vorgenommen das wieder zu ändern. :-)

Los geht’s aus aktuellem Anlass mit Klartext-Passwörtern. Das Controlpanel “Plesk” steht derzeit wieder im Kreuzfeuer, da laut dem Sicherheitsexperten Brian Krebs ein sogenannter “0day exploit” die Runde macht und gleichzeitig die Sicherheitslücke vom Februar 2012 für bittere Nachwirkungen sorgt. Damals konnte durch eine SQL-Injection in der Remote-API von Plesk völlig anonym auf betroffene Systeme zugegriffen werden, wobei im großen Stile die Benutzerpasswörter ausgelesen wurden. Diese speichert Plesk in der Tabelle psa.accounts unverschlüsselt und nicht gehashed.

Parallels hat natürlich reagiert und neben dem Bugfix auch ein Tool zur Massen-Änderung von Passwörtern bereitgestellt. Blöd ist nur, dass die kompromittierten Passwörter nicht auf eine Blacklist gesetzt wurden - so haben viele Endkunden die neuen (kryptischen) Passwörter einfach wieder zurück geändert. Wie will man sonst auch seine Kunden dazu “zwingen”, wirklich ein neues Passwort zu verwenden?

Nun, die Tatsache, dass in einer Remote-API eine SQL-Injection möglich war, ist eigentlich schon schockierend genug - es gibt viele Methoden um so etwas zu vermeiden (von der statischen Code-Analyse bis zur Verwendung von Prepared Statements). Aber das Passwörter jeglicher Art im Klartext gespeichert werden ist kein Programmierfehler, sondern meiner Meinung nach grobe Fahrlässigkeit. Auf Unix/Linux-System werden seit zig Jahren alle Account-Passwörter gehashed (anfangs nur mit crypt(), inzwischen schon mit komplexen SHA256-Hashes). MySQL ist nun auch nicht gerade für maximale Zugriffssicherheit bekannt (zumindest möchte ich mal behaupten, dass es für einen normalen Systembenutzer einfacher ist, in MySQL einzusteigen als /etc/shadow auszulesen).

Es gibt durchaus das Problem, dass einem Controlpanel ein reiner Hash des Benutzerpassworts nicht reicht - das ist beispielsweise bei E-Mail-Passwörtern häufig der Fall. Wir lösen das so, indem E-Mail-Clients sich nur über das CRAM-MD5-Verfahren am Mailserver anmelden dürfen (PLAIN macht keinen Sinn, da Passwörter völlig unverschlüsselt über den Äther gesendet würden). Auf dem Mailserver kann statt dem Klartext-Passwort nun das “vorgehashte” Passwort abgelegt werden - eine Speicherung im Klartext ist überflüssig (bei Dovecot ist es das Passwort-Schema CRAM-MD5).
Warum Plesk aber selbst das Admin-Passwort mit einem einfachen Shell-Befehl ausgeben kann, entzieht sich meiner Vorstellungskraft. Und wie mit diesem Panel betriebene Webserver eine PCI-Zertifizierung erhalten, obwohl wissentlich kritische Passwörter unverschlüsselt bleiben, ist ebenfalls fragwürdig.

Programmierfehler kann jeder machen - keine Frage. Ich kann auch nicht dafür garantieren, dass es bei LiveConfig keine Sicherheitslücken gibt (das wird vermutlich niemand können). Wir können aber unser Bestes tun, um so etwas zu vermeiden und im “worst case” den potenziellen Schaden zu minimieren: Passwörter werden grundsätzlich nur als gesalzene Hashes gespeichert, kritische Daten (etwa Private Keys für SSL-Zertifikate) werden stark verschlüsselt, SQL-Injections durch Prepared Statements unmöglich gemacht, und so weiter. Ein System ist eben nur so sicher wie seine schwächste Stelle.

Und zum Thema “automatische Passwörter” folgt in Kürze der nächste Beitrag.

Ach ja, bis heute werden in Plesk 10 (v10.4.4#36) die Passwörter nicht verschlüsselt!