[philosapiens]

Hi,

wenn ich ein Textdateien-CMS erstellen möchte, wobei die Textdateien in einem mit .htaccess-geschützen Ordner liegen soll und der Adminbereich in einem anderen ebenso geschützen Ordner, bestünde dann noch ein Sicherheitsrisko und wenn welches? Ich meine, man könnte ja ohne der Kenntnis der Variablen nix über die URL aufrufen und so die Variablen füllen. Und ohne Datenbank, könnte man die ja auch nicht "knacken".

Oder gibt es da auch elementare Sicherheitslücken, die man unbedingt abdecken sollte?

[Manko10]

Bei einer Datenbank gibt es auf jeden Fall ein Locking-Problem. Du musst die Datei locken, um bei gleichzeitigen Zugriffen, die Zerstörung der Datei zu verhindern. Das ist bei Datenbanken einfach deutlich besser (aber auch deutlich komplexer) gelöst als du es mit flock() je erreichen könntest.
Es könnte aber auch jemand dein Gästebuch lahmlegen, indem er einfach eine Million Einträge macht und dann merkst du schon, dass du das mit explode() und Schleifen zusammengefrickelt und nicht ein DBMS genutzt hast.
Der Punkt Datenbank knacken vs. Textdatei ist auch absurd. Wenn dein Datenbankuser nicht zufällig root heißt und nur Zugriff auf die Gästebuch-DB hat, kann ein Angreifer nicht mehr Schaden anrichten als bei einer Textdatei. Im schlimmsten Falle sind die Einträge weg, mehr nicht. SQL-Injections lassen sich aber auch durch konsequentes datenbanknahes Escaping verhindern.
Ohne Code kann ich dir aber nicht mehr sagen. Der Rest liegt an deiner Programmierung, ob die Sicher ist oder nicht. Wenn du nicht auf den Dateinahmen aufpasst, könnte es z.B. sein, dass plötzlich hübsche Bruteforce-Skripten in /tmp oder /var/tmp liegen oder plötzlich deine Datenbankzugangsdaten im Gästebuch stehen oder…

[Scheppertreiber]

Eine filelock ist ein filelock ist ein filelock ...

Ist die Datei blockiert ist sie es definitiv auch. Bei Datenbanksystemen wird
meist nur ein Bereich der Datei gelockt (zB Record-Locking). Zumindest für
die Laufzeit des Scripts.

Gleichtzeitige Zugriffe sind nicht das Problem, eher gleichzeitige Schreibzugriffe.

Es ist auch niemand gezwungen, für die Mini-Datenmengen eines Gästebuchs
eine Datenbank zu verwenden. Die GB-Spammer schießen sich auf SQL ein,
nimm halt etwas anderes.

[philosapiens]

Hi,

super! Vielen Dank für den Tipp! Na mal sehen, ob ich das so alles realisiert bekomme.

[Manko10]

Eine filelock ist ein filelock ist ein filelock ...

Ist die Datei blockiert ist sie es definitiv auch. Bei Datenbanksystemen wird
meist nur ein Bereich der Datei gelockt (zB Record-Locking). Zumindest für
die Laufzeit des Scripts.

Das ist mir bewusst. Dennoch nutzen Datenbanken nicht einfach Locks, das wäre zu unsicher. Die Lockingsysteme von Datenbanken sind hochkomplex und nicht einfach zu verstehen, um größtmögliche Datensicherheit bei größtmöglicher Zugriffsrate zu gewährleisten. In groben Zügen funktioniert das zwar genauso, aber allein mit flock() kommt man nie an das Locking einer Datenbank heran.

Mit gleichzeitigen Zugriffen meinte ich schreibende zugriffe und schreibende/lesende Zugriffe in Kombination. Hier muss mit Shared-Lock und Exklusivlock gearbeitet werden, um keine fehlerhaften Daten während eines Schreibprozesses auszulesen. Bei einem Gästebuch sicherlich nicht so das Riesenproblem, vor allem wenn es nicht starkem Traffic ausgesetzt ist, aber durchaus eine Sache, die man wenigstens bedenken sollte.

[inta]

Eine Datenbank quasi selbst zu bauen, halte ich auf für reichlich sinnlos. Das einzige Sicherheitsproblem bei der Verwendung einer Datenbank sind eigentlich SQL-Injections und davor kann man sich leicht schützen - entweder durch sowas wie mysql_real_escape_string oder am besten gleich prepared statements.

[Scheppertreiber]

Eine Datenbank quasi selbst zu bauen, halte ich auf für reichlich sinnlos.

Wie immer, es kommt drauf an. Wenn es um Performance und große Datenmengen
geht führt nicht immer ein Weg dran vorbei (alles abräumen was nicht unbedingt
notwendig ist). Die Unterscheide sind dramatisch.

Ich hab's ja jetztmal mit SQL probiert, ich merke einen deutlichen Unterschied.
Ich gewinne natürlich erheblich Flexibilität (im Moment SQlite3).

Mit gleichzeitigen Zugriffen meinte ich schreibende zugriffe und schreibende/lesende Zugriffe in Kombination.

Bei allen Lesezugriffen kann nichts anbrennen. Der Koordinationsaufwand hängt
auch davon ab, ob und wann überhaupt Änderungen an der DB vorgenommen
werden.

Kann man größere Aktionen nachts laufen lassen und währenddessen die DB
einfach sperren ist das am Einfachsten.

Bei Gästebüchern wird ja eher nicht geändert, es werden mE fast nur Einträge
angefügt, was sollte da kollidieren ? Es kann niemand einen Eintrag abrufen der
noch nicht vollständig in der DB ist.

lock() und flock() sind die Funktionen des OS, Die DB-Systeme verwenden das
auch, was sonst.

Jetzt mal beides zusammengebracht: Meine DB ist deshalb so schnell in der
Abfrage weill ich alles was mit Locking zu tun hat, rausgelassen habe. Wenn
ich ändere, wird die Datei (bzw die Dateien) exklusiv geöffnet und damit für
andere blockiert. Da das in C recht flott geht gab es da auch noch nie Probleme.
Es sind aber anwenderseitig auch so gut wie keine Änderungen notwendig, es
ist ja ein Archiv.

Es hat beides Vor- und Nachteile.

Momentan fahre ich beide Systeme parallel (in der Firma aus jeweils eigenen
Servern). Benchmarks habe ich mal vor einiger Zeit mit Btrieve gefahren, ich
müßte das auch mal mit SQLite machen.

Grüße Joe.

[philosapiens]

Hi,

meine Überlegungen bezüglich eines eigenen CMS waren ja garnicht so hoch gehängt. Ich möchte ja keine großen Datenmengen bewegen und eigentlich auch keine web2.0-Sachen drin haben. Ich wollte lediglich die Möglichkeit haben einen Artikel den man in Word geschrieben hat, vielleicht über ein text-area per copy-n-paste einzufügen und dann den Ort wählen, an welcher Stelle dieser Text veröffentlicht werden soll. Also nur die Textformatierung mit einem barrierefreien validen markup und die Verknüpfung mit der Navigation und eventuellem Eintrag in ein Inhaltsverzeichnis. Also nix Wildes. Daher meine Überlegungen das Ganze auch "nur" über txt-Dateien zu machen. Das Ganze wäre dann so etwas wie eine erweiterbare statische Seite.

Aber vielen Dank nochmals für Eure Ideen und Erfahrungsbereichte.

[laborix]

Zitat von philosapiens

... wenn ich ein Textdateien-CMS erstellen möchte, ...

Schau dir das mal an:

moziloCMS - Das CMS für Einsteiger :: moziloCMS :: Startseite

Ist nicht groß, aber ein "flat"-File CMS mit reinen Textdateien, Admin-Interface und sehr flink. Eventuell auch nur zum "abguggen"

[inta]

Zu Abgucken wären eventuell auch noch das Dokuwiki oder Flatpress geeignet.