SecurityPackage

[kummer]

das thema sicherheit kommt immer wieder auf. ich denke, man muss hier das ganze mal im ansatz anschauen und eine lösung suchen, die in aktion tritt, bevor contenido ins spiel kommt.

ich würde deshalb vorschlagen, die get- und post-parameter grundsätzlich zu prüfen (unabhängig von den modulen). dazu müssten diese konfiguriert werden (sind sie überhaupt zulässig und wenn ja, welcher regex müssten sie entsprechen). wenn ein hacker wahllos parameter übertragt, um eine injection zu versuchen, muss dies nach meiner einschätzung missglücken, wenn wir die prüfung ausreichend stringent vornehmen.

ich habe dazu mal einen paket-vorschlag gemacht. zu finden ist das ganze hier: http://www.editio.ch/cms/front_content. ... uleView=49

die integration ist einfach. die beiden klassen sind in das verzeichnis 'contenido/classes' zu legen und in der front_content.php ganz am anfang ist folgende zeile einzufügen:

Code: Alles auswählen

include_once('../contenido/classes/atelierq.securityPackage.class.inc.php');

die klasse prüft, ob sich die get-paramter in der konfiguration finden und sie der spezifizierten regex entsprechen. ist das nicht der fall, wird die ausführung abgebrochen und contenido wird gar nicht erst ausgeführt.

diese prüfung könnte nun auch auf post-parameter und auf das backend ausgedehnt werden.

natürlich muss man - wenn man mehr paramter verwendet, als ich in dieser vesion vorgesehen habe - die konfiguration entsprechend anpassen, respektive ergänzen.

für anregungen bin ich immer dankbar und hoffe, dass das die probleme lösen hilft.

gruss,
andreas

[Dodger77]

Gefällt mir echt gut, die Idee. Wenn man das dann noch in den Modulen selbst konfigurieren könnte, dann wäre das echt eine Wucht.

Übrigens: Der Link:

http://www.editio.ch/cms/front_content. ... uleView=49

funktioniert bei mir irgendwie besser.

[kummer]

Gefällt mir echt gut, die Idee. Wenn man das dann noch in den Modulen selbst konfigurieren könnte, dann wäre das echt eine Wucht.

das wäre in der tat schön. allerdings müsste dazu contenido zuerst ausgeführt werden, um die betroffenen module und deren konfiguration zu ermitteln. und genau das wollen wir ja eigentlich vermeiden.

aber ganz so schlimm sollte die konfiguration gar nicht werden. auch wenn eine relativ grosse zahl module verwendet werden, wird die anzahl gefragter parameter dennoch begrenzt bleiben. man müsste halt, nachdem ein modul installiert worden ist, das ganze mal ausführen. das package zeigt ja dann an, welcher parameter durch die prüfung gefallen ist. diesen müsste man dann halt noch ergänzen und die zutreffende regex bezeichnen.

und last not least: wenn sowas zum standard gehören würde, dann könnten die modulentwickler einfach angeben, welche zeilen in der konfiguration zu ergänzen sind. mehr ist ja gar nicht zu tun.

[kummer]

ich habe jetzt noch die post-parameter auch mitberücksichtigt. allerdings wird bei ungültigen posts die ausführung nicht gleich abgebrochen (da sonst fomulare nicht mehr funktionieren würden). zum download gehts hier lang: http://www.editio.ch/cms/front_content. ... uleView=50

neu ist:

(1) in den modulen kann mit $security->isRegularPost('meinVariablenName') geprüft werden, ob der post-parameter hinsichtlich konfiguration gültig ist.

(2) in das layout kann zu entwicklungszwecken $security->showPosts() eingefügt werden. dann werden alle post-parameter-schlüssel angezeigt (als HTML-kommentar) mit der angabe, ob diese gültig sind oder nicht oder in der konfiguration fehlen.

[holger.librenz_4fb]

Hi.

Jetzt komm ich auch endlich mal dazu meinen Senf dazu zu geben.

Ich muss gestehen, das ich im ursprünglichen Thread erst ein wenig Meckern wollte. Aber der jetzt entstandene Ansatz gefällt mir echt super. Ich würde den gern so nehmen und in Contenido direkt einarbeiten, wenn es OK ist. Dafür würd ich mich allerdings ein wenig mit an dem Code vergehen und das Ganze konfigurabel machen. Wäre das OK für Dich kummer?

So long
Holger

[kummer]

Aber der jetzt entstandene Ansatz gefällt mir echt super. Ich würde den gern so nehmen und in Contenido direkt einarbeiten, wenn es OK ist. Dafür würd ich mich allerdings ein wenig mit an dem Code vergehen und das Ganze konfigurabel machen. Wäre das OK für Dich kummer?

aber sicher doch. ich baue noch rasch ein logging ein, damit man sehen kann, wenn sich ein hacker versucht. ich poste dann den neuen code an dieser stelle.

wir wohl morgen werden. ich melde mich.

gruss,
andreas

[holger.librenz_4fb]

Hi.

Gut, dann warte ich noch.

Ich wollte es noch anpassen, das er - je nach Config - in ein Log oder (als Kommentar) ins HTML ausgibt, was geblockt werden würde. Und das würde ich abhängig machen, ob die Erweiterung im Lern- oder im Produktivmodus ist. Lernmodus bedeutet er logged einfach nur weg wenn er was verwerfen würde, Produktivmodus wäre eben der "Ernstfall" Später wäre da z.B. eine nette Idee im Admin-Bereich das Logfile mit den Fehlern auszulesen und entsprechend angeben zu können, das es gewollt ist oder eben nicht, das der Parameter durchgeht.... Der Möglichkeiten gibt es da viele.

So long.
Holger

[kummer]

ok, logging ist nun auch drin. ich denke, von dieser variante kannst du ausgehen: http://www.editio.ch/cms/front_content. ... uleView=51

falls du von mir noch was brauchen solltest, gib doch einfach rasch bescheid.

gruss,
andreas

[HerrB]

Super. Mein Wunsch wäre noch, dass der Entwickler bei den Modulen die Checks angeben kann (hat jetzt nichts mit den Klassen zu tun, sondern mit dem Modul-Bereich).

Wenn klar ist, wie die Konfigurierbarkeit von Holger realisiert wurde, würde ich mir da auch was ausdenken (wenn der Bereich nicht aktuell in Überarbeitung ist).

Gruß
HerrB

[wosch]

Nachdem ich ja meist derjenige bin der bei solchen Sachen nörgelt und mosert ...

Die Lösung von @kummer gefällt mir.
Wenn ich auch kein Programmierer/Entwickler bin, aber die Technik erscheint mir logisch und schlüssig.
Vor allem ist sie ausbau- und entwicklungsfähig für zukünftige Versionen und Module.

(Und nun bitte keine Eierlegendewollmilch... daraus machen, das ist ein Sicherheitstool, damit muß man nicht auch Mailen, Shotdown, ... machen können ...)

[kummer]

wenn ich mich hier gleich wieder einklinken darf...

ich würde diese informationen im modul einfach im output-bereich direkt in den code integrieren. dann braucht man kein weiteres feld zur einpflege dieser daten (wo fehler geschehen können).

ich stelle mir etwas in der art vor:

Code: Alles auswählen

<?php

/*
 * @param get meinVariablenName integer
 * @param get meineZweiteVariable primitivestring
 * @param post undNochEinPostParameter decimal
 */

die daten können dann aus dem modul-output-code einfach mit der regex:

Code: Alles auswählen

@param\s*(get|post)\s([a-zA-Z0-9-_]*)\s[a-zA-Z]*

isoliert und in die datenbank integriert werden. dann kann man diese daten im securityPackage verwenden.

[kummer]

