Studienarbeit: Erste Lebenszeichen

Hachja! Ist das schön, wenn man an einem Projekt arbeitet und irgendwann endlich mal irgendeine Reaktion der Anwendung verzeichnen kann. 😉

Gerade arbeite ich mal wieder an meiner Studienarbeit und sehe das erste Mal, das auch wirklich etwas passiert - einfach grandios! 😀

PESD: First Impression

PESD: First Impression


Was das sein soll?! Das kann man doch erkennen: Ein Forum!

Was man auf dem Bild sehen kann, sind die ersten Lebenszeichen der Template-Engine: Anstatt im Quelltext direkt zu hinterlegen, wie die Seite aussehen soll, werden die einzelnen Teile aus Template-Dateien gelesen und entsprechend umgesetzt.

Alle Nachrichten können bereits über deren Message-ID abgefragt werden. Dabei wird geguckt, ob eine Nachricht eine Kategorie darstellt, oder eine echte Frage (bzw. eine Antwort auf eine Frage) ist! 🙂

Was man sieht, ist der merkwürdige Benutzername MISSING - das kommt daher, dass intern noch nicht alles verdrahtet ist. Genauer gesagt: Das Forum ist noch nicht an das eigentliche System - PESD - gekoppelt.

PESD ist das Akronym für PHP: Enhanced Security for Databases. Dabei handelt es sich um ein Framework für die Erstellung sicherer Datenbankanwendungen in PHP. Sicher bedeutet hier, dass, auch wenn der Quelltext der Anwendung kompromitiert wird, ein Angreifer immernoch keinen Vollzugriff auf die darunter liegende Datenbank erhalten kann.

Dafür wird im Quelltext lediglich der Zugang zu einem Minimalaccount hinterlegt, der über eine Stored Procedure für den Login die Zugangsdaten für höherwertige Accounts abrufen und sich dann dadurch mehr Rechte verschaffen kann.
Auch die Datenbankabfragen und -manipulationen höherer Accounts sind durch (automatisch erzeugte) Stored Procedures gekapselt, sodass intern ein Data-Ownershipmodell durchgesetzt werden kann.

Wünscht mir Glück, dass ich die primären Ziele bis zum 11.09.2009 erreiche 😉 . Ich werde euch inzwischen auf dem Laufenden halten!

Update:
Beinahe vergessen es zu erwähnen: Ein massiver Vorteil von PESD gegenüber anderen - oder garkeinen - Systemen ist, dass die Anwendung gegen SQL-Injections abgehärtet wird! 😀
Dadurch, dass im Normalbetrieb (z.B. Foreneinträge lesen) keine höheren Privilegien gebraucht werden, werden auch keine schadhaften Änderungen zugelassen oder der Zugriff auf sensitive Daten bereitgestellt.

Lebendige Grüße, Kenny

Anmerkung an mich selbst: Da für Benutzer der gleichen Ebene derselbe Datenbank-Account verwendet wird, muss ein anderer Weg gefunden werden, um im Backend mit Sicherheit feststellbar sein, wer gerade den Account verwendet. Lösungsidee ist das verwenden einer Unique ID, die während dem Login zurückgegeben wird. Diese ist zeitlich begrenzt gültig und wird bei weiteren Calls anstelle der User-Credentials übergeben, um den tatsächlichen Benutzer zu bestimmen.

