sharpx

Hallo und Frohe Weihnachten (nachträglich)!

In den letzten Tagen habe ich mir über ein konzeptionelles Problem hinsichtlich Anwendungssicherheit bzw. Datenvalidierung für ein Onlineportal (Kundenprojekt) den Kopf zerbrochen.

Alle genutzten "eingehenden Daten" (d.h. $_GET, $_POST, $_COOKIE und manche Elemente aus $_SERVER) werden vor Ausführung der eigentlichen, HMVC-basierten, Anwendungslogik zentral vorvalidiert (eine strengere Validierung entsprechend dem jeweiligen letztendlichen Verwendungszweck der Information erfolgt innerhalb des Controllers). Ein Beispiel für eine solche Vorvalidierung wäre, dass $_GET-Elemente lediglich Alphanumerische (+ Deutsche Umlaute) Zeichen enthalten dürfen. Im Controller kann der Programmierer nun z.B. noch definieren, dass es sich nur um einen positiven ganzzahligen Wert 0 <= x < 10.000 handeln darf.

Das Vorgehen bei einer Verletzung der (sehr genau festgelegten) Validierungsregel innerhalb des Controllers ist klar. Die Ausführung der Anwendungslogik wird unterbrochen und ein spezieller ErrorController wird ausgeführt.

Nun stellt sich mir die Frage wie ich in der Vorvalidierungs-Klasse am Besten vorgehe.

Sollte ich versuchen die Eingaben zu säubern, sie also in gemäß meiner Spezifikationen valide Inhalte transformieren, auch auf die Gefahr hin, dass sie absichtlich eingegeben wurden, um die Systemsicherheit zu testen / zu gefährden. Vorteil hier wäre die Benutzerfreundlichkeit, da eventuelle Fehleingaben (z.B. ein Ausrufezeichen in einem Alphanumerischen Feld) einfach weggefiltert werden, ohne das der Benutzer eine Fehlermeldung erhält und dementsprechend nicht im Arbeitsablauf gestört wird.

Auf der anderen Seite könnte ich mich dafür entscheiden, bei einem Verstoß gegen meine Spezifikationen direkt die Anwendungslogik abzubrechen und eine Fehlerseite anzuzeigen. Grundlage der Entscheidung zu diesem Vorgehen wäre, dass non-valide Daten die auf das passende Format zurechtgestutzt werden, trotzdem nicht die vom Benutzer erwarteten Ergebnisse erzielen würden. Auch könnte es sich um sinnfreie Daten handeln, wie oben bereits beschrieben. Nachteil hier ist natürlich die BenutzerUNfreundlichkeit.

In meinem Kopf streiten sich gerade Engelchen und Teufelchen was ich denn nun tun sollte - Es wäre hilfreich wenn Ihr eure eigenen Gedanken / Philosophien zu diesem Thema mit mir teilen könntet bzw. evtl. auch eure eigene Projekte und die dort getroffenen Entscheidungen hinsichtlich des Themas "Anwendungssicherheit / Datenvalidierung" vorstellen könntet.

Danke hierfür im Voraus!

__________________
root@php.de:~$ rm -rd /

Mister Ad

meikel

Danke gleichfalls.

Leider falsch, weil GET Strings urlencodet sein müssen.

http://php.net/rawurlencode

sharpx

Und wo genau siehst du hier das Problem? Das entsprechende Decoding übernimmt PHP automatisch.

__________________
root@php.de:~$ rm -rd /

meikel

Code mit non-US-ASCII Zeichen im URL ist Kot.

sharpx

Könntest du dich bitte etwas verständlicher Ausdrücken?

Hier mal ein kleiner Auszug aus meinem Code:

__________________
root@php.de:~$ rm -rd /

tr0y

