PHP - sind hier "Sicherheitsexperten" an Board?

[himitsu]

n'abend,

die grundlegende Basis für mein winziges (eigenes) CMS hab ich nun soweit fertig. (falls ich nich noch welche Fehler finde).

Und da wollte ich mal fragen, ob jemand hier zufällig irgendwo ein Sicherheitsproblem entdecken kann?
Jetzt kann ich ja Vieles noch problemlos grundlegend umstrukturieren.


als Zielplattform ist
PHP 5.2 (mal sehn wann auch die kleinen Server das auf schönere 5.3 umgestellt werden) und MySQL 5 vorgesehn

aktuell lauffähig:
- sperren vom direkten Ausführen von "Include"-Dateien
also aktuell noch fast alles im Scripts-Verzeichnis
(hier hatte ich auch erst die übliche Variante mit einer Konstante via DEFINE und jetzt wird es ohne externe Konstante über 'nen Stacktrace erledigt)
- Login (eingerichteter Benutzer ist "Admin" + "Pass")
- Logout
- die Sprachverwaltung
- eine dynamische Session (sie und ihr Keks wird nur erstellt, wenn sie nötig ist und ebenso auch wieder gelöscht)

noch nicht ausprobiert (aber hoffentlich lauffähig):
- Registrierung
- freischalten eines gesperrten/neuen Accounts
- neues Passwort, wenn vergessen
- die Basisverwaltung des Cronjobs
- viele Funktionen (aktuell noch, mal sehn ob ich das noch ändere), welche den Zugriff auf die grundlegenden Datenbank und Dateizugriffe bereitstellen

was noch fehlt:
- erstmal ist die Templateklasse noch nicht fertig
(drum auch billiges Echo+HTML in der Index.php)
- und erst dannach kann ich mich um den Rest kümmern
- nja und dann kommen noch so 10-20 weitere Dateien dazu, für die restlichen Funktionen (es soll ja alles klein bleiben)


Was den Dateiupload betrifft, da werden die Dateien entweder nicht von extern zugänglich sein (werden z.B. nur via readfile und vorherige Rechteprüfung freigegeben) und/oder ihre Dateinamen im Dateisystem werden geprüft und enthalten keine "bösen" Zeichen und auch die "schlimmen" Dateierweiterungen sind da nicht vorhanden (PHP hochladen und dann ausführen ist also nicht möglich)



bei den Sperren will ich noch was ändern
- also automatischer Überlasungsschutz kommt noch rein (falls unser Handy mal bei mir vorbeischaut und mit millionen Anfragen alles überlastet)
- damit verbunden auch eine etwas andere/bessere Art auf zuviele falsche Passworteingaben zu reagieren (aktuell wird nach 5 Versuchen der Account gesperrt und kann per Mail wieder freigeschaltet werden)


In dem Code hab ich die Debugausgabe aktiviert, also nicht über die Messages und den DEBUG OUTPUT wundern.
Und wie gesagt, aktuell geht es mir erstmal um die Sicherheit,
also voralem alles, welches in der Scripts/Functions.php in den Funktionen Main_GetConfigDefaults und besonders Main_Initialize behandelt wird.
Aus den Debugausgaben sollten auch alle gefährlichen Infos rausgefiltert werden.



Im Anhang liegen die Dateien
und hier hab ich noch 'nen Testserver mit den Dateien (9 MB)



Testserver:
- dort ist'n kleiner Apache, PHP 5.3 und MySQL 5.1 drinnen
- beim "installieren" entpackt der nur diese Module in sein Verzeichnis
- mein Projekt wird dann über http://localhost/Test/Scripts/Install.php5 eingerichtet
- und auf http://localhost/Test/Index.php5 liegt die Testseite

[edit]
ups, den Anhang vergessen :oops:

[fkerber]

Hi!

Sehe ich das richtig, dass du keine Prepared-Statements verwendest?
Falls dem so ist, würde ich dir raten, es so bald als möglich zu tun.

Gründe u.a.:
*) Performance-Gewinn
*) Besserer Schutz vor SQL-Injections


Grüße, Frederic

[Valle]

Hallo, :-)

ich hoffe du hast nichts dagegen, wenn ich dein CMS mal etwas genauer auseinander nehme, nicht nur bezüglich Sicherheit.:cyclops:

