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! :D

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! :-D
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.