Upload: Keine HTML Dateien zulassen / Session-Sicherheitslüc

[matthiasschnueriger]

Hallo,

Ich habe meine Webseite einem Internet Security Experten gezeigt. Gemäss seinen Aussagen hat Contenido zum Teil gravierende Sicherheitslücken, welche ich jetzt zu schliessen versuche.

1. Wie kann ich bei der Datenverwaltung den Upload von HTML-Dateien verweigern?
Hintergrund: Meine Seite hat verschiedene User und wenn einer dieser User ein HTML File mit "Cross Site Scripting" (ich verstehe davon nichts) hochlädt, kann er theoretisch die Session eines anderen Users abfangen und sich dann ohne Zugangsdaten unter einem anderen Namen einloggen.

2. Das bringt mich zu Frage 2: Nach Angaben des Experten laufen die Sessions im Verzeichnis cms/ mit Cookies, in contenido/ jedoch über den URL Parameter "contenido=". Weshalb ist das so? Zitat Experte: "Allerdings ist bei Contenido eben genau das Session Cookie schlecht gemacht, weil's nicht an die Browser-Session gebunden ist, sondern nach einer Stunde abläuft."

Was sagen die Forum-Experten dazu...?

[kummer]

1. Wie kann ich bei der Datenverwaltung den Upload von HTML-Dateien verweigern?
Hintergrund: Meine Seite hat verschiedene User und wenn einer dieser User ein HTML File mit "Cross Site Scripting" (ich verstehe davon nichts) hochlädt, kann er theoretisch die Session eines anderen Users abfangen und sich dann ohne Zugangsdaten unter einem anderen Namen einloggen.

Zunächst ist durch das Ausschalten von HTML beim Upload dieses Problem nicht weg. Es hängt genau genau genommen gar nicht mit den HTML-Dokumenten zusammen, obwohl schadhafter Code freilich dort eingebettet sein kann. Die grundsätzliche Frage ist ja, ob deine Benutzer vertrauenswürdig sind. Wenn nicht, dann musst du den von diesen Benutzer stammenden Inhalt stets auf Injektionen und schadhaften Code untersuchen oder besser gleich die Möglichkeiten soweit einschränken, dass die Übergabe entsprechender Scripte ausgeschlossen ist. Legt ein solcher Benutzer eine ganz normale Seite in Contenido an, kann er an dieser Stelle ebenfalls schadhaften Code unterbringen.

Trotzdem kannst du natürlich was tun. Beim Upload ist eine Möglichkeit. Du kannst aber auch einfach bei der Ausgabe eingreifen und Dateien mit der Endung .html und .htm gar nicht erst ausliefern. Dazu reicht ein Eintrag in der .htaccess. Aber wie gesagt: es wird dir nicht helfen, wenn deine Benutzer nicht vertrauenswürdig sind.

2. Das bringt mich zu Frage 2: Nach Angaben des Experten laufen die Sessions im Verzeichnis cms/ mit Cookies, in contenido/ jedoch über den URL Parameter "contenido=". Weshalb ist das so? Zitat Experte: "Allerdings ist bei Contenido eben genau das Session Cookie schlecht gemacht, weil's nicht an die Browser-Session gebunden ist, sondern nach einer Stunde abläuft."

Tja, das stimmt; ich kenne jedoch weder den Grund noch weiss ich, weshalb das immer noch so ist. An dieser Stelle ist Wissen auf der Seite der Agentur gefragt. Idealerweise wird die Pflege ausschliesslich über SSL vorgenommen. Je nach Sicherheitsbedürfnis muss auch darüber nachgedacht werden, vom Benutzer eine zertifikatsbasierte Authentifizierung zu verlangen. Out-of-the-Box wird die Aktualisierung über den Port 80 vorgenommen und sowohl Benutzername als auch Passwort im Klartext übertragen. Wenn man das so belässt, sind alle anderen Sicherheitsprobleme mehr oder weniger irrelevant. Will man also was tun, sollte man dort ansetzen.

Die Datenbankverbindungsdaten des Frontends sollten sich ausserdem von denen im Backend unterscheiden. Im Frontend sollte der DB-Benutzer ausschliesslich über Select-Rechte verfügen sowie ggf. über Update-, Insert- und Delete-Rechte für spezifische Tabellen, bei welchen das tatsächlich notwendig ist. Welche das sind, hängt von den verwendeten Modulen ab.

Dann sollte man alle verwendeten Module auf Sicherheitslücken untersuchen und ggf. selber welche schreiben. Das gilt insbesondere für Module, die Besucherdaten entgegen nehmen. Also Kontaktformulare, Gästebuchmodule, Newsletter usw. Oder man lässt solche besser gleich weg. Hängt halt vom Sicherheitsbedürfnis ab.

Deine Benutzer, das sollte man daneben nicht vergessen, müssen zwingend als vertrauenswürdig gelten. Wenn das nicht so ist, dürfen sie im Backend schlicht nichts tun. Du hast im Backend alle Möglichkeiten und diese will man vernünftigerweise nicht einschränken. Ich vermute mal, wir sprechen von zwei Arten von Benutzern. Diejenigen, die Zugang zum Backend erhalten, müssen als vertrauenswürdig gelten, sonst haben sie dort nichts verloren. Benutzer, die über das Frontend Daten liefern können naturgemäss nicht als vertrauenswürdig eingestuft werden. Deren Möglichkeiten müssen soweit eingeschränkt werden, dass die Injektion schadhafter Code ausgeschlossen ist. Das ist nun allerdings mehrheitlich eine Frage der Module und weniger des Kernsystems.

Kurz gesagt: dein Sicherheitsexperte hat schon recht. Allerdings hat er dir nur die Hälfte gesagt. Wenn er also tatsächlich ein Experte ist, wird er die aufzeigen können, was du tun kannst, um Sicherheit zu gewinnen. Das Ausschalten von HTML-Uploads sowie das angesprochene Session-Problem dürften nicht die grössten Probleme sein.

[Oldperl]

Verschoben, Sicherheitsthema.

Gruß aus Franken

Ortwin

[matthiasschnueriger]

Kummer: Vielen Dank für deine ausführlichen Erklärungen! Ich sehe das genauso, wenn ein Benutzer mit Zugang zum Backend Schaden anrichten will, ist der Fehler bereits viel vorher (und zwar bei der Vergabe der Zugangsdaten) geschehen!

[kummer]

Dennoch würde ich mindestens den Zugang auf das contenido-Verzeichnis ausschliesslich über SSL laufen lassen. Sonst werden Passwörter im Klartext übertragen.