• das gesamte Konzept deines CMS ist leider völlig veraltete Technik und alles andere als flexibel, tut mir Leid. Du wirst mit Sicherheit Probleme damit bekommen, wenn du das intensiver benutzen willst. MVC sollte das sein, was du suchst,
• Du verwendest globale Variablen und einige Konstanten ($Config oder R_GUEST), was wie auch in Delphi nicht gerade die feine englische Art ist. ;-)
• es sind einige Rechtschreib- oder Tippfehler zu finden. Main_Fialize() oder $_SESSION['Activ'].
• du mixt sehr extrem Groß- und Kleinschreibung. Das ist nicht hilfreich für Leute, die sich mit deiner API beschäftigen wollen. In den meisten Fällen hat sich ein "allesklein" für Variablen und Funktionen bewährt. Lediglich Klassen (dazu gleich mehr) schreibt man meistens in Camel_Case.
• eine functions.php ist keine gute Idee. Mag sein, dass die Ladegeschwindigkeit erhöht wird, weil alles in einer Datei steht, aber Versionierung, logische Trennung oder einfach nur Übersicht leiden schwer darunter.
• soweit ich dein CMS verstanden habe, muss man für jede neue Seite eine neue Datei anlegen und diese mit Kopf- und Fußzeilen ausstatten. Das artet in vielen Hacks und unnötigem Copy and Paste aus. Und wehe es ändert sich mal was ...
• Die wesentlichen Config-Einträge wie MySQL-Zugangsdaten stehen in Zeile 2090! Findest du nicht, dass derartig relevante Sachen eine eigene Datei verdient haben? ;)
• es ist schön, dass du deinen Code (bzw die API) so einigermasen dokumentierst, aber mittlerweile gibt es sehr schöne inline-Dokumentationssysteme (phpDoc!), welche teilweise schon von Editoren unterstützt werden und wesentlich lesbarer und geläufiger (folglich einfacher) sind.
• du magst preg_match, oder? *g* Ein CMS sollte das möglichst vermeiden, denn es ist nicht gerade das Schnellste. Es gibt viele Stellen in deinem Code, die ein derartiges Monster an Funktionskraft gar nicht benötigen. Hier streiten sich viele (alcaeus wird gleich wieder kommen ... ^^), aber soweit ist das jedenfalls meine Meinung.
• Funtions.php5, Zeile 284; fummle doch bitte nich an den Dateirechten rum. 0777 ist ein böses Gerücht, völlig sinnlos und nicht Aufgabe des Script. Der Administrator selbst hat dafür zu sorgen, das Dateien die Rechte haben, die sie haben sollen. 0777 steht für Lese-Schreib- und Ausführrechte für jeden. Wozu muss ein Script ausgeführt werden (die werden interpretiert) und warum haben Andere Lese- und Schreibrechte darauf? ;)
• und in Anbetracht dessen müsste man noch sagen, dass dein CMS wahrscheinlich nicht Windows-Server kompatibel ist (siehe Pfadnamen und diese chmods).
• bzgl. der Sicherheit ist mir sonst noch nichts aufgefallen. Mir fällt es schwer, relevante Stellen zu finden, denn was die Verzeichnisstruktur angeht, hast du dein Projekt sehr klein gehalten.

Was ich dir noch so als kleine Anregungen sagen möchte: Schau dir doch mal MVC an. Wenn man das geschickt umsetzt, hat man eine unglaubliche Flexibilität. OOP ist leider gar nicht verwendet worden, was dank PHPs Funktionsumfang sicher Spaß gemacht hätte. Dann wäre auch ein gutes URL-Management eine sinnvolle Sache. Lieber sollte man per htaccess immer die index.php aufrufen, die dann anhand der URL die richtige Seite includet. Und letztendlich werf ich mal noch den Begriff "Autoloader" in die Runde. Kapselt man alle Funktionalitäten in Klassen, so ist ein Autoloader eine feine Sache.

Ansonsten hast du dir sicher viel Mühe gegeben und eine Menge Arbeit da rein gesteckt. Du hast viel abstrakt gehalten und dich auf die Zukunft vorbereitet. Funktionieren wird das alles sicherlich, aber Spaß macht es später eher keinen mehr. PHP kann toller sein. :-)

Wenn du noch Fragen zu den einzelnen Listenpunkten hast, dann nur her damit. Ich kann da gerne einiges genauer erläutern. :-)

Liebe Grüße,
Valle

[alcaeus]

@Valle: was soll das denn heissen? :P