(Und nun bitte keine Eierlegendewollmilch... daraus machen, das ist ein Sicherheitstool, damit muß man nicht auch Mailen, Shotdown, ... machen können ...)

genau. da gibts nicht weiter dazu zu sagen.

[holger.librenz_4fb]

(Und nun bitte keine Eierlegendewollmilch... daraus machen, das ist ein Sicherheitstool, damit muß man nicht auch Mailen, Shotdown, ... machen können ...)

Menno!

[holger.librenz_4fb]

So und nun wieder zum Thema:

Die Idee das aus dem Header zu lesen finde ich eigentlich nicht schlecht - zumal das vielleicht animiert mehr und besser zu kommentieren, wenn da schon mal ein Kommentarblock offen ist. Allerdings würde das bedeuten, das wir wieder die DB mit ins Spiel bringen. Ich finde gerade die Idee, das via File abzuhandeln, hat flair. So brauchen wir nichts, außer die Konfiguration und gut ist - keine Abhängigkeiten und bei der Menge an Daten auch noch überschaubar!

Allerdings kann man sowas ja in eine Config schreiben, wenn es rausgeparsed wird. Was denkt ihr drüber?

Ich würde übrigens auch gern die Standard-Konfiguration und die installationsabhängige Konfiguration trennen. Hintergrund hierfür ist, das die Standardkonfiguration immer mitgeliefert wird und ggf. Änderungen überschreibt bei einem Update. Wenn wir das Trennen wäre das Problem aus der Welt!

So long.
Holger

[kummer]

Allerdings kann man sowas ja in eine Config schreiben, wenn es rausgeparsed wird. Was denkt ihr drüber?

wenn wir schon beim thema sicheheit sind: das schreiben in eine datei vom server aus ist grundsätzlich als nicht sicher anzusehen. ich sehe deshalb drei möglichkeiten:

(1) entweder wird 'von hand' in ein konfigurationsdatei geschrieben (wie ursprünglich von mir vorgeschlagen) oder

(2) wir lesen die parameter wie vorgeschlagen aus den modulen. dann würde ich allerdings eine integration in die db vorsehen.

(3) oder variante 3: wir lesen aus der datenbank alle module aus, isolieren mit der regex die parameter, die in den modulen verwendet werden und bieten die datei zum download an. dann kann diese noch per ftp an die richtige stelle verschoben werden und gut. damit haben wir kein sicherheitsproblem mit schreibbaren dateien und verzeichnissen und brauchen auch noch keine db-verbindung (die wird ja erst später im verlauf der ausführung vorgenommen).

ohne jetzt im gleichen thread ein neues sicherheitsthema aufnehmen zu wollen: es wird jetzt schon reichlich vom server in dateien geschrieben (z.b. css, javascripte, templates usw.) und code aus der db mit eval() abgearbeitet (module). beides ist sehr ungünstig in punkto sicherheit. mir scheint es sinnvoll, diesen weg mindestens nicht noch weiter zu gehen. langfristig würde ich sogar ganz davon weg kommen, da die leute, die den auftritt pflegen immer einen ftp-zugang haben und mit diesem gut arbeiten können. also module in das filesystem verlegen und in der datenbank nur noch eine referenz auf die datei pflegen. templates, css und javascript ganz in das filesystem verlegen. logs zentral auf eine ebene über dem webroot verlegen und zum schreiben freigeben. gleiches gilt für graphiken. hier braucht es dann ein script, dass die graphiken verfügbar macht. wenn das alles gemacht werden würde, benötigte man keinerlei (!) schreibrechte mehr in contenido zu vergeben (mit ausnahme für graphiken und logs - da jedoch eine ebene über dem webroot oder in einem verzeichnis, das mit htaccess entsprechend geschützt werden kann).

NACHTRAG: wie gesagt, kein neues thema im gleichen thread. ich wollte damit eigentlich nur werbung machen für die variante 3.