Pre-Validation die außerhalb der gesamtlogik passiert ( meinetwegen schon im Bootstrap der Anwendung oder als eigene vorgeschaltete Library ), die Superglobals "überarbeitet" würde bei mir InvalidArgumentExceptions statt den eigentlichen Werten übergeben. Das Inbound-Konzept der Anwendung müsste nur entsprechend dem gelieferten Interface reagieren, Die Exception entweder weiterreichen oder direkt abfeuern. Alles in allem würde ich aber auf keinen Fall den Wert der meine Anwendung kompromitieren könnte, an meine Anwendung ranlassen ( wollen ).

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

sharpx

Die Gefahr der Kompromitierung existiert ja nicht (mehr), da die Daten im gegebenen Beispiel nun lediglich a-zA-Z0-9 => alphanumeric sein können. Die Frage ist nur, ob es Sinn macht, hier eine "heile Welt" anzunehmen und mit den gesäuberten Daten die Programmlogik weiterlaufen zu lassen.

__________________
root@php.de:~$ rm -rd /

tr0y

Informier die Anwendung doch das dort gesäubert wurde ( wie oben beschrieben ), dann kannst du zumindest Anwendungszentral mitloggen was die Anwendung auch betrifft.

Wenn du keine Exceptions dafür weiterreichen willst ( weil du Werte säuberst und doch weiterreichts ) würde ich zumindest ein Interface implementieren das die Anwendung ein Subject aggregiert und deinem Validator einen Observer, der diese Exceptions der Validation "zur Kenntnisnahme" piped.

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

nedelin

Mein Gott, wie ich solche pauschalen Statements liebe...

@sharpx:

Ich mach's ähnlich wie Du: es gibt eine zentrale Vorvalidierung eingehender Daten. So wird bspw. für GET geprüft:

1. ist die GET-Variable überhaupt registriert
2. erlaubte Zeichen des GET-Wertes via Whitelist; ist abhängig von der GET-Variable
3. max. Länge des GET-Wertes

Die Superglobalen werden anschliessend gelöscht, um die Verwendung verseuchter Daten auszuschliessen. Bei erfolgreicher Validierung werden die Superglobalen als statische Klassenmember bereitgestellt; im Fall einer negativen Validierung wird im Content-Controller eine Fehlerseite + entspr. HTTP-Header ausgelöst.

Im Falle der POST-Variablen werden die hereinkommenden Daten an der Stelle der konkreten Implememtierung geprüft; hier greift eine zentrale Validierung zu kurz. Dies übernimmt i.d.R. eine Klasse zur Formularverarbeitung, welche über das Model (Datenbank) konfiguriert wird. Darüber hinaus können für spezielle Szenarien individuelle POST-Variablen registriert werden, z.B. Integer.

dr.

dr.e.

Zentrale Validierung für konkrete Anwendungsteile verletzt ganz klar die Kapselung (weiter auch separation of concerns)! Konkrete Logik sollte auch in der konkreten Implementierung stecken und nicht "aussen" bereits bekannt sein. In einer Bootstrap, einem Input-Filter oder einer Front-Controller-Action lassen sich allgemeingültige, Anwendungs-übergreifende Dinge validieren, nicht jedoch konkrete Inputs für beispielsweise ein Formular in der Anwendung. In diesen kann ich mir XSS-Prüfungen oder DB-Attacken ansehen und ggf. mit einer globalen Fehlerseite beantworten (natürlich mit einem Log um im Betrieb derartige Angriffe analysieren zu können).

Sobald es im Rahmen einer HMVC-Implementierung um die Prüfung von konkreten Eingaben angeht, ist immer diejenige Komponente dafür zuständig um die es gerade geht. Diese "kennt" ihre Business-Prozesse, ihre validen und nicht validen Eingaben und kann entsprechend reagieren. Aus Usability-Gesichtspunkten möchte der Benutzer doch keine globale Fehler-Seite angezeigt bekommen, wenn er statt einer "1" eine "5" eingegeben hat.

Ich bin mir nicht sicher, in wie weit du dich mit Software-Architektur-Pattern befasst hast, dieser Satz klingt jedoch sehr abenteuerlich. "vorvalidieren" ist ein bischen wie "halbschwanger" und HMVC ist ein Struktur-Pattern für Web-basierte GUIs und zunächst keine Anwendungslogik.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~