Ich geb auch noch bisserl Senf dazu, allerdings ohne mir die Muehe gemacht zu haben, den Code anzusehn. Security-Reviews gibts sind dann doch etwas aufwaendiger.
Ein paar allgemeine Kommentare kann ich dir geben:

• Valle hat Recht wenn er dir MVC ans Herz legt. Nein, eine Template-Engine macht deinen Code nicht MVC-konform. Ja, ein MVC-Framework hilft dir. Ich empfehle Symfony 1.4 und Doctrine (ist in symfony enthalten) als Framework-Loesung. Damit sind auch die von Frederic angesprochenen Prepared Statements abgehakt.
• index.php5 ist eine Sache die es nicht geben sollte. index.php ist schon eher richtig - FYI: es gibt nur eine unterstuetzte PHP-Version, und das ist PHP5. Hoster bei denen Dateien die Endung php5 haben muessen, damit PHP5 greift kannst du in die Tonne kloppen. Ausserdem ist .php die Standard-Erweiterung fuer PHP-Skripte. Ich aendere doch nicht meine Apache-Einstellungen (wo PHP bei Dateien mit der Endung .php greift) um ein CMS ausfuehren zu koennen. Sorry, aber is nicht.
• @Valle: camelCase funktioniert anders. Ich empfehle uebrigens einen Blick auf die PEAR oder ZF Coding-Guidelines - diese sind akzeptierter Standard. Da stehn noch ein paar andere sinnvolle Dinge drin.
• 777 ist toedlich. Ganz ehrlich: wenn www-data irgendwo schreiben soll, machs ueber die normalen Gruppen- und Benutzer-Berechtigungen von Linux. Es gibt keinen Grund warum der mysql-Benutzer in den Apache-Skripten rumfummeln darf oder warum Dateien gar ausfuehrbar sein sollen. 644 (Files) bzw. 755 (Directories) kombiniert mit chown und chgrp sollte dein bester Freund werden.
• Um das functions.php-Beispiel weiterzufuehren: wenn du die Funktionen logisch in Klassen kapselst und mit nem Autoloader arbeitest dann sparst du dir das unnoetige Laden von zig Funktionen. Das Parsen der PHP-Dateien kostet naemlich ohne Opcode-Cache richtig viel Zeit. Wenn dein Code nur eine von 20 Klassen braucht, wird auch nur die geladen, und dann auch erst sobald sie benoetigt wird. Guck dir hierzu mal spl_autoload() an. Da ist uebrigens noch ein Vorteil von MVC-Frameworks: diese implementieren sowas bereits ;)
• Um Valle noch den Gefallen zu tun: bei der Performance-Optimierung eines grossen Ticketing-Systems haben wir uns entschlossen, ein is_preg-Flag in die Tabelle einzufuegen um so zu entscheiden ob wir per preg_match vergleichen oder per == wenn PREG nicht von Noeten ist. Das Ergebnis: der Code war nachher um den Faktor 20 (!) schneller. Muss ich noch mehr dazu sagen? :mrgreen:

Mein ganz freundlich gemeinter Tipp: guck dir mal folgende Tutorials an: A gentle introduction to Symfony und Practical symfony (for Doctrine). Sobald du mal die Vorteile des Systems gespuert hast wirst du sie nicht mehr missen wollen (ich sag nur I18N, Test-Frameworks, Routing-Klassen, CRUD-Generation, etc. :love:)

Greetz
alcaeus

[Valle]

Hallo,

ich möchte gerne noch die Sachen, welche alcaeus genannt hat unterstreichen. Hoster, die nur PHP in der Version 5 verwenden, wenn die Dateiendung .php5 ist, sind für die Tonne. Ich weiß dass es sowas noch gibt, aber der Einsatz eines längst nicht mehr unterstützen Software-Pakets ist ein Armutszeugnis für jeden Hoster...

Mit Doctrine habe ich bisher Erfahrung gemacht, was deren DB-Sachen betrifft (weiß jetzt nicht genau, ob da noch mehr dabei ist). Doctrine ist ein krasser Gegensatz zu herkömlichen Datenbank-Aktionen wie man sie so vielen PHP-Scripten kennt. Aber der Umstieg lohnt sich auf jeden Fall!

@alcaeus: Hätte ja nicht gedacht dass wir uns mal so einig sind. :mrgreen: Hatten wir uns nicht mal darüber unterhalten, dass das einsparen solcher Regular Expressions deiner Meinung nach nichts bringen würde? :gruebel:

Liebe Grüße,
Valle

[himitsu]

hab nix dageben :stupid:
@RedBox: das von alcaeus les ich mir auch gleich durch

Also MVC kenn ich noch nicht.
Hatte die letzen Jahre schon einige CMS ausprobiert und das Einzige was jetzt noch auf'm Server ist, sind eigene Sachen, ein kleines Fotoalbum und ein WordPress, welches bis jetzt als Einziges halbwegs brauchbar erschien.

Hab halt keine Lust teilweise bis zu mehreren 100 MB für ein kleines CMS zu belegen ... Einige waren zwar im Gegenzug auch sehr umfangreich, aber dafür war dann nie das zu finden, was man grade braucht.

Kennst du TikiWiki? Das "klang" nicht schlecht, war auch "leicht" Installiert, aber ich fand nichtmal raus, wie man eine neue Seite erstellte.

Ich nutze das Ganze auch vorwiegend zum Lernen (man lernt fast täglich was Neues) und ich hoffe daß (zumindestens für mich) am Ende etwas "brauchbares" rauskommt.


* es gibt doch nur eine globale Variable
die $Config und sonst gibt es maximal ein paar Konstanten

* ganz soooo flexiebel hab ich eh nie vor
(wer weiß, ob es jemals jemand Anderes, außer mir verwenden wird
und wer "mehr" will, der kann gerne eines von den teilweis 200-300 MB kleinen CMS-Packeten installieren ... da ist dann natürlich viel mehr möglich)
aber was das angeht, da hab ich mir mal ein vollkommen anderes unkonventionelles "System" ausgedacht, welches erst auf einer höheren Ebene integriert wird, mal sehn ob es dann auch

* "es sind einige Rechtschreib- oder Tippfehler zu finden"
es läuft soweit und nach sowas hatte ich noch garnicht viel geguckt (sowas sieht mal selten von alleine)

* "du mixt sehr extrem Groß- und Kleinschreibung"
hmmm?
Das mach ich überall so, also Wortanfänge groß.

* "Die wesentlichen Config-Einträge wie MySQL-Zugangsdaten stehen in Zeile 2090!"
Die stehn doch ab Zeile 18 in der Config.php, gleich der 5 Konfigurationsparameter?

* "du magst preg_match, oder? *g*"
die ein/zwei mal :oops:
ich versuche das später über die Cache wieder gut zu machen :angel2:

* "fummle doch bitte nich an den Dateirechten rum. 0777 ist ein böses Gerücht, völlig sinnlos und nicht Aufgabe des Script."
eine der Zeilen, welche ich ungefragt seit Jahren von einem Projekt ins andere kopiere.
(hatte da mal einige Probleme, daß Dateien die via FTP eingespielt wurden, nicht via PHP änderbar/löschbar waren)
PS: sowas findet man sehr oft in tausenden "Tutorials"
aber da hör ich gern auf dich

* "denn was die Verzeichnisstruktur angeht, hast du dein Projekt sehr klein gehalten"
das war Absicht.
> "Scripts" für inneren Dateien
> "Media" für die paar Bilder, CSS, JS und Co.
> "Cache" ist klar
> ein oder mehre "Files" für Dateianhänge und Co.
Cache und Files können verschoben werden (hab da z.B. auf meinem Webspaces ein nettes Verzeichnis, welches nicht via HTTP erreichbar ist)
Aber selbst wenn man darauf zugreifen könnte, dann sollte über die .htaccess alles gesperrt werden und die Dateinamen werden dort auch niemals Endungen wie .php haben. Und die index.html sollte notfalls verhindern, daß der Server einen Dateiindex bei example.com/Files/ ausliefert, falls die .htaccess versagt ... ich hoffe ja das reicht aus

* "OOP ist leider gar nicht verwendet worden"
hey, die MySQL- und die ein/zwei anderen Klassenzählen garnichts? :cry:

Und ja, ich hab mit sowas grad erst angefangen:
- Die Destruktoren lernte ich erst vor Kurzem kennen und es gefällt mir langsam.
- Variablen-Referenzen bei Parametern (vorallem in den Anfängen der Template-Klasse) sind auch nett (ebenfalls erst vor 'ner Weile kennengelernt)

Hatte mir schon überlegt die Funktionen der Funktions.php in Klassen auszulagern, aber mir fiel noch kein schönes Konzept ein. :?

* "Lieber sollte man per htaccess immer die index.php aufrufen"
Rate mal, warum es bis jetzt nur diese eine Index.php gibt?
Eventuell wird es noch ein/zwei weitere spezialiesierte Dateien geben,
und der Rest wird mir ein bissl ModRewrite-Rumgespiele über .htaccess geregelt. :stupid:

[alcaeus]

Zitat:

Zitat von Valle (Beitrag 1032458)

@alcaeus: Hätte ja nicht gedacht dass wir uns mal so einig sind. :mrgreen: Hatten wir uns nicht mal darüber unterhalten, dass das einsparen solcher Regular Expressions deiner Meinung nach nichts bringen würde? :gruebel: |

Kann mich nicht dran erinnern, in letzter Zeit warens dann doch ein paar mehr PHP-Themen als dass ich mir deren Inhalte merken koennte. Darfst aber gerne suchen wenn du magst. *gg*
Ausserdem: du musst nur oefter meine Meinung annehmen, dann sind wir uns auch einig :mrgreen:

Greetz
alcaeus

[himitsu]

@index.php5 : das ist soeine Sache, welche aktuell nicht anders ging.
.php ist noch mit PHP 4 verbunden
und PHP 5 konnte ich nur so nutzen

Aber darum hab ich es auch so geregelt, daß die Dateiendungen halbwegs flexibel sind.

[Valle]

Hallo,

@alcaeus: Nicht nötig, ist auch nicht so wichtig. :-)

@himitsu: Ich weiß gar nicht wie man auf 200-300 MB pro CMS kommt. PHP-, HTML-, JavaScript und CSS-Code ist klein und lässt sich über Packer sehr stark komprimieren. 200-300 Megabyte sind wahrscheinlich noch hunderte unnötige Design, Dokumentationen, Bilder, usw. Scheue dich nicht dafür für dein "kleines CMS" 200 PHP-Dateien und Ordner zu erstellen. Ein inode auf der Festplatte kostet nicht die Welt an Speicher. Der Aufwand eine viele tausende Zeilen große Datei zu managen schon. ;-)

Und übrigens: OOP ist für mich nicht die Verwendung der MySQLi-Klassen. OOP ist, wenn du's selber machst. ;-) Viele schöne Klassen, Interfaces, Vererbungen, Abstraktionen oder finale Klassen. Sowas macht den Reiz aus.

Ich kann dir als Referenz auch noch das Zend Framework empfehlen. Jenes ist zwar sehr langsam, als technischer Ansatz aber sicher einen Blick wert. Deren API, die abstrakte Implementation und das gesamte Konzept ist sehr gut Durchdacht und meiner Meinung nach echt lobenswert. :-)

Liebe Grüße,
Valle

[himitsu]

OK, das war vielleicht ein bissl übertrieben, aber es gibt ja einige "Webseiten", wo das ganze System, alleine schon in der Grundausstattung, mindestens 30-50 MB belegte (jedenfalls war das letztes Jahr noch so ... hab grade nachgesehn und dieses komische Joomla scheint geschrumpft zu sein :gruebel: )


Das php = PHP4 wurde damals so belassen, als PHP 5 eingebaut wurde, damit es halt keine Probleme mit alten Sachen gibt und alles Problemlos weiterlief.

Für den Webspace ist eigentlich schon lange eine Umstellung geplant.
Erstmal sehn, ob/wie ich wenigstens einige der alten Sachen so umstelle, daß sie unter PHP 5 laufen würden ... ist aber nicht mehr viel Altes vorhanden ... das ändern der Serverkonfiguration für .php = PHP5 wäre schnell erledigt, aber ich wüßte nicht, was an index.php5 soooooo schlimm sein sollte?
(wäre doch letztendlich eh hinter 'nem ModRewrite verschwunden :stupid: )

Zitat:

OOP ist für mich nicht die Verwendung der MySQLi-Klassen. OOP ist, wenn du's selber machst.

ähhhhhh?

Ich lerne grade mal die Anfänge von PHP 5 kennen ... ist nicht grade einfach das Ganze. :shock:





Aber über meine Session/Keks-Verwaltung sagt keiner was :heul:
Wisst ihr wie schwer das war die Session/Kese nur zu erstellen/verwenden, wenn die wirklich benötgt werden? (nach dem Einloggen oder Umstellen der Anzeigesprache)
Also standardmäig bekommt man von dem Script keinen Keks verpaßt. :D

Das ist mein Beitrag zur Entmüllung des Internets/Browsers. :angel: