Zugriffsrechte: Diskussion gewünscht

[Robert R.]

Lieber Mitdenker Hotti,
liebe Mitdenker im gesamten Forum,
liebe Wissende,
liebe Neugierige,

ja!

Es ist sehr umständlich und auch an einer Stelle unlogisch: Wenn das Berechtigungssystem in der DB abgebildet ist, warum müssen dann nach einer Abfrage die Berechtigungen erneut geprüft werden wenn es um Ausliefern von Content geht?

Ich würde die möglichen Konzepte gerne noch weiter diskutieren.
Das ist ein grundsätzliches Problem von CMS im HTTP-Umfeld. Viele Systeme und Portale haben da immense Lücken.

Ich wollte die nun bei unserem _bestehenden_ System durch eine möglichst simple und für nachfolgende Betreuer leicht verständliche Anprogrammierung schließen. Bisher werden nämlich immer die URLs der Bilder, die dann auch noch in einem Verzeichnis innerhalb der Document Root liegen, in der Antwort auf den Primärrequest der Ressource (MRD = Main Response Document, so heißt das bei uns zumindest) ausgegeben. Das ist kritisch, da z.B. Bilder von Mitgliedern der Community nur genau einer bestimmten Gruppe der Community zugänglich sein dürfen. Man könnte theoretisch das Verzeichnis durchklappern, ob man Treffer findet.

1.) Ersteinmal könnte man das Bilderverzeichnis (gilt aber auch sinngemäß für alle anderen MIME-Types) aus der DocRoot rausnehmen.

2.) Dann könnte man die zu sichernden Documents mit einem kryptischen Namen, ähnlich dem Sessionnamen von PHP versehen. Das verringert schon einmal die Trefferquote um Faktor (Namensvorrat/Anzahl der Dateien). Das Verhältnis dürfte selbst bei 1.000.000 Dokumente noch hoch genug liegen, dass es als _relativ_ sicher gelten kann.

3.) Da der Zugriff nun nur noch per Skript möglich ist, könnte man dessen Ausführung auch noch von einger gültigen Session abhängig machen.

4.) Da es nun möglich ist, Fehlversuche genau dem Sessionbesitzer zuzuordnen, könnte man nach z.B. 10 Fehlversuchen den Benutzer sperren.

5.) Schlussendlich könnte man die Ressourcelocators auch noch verschlüsseln, was dann aber zu extrem langen Ressourcekennungen (RUL-Encode lässt grüßen) führen könnte. Und die Sicherheit würde vermutlich aufgrund des ohnehin schon riesigen Namensvorrates nicht erhöht werden. Die Ergebnisse werden vermutlich ohnehin aus derselben Zielmenge stamnmen.

Was spart man dadurch?

• Keine zusätzlichen Datenbankzugriffe für Sekundärerequests nötig.
• Keine Instantiierung des Gesamtsystems bei jedem Sekundärrequest nötig.
• Kein Eingriff in die grundlegende Sicherheitsarchitektur des Systems nötig

Die Sessiondatei wird ohnehin geladen, die Datei mit den Hauptfunktionen auch. Man kann die Sekundärrequests auch mit einem Minimalskript abarebiten, das ausschließlich die Config-Dateien benötigt und die Session aufrufen muss, um festzustellen, ob die Gültig ist.

Weil bei HTTP alle Requests immer für sich alleine stehen?

Content Negotiation ist das Stichwort.

Was soll ich da verhalndeln?
Content Negotiation würde die Sicherheit eher verringern, als erhöhen.

Du kannst das viel einfacher lösen mit einer Routing-Table und einer Klassenbindung an die entsprechenden Ressource:
  URL => Class

Das würde ja bei Mod_Rewrite schon so wein. Da benötige ich nur das zugehörige Skript, dass keinerlei Sonderregelungen mehr benötigt (siehe obige Beschreibungen)

Spirituelle Grüße
Euer Robert