Sicherheitsfunktionen

[Gast]

Willkommen Gast. Bitte einloggen oder registrieren.

Einloggen mit Benutzername und Passwort

[Darty]

Hallo, bin vor ein paar Wochen über pragmaMX gestolpert und habe auf einer Testumgebung schon Anpassungen vorgenommen, um eine neue Seite zu erstellen.
Den Einstieg erleichtert mir dabei, meine Erfahrung mit dem System von Jens Reimer (ohne Werbung machen zu wollen).

Hm, ob mein Anliegen genau hier rein passt entscheidet bitte Ihr!

Denn es geht sowohl um Programmierung von eigenen Modulen, Blöcken usw., als auch um die Möglichkeit, die Sicherheitsfunktionen von pragmamx für eigene Scripte zu nutzen.

Gibt es eine Übersicht der Funktionen, speziell im Breich der Sicherheit?

Ich denke da an Formulareingaben, HTML Nutzung, Intrusion Detection usw., halt alles was mir die Möglichkeit gibt auf Schadcode zu prüfen.
Ich denke da z.B. an eine Rezeptdatenbank oder eine Linkdatenbank, in der viele Infos eingebracht werden, zum Teil mit Bildern versehen und auch externe Links verwendet werden.
Ziel ist schlichtweg, nicht mit externen Modulen auf den Bauch zu fallen und für Sicherheitslücken zu sorgen, die von schlampiger Programmierung kommen.

Welche Funktionen sind dafür im CMS vorgesehen?

Womit wir eigentlich wieder beim Thema API währen. 

[Andi]

Hi

hier mal ein vorläufiger Auszug, aus dem demnächst erscheinenden "pragmaMx Coding Guide":

Direktaufruf von Dateien
Alle Dateien, die nur includet werden, müssen wirksam gegen Direktaufruf geschützt werden. Dies wird in pragmaMx am Einfachsten durch die Prüfung auf das Vorhandensein der Konstanten mxAdminFileLoaded (in Dateien, die von der admin.php includet werden) oder für alle Anderen Dateien, der Konstanten  mxMainFileLoaded bewerkstelligt werden.
z.B. if (!defined('mxMainFileLoaded')) die ("You can't access this file directly...");


Request Variablen
Alle dem Script per get, post und cookie übergebenen Variablen, werden bereits von pragmaMx wie folgt behandelt:
- bei register_globals=on werden zuerst die in den globalen Scope importierten Request Variablen wieder gelöscht.
- unabhängig von der Einstellung magig_quotes_gpc werden bestimmte Sonderzeichen mit einem Backslash escaped (auch rekursiv in Arrays). (nicht mehr in pragmaMx 0.2)
- bei "nicht Administratoren" werden die nicht erlaubten HTML-Tags gefiltert
- bei "nicht Administratoren" werden potentiell gefährliche Teilstrings gefiltert
- bei "nicht Administratoren" werden zensierte Inhalte ausgefiltert
Nach der Behandlung, werden diese Variablen in den globalen Scope kopiert, da einige Scripte die Einstellung register_globals=on erwarten. (nicht mehr in pragmaMx 0.2)


Session Variablen
Die Session Variablen sollten nicht direkt über $_SESSION verwendet werden, sondern über folgende Api-Funktionen:
- mxSessionSetVar($name, $value) > setzt eine Variable in der Session
- mxSessionGetVar($name) > liest eine Variable aus der Session
- mxSessionDelVar($name) > entfernt eine Variable aus der Session


Lesen und Schreiben in der Datenbank
Durch das expliziete escapen und filtern aller Request Variablen, sind diese eigentlich zur Verwendung in der Datenbank vorbereitet. Trotzdem, weil sich dieser Zustand zwischenzeitlich ändern kann, müssen alle Stringvariablen, vor der Verwendung in der Datenbank mit der Funktion mxAddSlashesForSQL($what) behandelt werden. Desweiteren empfehlen sich weitere individuelle Prüfungen auf Gültigkeit, z.B. anhand einer "white-List" oder einer einfachen Längenbegrenzung. Variablen, die nur Zahlen enthalten dürfen, müssen vor der Verwendung in der DB mit intval() oder ähnlichen Funktionen behandelt werden, so dass auf jeden Fall nur ein gültiger Zahlenwert (oder 0) enthalten ist.
Die Prüfung bzw. Umwandlung der Variablen sollte entweder direkt im zusammengesetzten String der Datenbankanfrage geschehen, oder zumindest unmittelbar davor.
Die vielverbreitete Unsitte, dass ausgelesene Datenbankwerte mit stripslashes() behandelt werden ist unnötig, bzw. sogar unsinnig.


Anzeigen von Datenbankinhalten oder Request Variablen
Trotz der vorbeugenden globalen Behandlung von Request Variablen, sollten diese auch vor dem Anzeigen innerhalb der Webseite, auf Gültigkeit geprüft werden.
Alle Daten die zur Anzeige gelangen, sollten mit der Funktion mxPrepareToDisplay() behandelt werden, um evtl. darin enthaltene eMailadressen und ähnliche Dinge, vor Spambots zu verstecken.

[Darty]

Oh, Andi sorry für den späten Return!

Danke für die umfangreiche Antwort, bin Beruflich leider sehr gebunden und komme nur noch sporadisch zum Coden.
Aber damit läßt sich schon was anfangen.

Gruß Darty