9 Kommentare » Schreibe einen Kommentar

  1. Hm, da hierzu kein neuerer Beitrag mehr gefunden werden kann, mal eine Frage:

    Wie weit bist du mit dem PESD? Mich würde es schon interessieren, wie du es technisch gelöst hast. Optimal wäre auch, man hätte schon einmal etwas Code zum Begutachten. Zumal, wie lang geht die Studienarbeit noch?

    Und: kommt der Quellcode an die Öffentlichkeit? Wenn ja, unter welcher Lizenz? Vielleicht gibt es dann auch jemanden, der das dann auch auf andere Skriptsprachen portiert und so weiter und so fort ...

    Okay, es waren mehr als eine Frage. 🙂

    greetz
    blogcrafter Chris

    • Danke, dass du mich daran erinnerst: Die Studienarbeit wurde längst eingereicht - wie alles, was mein Studium betrifft (bin seit einem Monat fertig und in der Arbeitswelt angekommen). Hatte bisher noch keine Zeit, das ganze in einen fachgerechten Artikel zu verwursten.

      Soviel sei gesagt: der Schutz-Mechanismus selbst funktioniert einwandfrei - was fehlt ist die Implementierung in einem echten (Test-) Projekt. Hierfür fehlen allerdings noch ein paar Helferlein (es ist ein bissel mehr Aufwand, die einzelnen Stored Procedures per Hand zu erstellen, wenn man sie auch aus SQL-Statements autogenerieren lassen könnte).
      Auch das Error-Handling der Core-Methoden ist noch nicht perfekt: Wenn man versucht, ein Statement auszuführen, dass der aktuellen Rolle nicht erlaubt ist, dann scheint das keinen Fehler zu generieren - man kriegt lediglich kein Ergebnis zurück. Da muss unbedingt nochmal nachgebessert werden. Glücklicherweise habe ich alle mysqli-Funktionen nochmals gekapselt, sodass solch ein Fix nur an einer Stelle durchgeführt werden muss.

      An genau einer Stelle während der Entwicklung hat mich das System wirklich überzeugt: Angenommen man hat einen Benutzer, dem eine Rolle zugewiesen ist. Dieser soll nun eine höhere Rolle erhalten (z.B. wird ein normaler Forenuser zum Moderator ernannt). Dadurch, dass der Benutzer auch über sein abgeleitetes Passwort mit dem korrekten DB-Account verbunden ist, ist es garnicht möglich, die Rollenänderung ohne den Benutzer durchzuführen (ausgenommen dem Fall, dass man sein Passwort gleichzeitig zurücksetzt). Zum ändern der Rolle des Benutzers ist zwingend der Benutzer selbst erforderlich, der sein Passwort angeben muss.

  2. Mit "Lösungsidee ist das verwenden einer Unique ID, die während dem Login zurückgegeben wird." meinst du eine session id?

    Heutzutage bedarf es nur eines winzigen codeschnipsels, um user-generated-content sicher in db's einzufügen.
    beispiele für php strings:
    mysql_real_escape_string()
    für zahlen: intval(), floatval(), is_numeric(), etc.

    Heutzutage ist es viel wichtiger cross-site-scripting lücken (XSS) zu verhindern, aber auch (E-Mail-)Header-Injection's sind eine gefahr.

    ps. in deinem artikel steht noch nicht mal, mit welcher programmiersprache und datenbank du dich beschäftigst

    • Tut mir leid, falls ich dir damit zu nahe trete, aber deine Dagegen-Phase wird langsam recht anstrengend.

      Um Begriffsverwirrungen vorzubeugen heißt diese Unique-ID in der Anwendung Token. Dabei handelt es sich um einen HMAC, der Webbenutzer-spezifisch ist und dieses innerhalb der Datenbank ausweist.

      In meinem Artikel taucht der Name des Projektes auf: PHP: Enhanced Security for Databases. Es wird derzeit primär für die Verwendung mit MySQL entwickelt.

      Du verkennst den Ansatz. Deine genannten Sicherungstechniken sind anwendungsseitig. Ziel ist es aber, die Sicherheitsschicht - soweit möglich - zur Datenbank zu verlagern. Sobald bei einer normalen Anwendung jemand Zugriff auf den produktiven Code bekommt, hat dieser - im Fall PHP - zu 99%iger Wahrscheinlichkeit auch Zugriff auf die Admin-Accountdaten (Username, Passwort).

      Um es nochmal deutlich zu machen: PESD dient nicht dazu, die Datenbank durch die Webanwendung zu schützen, sondern die Datenbank vor der Webanwendung zu schützen. Selbst wenn diese anfällig für XSS ist, soll dieses verhindert werden, indem normale Besucher garnicht die Möglichkeit haben, eigene SQL-Statements abzusetzen (fehlende Rechte). Gleichzeitig soll das System so bequem sein, dass es für den täglichen Multi-User-Einsatz (z.B. in Foren) nutzbar ist.

      • Mach dir keine Sorge, es geht mir nicht darum gegen Dich zu sein, sondern nur mehr Informationen zu erhalten.

        • Damit vllt. die Intention hinter PESD verständlicher wird: Ich habe bereits in meiner Bachelor-Thesis kurz über das Problem der Software-side Security bei Datenbankanwendungen geschrieben. Aus diesem Anriss ist auch die Idee zu PESD entstanden. Ich habe dir mal Kapitel 3: Software-side Security aus der Arbeit extrahiert.

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.