Hallo,

Also, am Anfang war es einmal ein Projekt, nennen wir es 'full'.
Die Ordnerstruktur sah so aus:
/home/full/ beinhaltet alle Seiten die direkt aufgerufen können
/home/full/lib/ beinhaltet verschiedene Klassen (wird aus /home/full/ inkludiert)

Dann sollten aus dem einen Projekt 2 Projekte werden, die hinzugekommene Version
('limited') sollte weniger Funktionen enthalten und sich ab und zu ein bisschen
anders verhalten. Jetzt hätte ich einfach das ganze 'full'-Verzeichnis kopiert
und hätte dann die Änderungen für die limited-Version hineingeschrieben.
Allerdings ist da ja nicht so elegant, da es immer noch bestimmte Codeteile
gibt, die in beiden Projekten gleich sind.

Da aber die Projekte unabhängig voneinander funktionieren sollten, kann ich auch
nicht aus /limited/ einfach /full/lib/ inkludieren. Der Weg, das lib Verzeichnis
einfach auf die selbe Ebene wie full und limited zu stellen ist sicherlich auch
nicht die Optimalste (ein anderer Benutzer, der nur die limited Version habe
will, würde sich wahrscheinlich nur den limited-Ordner kopieren das lib
Verzeichnis vergessen).

Habt ihr schon mal so ein Problem gehabt? Wie habt ihr es gelöst? Was würdet ihr
mir raten?

MfG, Johannes

Johannes Permoser schrieb:
> Habt ihr schon mal so ein Problem gehabt? Wie habt ihr es gelöst? Was
> würdet ihr mir raten?

5 Threads obendrüber würdest du "Welche Ordnerstruktur würdet ihr
wählen" finden. Denke da gibt es schon ein paar Lösungsansätze für
solche Ordnerstrukturen.

Ansonsten kann ich es dir so raten wie ich es derzeit mache (sonst würde
ich es ja nicht so machen, wenn ich es nicht für sinnvoll halten würde
^^), Details siehe im erwähnten Thread.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Am Fri, 18 Jan 2008 16:51:52 +0100 schrieb Johannes Permoser:

> /home/full/ beinhaltet alle Seiten die direkt aufgerufen können
> /home/full/lib/ beinhaltet verschiedene Klassen (wird aus /home/full/ inkludiert)

lib und include-Verzechnisse legt man besser außerhalb der
Dokumentenverzeichnisse an, damit von außen niemand darauf zugreifen kann.

Martin

Am Fri, 18 Jan 2008 16:55:08 +0100 schrieb Christoph Herrmann:

> Denke da gibt es schon ein paar Lösungsansätze für
> solche Ordnerstrukturen.

Die dort gegebenen Antworten finde ich persönlich nicht sehr
aufschlussreich. Auf Sicherhetisaspekte wird nicht eingegangen.

Wie man seine Projekte ansonsten über Verzeichnisse strukturiert ist
eigentlich ziemlich egal und vermutlich projektabhängig. Ob eine Site aus
30 oder 6.000 Dokumenten besteht, ist das schon ein relevanter Parameter.

Wer nicht Herr über den ganzen Server ist, weil er nur über einen
virtuellen Server oder Webspace verfügt, kann die Verzeichnisse nich
vollkommen beliebig anlegen.

Das wichtigste habe ich in meinem anderen Posting dieses Threads schon
gesagt. Der Rest ist wirklich beliebig. Ob man eine Hand voll css-Dateien
in ein separates Verzeichnis legt oder ist DocRoot ist wirklich von
keinerlei Bedeutung.

Martin

Martin Lemke <nospamusenet [at] maaaddin.de> wrote:

> lib und include-Verzechnisse legt man besser außerhalb der
> Dokumentenverzeichnisse an, damit von außen niemand darauf zugreifen kann.

Ein Eintrag in der .htaccess tuts auch. Entweder, man schließt ganze
Ordner damit aus, oder, generell möglicherweise sinnvoll

- .php - includierte Dateien mit Endung *.inc
- .inc in der .htaccess auf deny from all stellen.

Servus,
Konni

--
Inzwischen ohne Signatur

Martin Lemke schrieb:
> Die dort gegebenen Antworten finde ich persönlich nicht sehr
> aufschlussreich. Auf Sicherhetisaspekte wird nicht eingegangen.

Ich wüsste nicht, was eine Verzeichnisstruktur mit Sicherheitsaspekten
zu tun hat. Bei mir sind die PHP Dateien gesichert, bis auf die
"index.php" kann keine andere Datei direkt aufgerufen werden.

> Wie man seine Projekte ansonsten über Verzeichnisse strukturiert ist
> eigentlich ziemlich egal und vermutlich projektabhängig. Ob eine Site aus
> 30 oder 6.000 Dokumenten besteht, ist das schon ein relevanter Parameter.

Jep, das ist wohl der wichtigste Parameter.

> Wer nicht Herr über den ganzen Server ist, weil er nur über einen
> virtuellen Server oder Webspace verfügt, kann die Verzeichnisse nich
> vollkommen beliebig anlegen.

wüsste nicht was das eine mit dem anderen zu tun hat. ich kann auch auf
meinem Webspace 100 Ordner oder ähnliches anlegen.

> Das wichtigste habe ich in meinem anderen Posting dieses Threads schon
> gesagt. Der Rest ist wirklich beliebig. Ob man eine Hand voll css-Dateien
> in ein separates Verzeichnis legt oder ist DocRoot ist wirklich von
> keinerlei Bedeutung.

Man selbst muss auch nach Wochen noch durchblick haben und auch andere
sollten nicht Stundenlang schauen müssen wo Sie was finden, das ist das
wichtigste.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Konni Scheller schrieb:
> Ein Eintrag in der .htaccess tuts auch. Entweder, man schließt ganze
> Ordner damit aus, oder, generell möglicherweise sinnvoll
>
> - .php - includierte Dateien mit Endung *.inc
> - .inc in der .htaccess auf deny from all stellen.

Oder direkt in PHP ein Mechanismus einbauen, der verhindert, dass jemand
die Datei direkt aufruft, dann ist man unabhängiger vom Server.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:

> Man selbst muss auch nach Wochen noch durchblick haben und auch andere
> sollten nicht Stundenlang schauen müssen wo Sie was finden, das ist das
¯¯¯

Stimmt. Es würde einen schlechten Eindruck machen, wenn andere
stundenlang schauen müssten, wo und vor allem wie ich meine Dateien
finde. In der Regel brauche ich dafür auch nur wenige Sekunden.

Im Übrigen sind wir im Usenet per Du ;-)

Gruß. Claus

Christoph Herrmann schrieb:

> Oder direkt in PHP ein Mechanismus einbauen, der verhindert, dass jemand
> die Datei direkt aufruft

Hast Du dafür eine zuverlässige Lösung?

Gruß. Claus

On Sat, 19 Jan 2008 15:41:23 +0100 Claus Reibenstein wrote:
> > Oder direkt in PHP ein Mechanismus einbauen, der verhindert, dass
> > jemand die Datei direkt aufruft

> Hast Du dafür eine zuverlässige Lösung?

Bei der ueberwaeltigenden Mehrzahl aller inkludierten Programme
eruebrigt sich so eine Loesung eigentlich, da sich darin entweder nur
Funktionen befinden, oder eine Klassendefinition. Ein Aufruf wird daher,
selbst wenn er gestattet ist, nicht sonderlich viel bringen, ausser
einer komplett leeren Seite.

Selber habe ich trotzdem alle inkludierten Dateien in einem eigenen
Unterbaum zusammengefasst, der zentral mit "Deny from all" in der
..htaccess abgesichert ist.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

2008 endlose Jahre seit der Zeitenwende! Und das alles ohne Stefan.
(Sloganizer)

Stefan Froehlich:

> Ein Aufruf wird daher, selbst wenn er gestattet ist, nicht sonderlich viel
> bringen, ausser einer komplett leeren Seite.

Du behauptest also allen Ernstes, dass ein Aufruf einer *.inc Datei
unbedenklich sei?
--
Mit PHP Kontonummern auf Gültigkeit prüfen:
<http://bav.malkusch.de/>

Christoph Herrmann:

> Oder direkt in PHP ein Mechanismus einbauen, der verhindert, dass jemand
> die Datei direkt aufruft, dann ist man unabhängiger vom Server.

Ich denke das ist unmöglich.
--
Mit PHP Kontonummern auf Gültigkeit prüfen:
<http://bav.malkusch.de/>

Markus Malkusch schrieb:
> Christoph Herrmann:
>
>> Oder direkt in PHP ein Mechanismus einbauen, der verhindert, dass jemand
>> die Datei direkt aufruft, dann ist man unabhängiger vom Server.
>
> Ich denke das ist unmöglich.

if(!defined('INCLUDED')) exit(0)
über jedes include, bei dem es nicht egal ist. In der includierenden
Datei dann die Konstante setzen.
Ich spare es mir aber auch, indem ich die Daten außerhalb des
DocumentRoot halte.
Schon alleine, weil es unangenem sein kann, wenn man durch einen Fehler
in der Serverkonfig die .htaccess nicht mehr greifen (das passiert
zumindest schneller, als dass das DocumentRoot geändert wird).
Insbesondere, wenn man Konfigurationsdateien hat, die nicht in PHP sind
und damit angezeigt würden.

On Sat, 19 Jan 2008 16:14:19 +0100 Markus Malkusch wrote:
> > Ein Aufruf wird daher, selbst wenn er gestattet ist, nicht sonderlich viel
> > bringen, ausser einer komplett leeren Seite.

> Du behauptest also allen Ernstes, dass ein Aufruf einer *.inc Datei
> unbedenklich sei?

Gegeben sei die folgende Datei:

| <?php
|
| function abc($def) {
| $a = 2 * $def;
| return $a;
| }
|
| class Ghi {
| private function jkl($mno) {
| $pqr = 3 * $mno;
| return $pqr;
| }
| }
|
| ?>

Wo siehst Du das Problem, wenn jemand die Datei ausfuehrt? Was
steht in Deinen .inc-Dateien, das ein (Sicherheits- oder sonstiges)
Problem verursachen koennte?

Wie schon geschrieben, ich verbiete ja _ohnehin_ den Zugriff per
..htaccess, weil es einfach ist und weil auch der Inhalt des
Verzeichnises unter gar keinen Umstaenden nach aussen hin relevant
sein kann. Fuer so wichtig, wie sie hier oft dargestellt wird, halte
ich die Fragestellung aber bei weitem nicht.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Für die einsamen Tage - Stefan: schwimmen, welch verränktes Verzehren!
(Sloganizer)

Claus Reibenstein schrieb:
> Christoph Herrmann schrieb:
>
>> Oder direkt in PHP ein Mechanismus einbauen, der verhindert, dass jema=
nd
>> die Datei direkt aufruft
>
> Hast Du dafür eine zuverlässige Lösung?

Ganz pragmatisch: In der index.php (bzw. jedem Skript, das direkt
aufgerufen werden darf)

define( '_MY_VALID_APP', 1 );

In jedem anderen Skript

if ( !defined( '_MY_VALID_APP' ) ) {
require 'whereever/403.php';
die();
}

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Jonas Werres:

> if(!defined('INCLUDED')) exit(0)

Und wie verhinderst Du ausschließlich mit PHP, dass der Quelltext lesbar
wird?

> Ich spare es mir aber auch, indem ich die Daten außerhalb des
> DocumentRoot halte.

Das ist nicht unabhängig vom Webserver.
--
Mit PHP Kontonummern auf Gültigkeit prüfen:
<http://bav.malkusch.de/>

..oO(Konni Scheller)

>Martin Lemke <nospamusenet [at] maaaddin.de> wrote:
>
>> lib und include-Verzechnisse legt man besser außerhalb der
>> Dokumentenverzeichnisse an, damit von außen niemand darauf zugreifen kann.
>
>Ein Eintrag in der .htaccess tuts auch. Entweder, man schließt ganze
>Ordner damit aus, oder, generell möglicherweise sinnvoll
>
>- .php - includierte Dateien mit Endung *.inc
>- .inc in der .htaccess auf deny from all stellen.

Schon. Mir ist in diesem Fall aber eine solide Wand lieber als lediglich
eine verschlossene Tür. Was nicht direkt aufgerufen werden soll, egal ob
Script oder sonstige Datei, kriegt schon aus Prinzip erst gar keine URL.

YMMV.

Micha

Markus Malkusch schrieb:

> Das ist nicht unabhängig vom Webserver.

Warum denn das? Das funktioniert auf jedem. Vieleicht meinst Du ja das
Webspace-Packet des Anbieters oder die Zugriffsrechte des Mieters auf
Verzeichnisse ausserhalb von document_root. Aber mit dem Webserver hat
das nix zu tun.

> Und wie verhinderst Du ausschließlich mit PHP, dass der Quelltext lesbar
> wird?

Verstehe die Frage nicht. Wenn PHP läuft, verhindert PHP das automatisch.
Wenn man auch den Fall berücksichtigen wollte, dass PHP nicht läuft ...
naja, dann beantwortet sich die Frage auch von selbst.

Claus Reibenstein schrieb:
> Stimmt. Es würde einen schlechten Eindruck machen, wenn andere
> stundenlang schauen müssten, wo und vor allem wie ich meine Dateien
> finde. In der Regel brauche ich dafür auch nur wenige Sekunden.

Was heißt schlechten Eindruck. Wenn man im Team entwickelt oder seine
Sachen mal weitergibt ist es halt mit Aufwand verbunden jedesmal die
Sachen suchen zu müssen.

> Im Übrigen sind wir im Usenet per Du ;-)

Wenn man neben der Arbeit antwortet zwischen den E-Mails zu den Kunden
passiert das schon mal *g*. Bisher hier nen "Sie" schreiben, statt zum
Kunden "Du" und paar Minuten Chef hintendran zu haben. :)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Claus Reibenstein schrieb:
> Hast Du dafür eine zuverlässige Lösung?

1. Möglichkeit, Allgemein:

index.php:
define('INTERN', true);

restliche Dateien:
if(defined('INTERN') == false)
{
die();
}

2. Möglichkeit, die ich nutze:

/*
* Wenn die Klasse "Systemcore" nicht existiert, wurde die Datei ohne die
* Engine geladen oder direkt aufgerufen, wobei beides nicht erlaubt ist
*/
if(class_exists('Systemcore', false) == false)
{
die('no intern access');
}

Ob man bei "die()" eine Meldung ausgibt ist Geschmackssache. Es
reduziert aber die Fehlersuche, wenn man mal was vergessen hat zu
definieren oder zu laden. :)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Stefan Froehlich schrieb:
> Wo siehst Du das Problem, wenn jemand die Datei ausfuehrt? Was
> steht in Deinen .inc-Dateien, das ein (Sicherheits- oder sonstiges)
> Problem verursachen koennte?

Durch Programmierfehler könnte sowas passieren, die Wahrscheinlichkeit
liegt nicht bei 0%.

> Wie schon geschrieben, ich verbiete ja _ohnehin_ den Zugriff per
> .htaccess, weil es einfach ist und weil auch der Inhalt des
> Verzeichnises unter gar keinen Umstaenden nach aussen hin relevant
> sein kann. Fuer so wichtig, wie sie hier oft dargestellt wird, halte
> ich die Fragestellung aber bei weitem nicht.

Warum einem Nutzer erlauben Dateien aufzurufen, wenn er dies nicht
machen sollte. Und aus dem oben genannten Gründen sichere ich es lieber
ab, statt anzunehmen es sei alles sicher.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Michael Fesser schrieb:
> Schon. Mir ist in diesem Fall aber eine solide Wand lieber als lediglich
> eine verschlossene Tür. Was nicht direkt aufgerufen werden soll, egal ob
> Script oder sonstige Datei, kriegt schon aus Prinzip erst gar keine URL.

Ist nicht immer möglich. Und dass meine Sachen überall funktionieren,
sicher ich diese lieber selbst ab.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Claus Reibenstein schrieb:
>> Hast Du dafür eine zuverlässige Lösung?
>
> [snip - andere Möglichkeit]
>
> if(class_exists('Systemcore', false) == false)
> {
> die('no intern access');
> }

Kein Zugriff für Praktikanten? ;-)

> Ob man bei "die()" eine Meldung ausgibt ist Geschmackssache. Es
> reduziert aber die Fehlersuche, wenn man mal was vergessen hat zu
> definieren oder zu laden. :)

Was hat es eigentlich für einen Vorteil so ein Konstrukt in eine Datei
zu packen die nur Klassen- und Funktions-deklarationen enthält? Spart
man sich dadurch überhaupt irgend etwas, denn die Abfrage geschieht ja
zur Laufzeit, da ist ja schon alles definiert und danach kommt ja nichts
mehr in der Datei.

Ich habe schon seit bestimmt zwei Jahren keine Dateien mehr gehabt die
nicht direkt aufrufbar sein sollten und dennoch Code enthielten der
direkt ausgeführt wurde.

regards,
Jens

Markus Malkusch schrieb:
> Christoph Herrmann:
>> Oder direkt in PHP ein Mechanismus einbauen, der verhindert, dass jemand
>> die Datei direkt aufruft, dann ist man unabhängiger vom Server.
>
> Ich denke das ist unmöglich.

Wenn du darauf hinaus willst, dass man die .php Datei trotzdem noch
aufrufen kann trotz Sicherung, dann stell ich mein Satz halt etwas um:
Ich mache direkt in jede PHP Datei ein Mechanismus, der verhindert, dass
der darunterliegende Quellcode in ungewollten Fällen (Direktaufruf oder
bei mir wenn der Hauptkern fehlt) zum Ausführen kommt.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:

> Claus Reibenstein schrieb:
>
>> Stimmt. Es würde einen schlechten Eindruck machen, wenn andere
>> stundenlang schauen müssten, wo und vor allem wie ich meine Dateien
>> finde. In der Regel brauche ich dafür auch nur wenige Sekunden.
>
> Was heißt schlechten Eindruck. Wenn man im Team entwickelt oder seine
> Sachen mal weitergibt ist es halt mit Aufwand verbunden jedesmal die
> Sachen suchen zu müssen.

Wie geschrieben: Dauert bei mir i.d.R. nur wenige Sekunden. Aber darum
ging es mir eigentlich gar nicht.

>> Im Übrigen sind wir im Usenet per Du ;-)
>
> Wenn man neben der Arbeit antwortet zwischen den E-Mails zu den Kunden
> passiert das schon mal *g*. Bisher hier nen "Sie" schreiben, statt zum
> Kunden "Du" und paar Minuten Chef hintendran zu haben. :)

Wie wäre es mal mit _verständlichem_ Deutsch? Diese Wortansammlungen
sind nur schwer zu verdauen.

Hast Du eigentlich überhaupt verstanden, worum es mir ging? Hast Du
gesehen, was ich unterstrichen habe? Hast Du den Smiley entdeckt? Ich
habe nicht den Eindruck.

Gruß. Claus

Ulf Kadner:
> Markus Malkusch schrieb:
>
>>> [DocRoot]
>
>> Das ist nicht unabhängig vom Webserver.
>
> Warum denn das?

Weil der irgendwo irgendwie beim Webserver konfiguriert wird. Man kann sich
ja vorstellen, dass er so konfiguriert wird, dass es gar keine Möglichkeit
gibt außerhalb des DocRoots Dateien abzulegen.
--
Mit PHP Kontonummern auf Gültigkeit prüfen:
<http://bav.malkusch.de/>

Jonas Werres:

>> Und wie verhinderst Du ausschließlich mit PHP, dass der Quelltext lesbar
>> wird?
>
> Verstehe die Frage nicht.

Manch einer will eben vermeiden, dass jedermann seinen Quelltext lesen kann
(man denke z.B. an MySQL-Passwörter).

> Wenn man auch den Fall berücksichtigen wollte, dass PHP nicht läuft ...
> naja, dann beantwortet sich die Frage auch von selbst.

Für mich ist sie damit nicht beantwortet.
--
Mit PHP Kontonummern auf Gültigkeit prüfen:
<http://bav.malkusch.de/>

Christoph Herrmann:

> Wenn du darauf hinaus willst, dass man die .php Datei trotzdem noch
> aufrufen kann trotz Sicherung

Ich will darauf hinaus, dass Du mit PHP nicht beeinflussen kannst das die
Datei überhaupt geparst wird. Mancheiner will auch nicht seinen Quellcode
an die Öffentlichkeit preisgeben. Da sehe ich keine Möglichkeit mit PHP
alleine Schutz zu gewähren.
--
Mit PHP Kontonummern auf Gültigkeit prüfen:
<http://bav.malkusch.de/>

Markus Malkusch schrieb:
> Für mich ist sie damit nicht beantwortet.

Ich denke, wenn Dich eine Diskussion wirklich interessieren würde, dann
würdest Du versuchen, eine zu führen.

Jens Himmelrath schrieb:

> Was hat es eigentlich für einen Vorteil so ein Konstrukt in eine Date=
i
> zu packen die nur Klassen- und Funktions-deklarationen enthält? Spart=

> man sich dadurch überhaupt irgend etwas, denn die Abfrage geschieht j=
a
> zur Laufzeit, da ist ja schon alles definiert und danach kommt ja nicht=
s
> mehr in der Datei.

Da hast du im Prinzip völlig Recht. *Wenn* die Datei nur Funktions- und=

Klassendefinitionen enthält, passiert auch so nichts.

Man kann aber automatisch prüfen, ob diese potenzielle Sicherheitslüc=
ke
geschlossen ist. Eine Datei, die die magische[tm] Konstante nicht
enthält, ist suspekt und wird gemeldet. Das ist also in etwa wie mit de=
n
Nitices...

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Markus Malkusch schrieb:

> Weil der irgendwo irgendwie beim Webserver konfiguriert wird. Man kann =
sich
> ja vorstellen, dass er so konfiguriert wird, dass es gar keine Möglic=
hkeit
> gibt außerhalb des DocRoots Dateien abzulegen.

Wenn man seine Installation nicht in ein Unterverzeichnis legen und die
Domain dahin "umbiegen" kann, ist man definitiv beim falschen Hoster.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Niels Braczek schrieb:
> Jens Himmelrath schrieb:
>
>> Was hat es eigentlich für einen Vorteil so ein Konstrukt in eine Datei
>> zu packen die nur Klassen- und Funktions-deklarationen enthält? Spart
>> man sich dadurch überhaupt irgend etwas, denn die Abfrage geschieht ja
>> zur Laufzeit, da ist ja schon alles definiert und danach kommt ja nichts
>> mehr in der Datei.
>
> Da hast du im Prinzip völlig Recht. *Wenn* die Datei nur Funktions- und
> Klassendefinitionen enthält, passiert auch so nichts.
>
> Man kann aber automatisch prüfen, ob diese potenzielle Sicherheitslücke
> geschlossen ist. Eine Datei, die die magische[tm] Konstante nicht
> enthält, ist suspekt und wird gemeldet.

Dafür müsste man aber einen Parser schreiben, der alle Dateien des
Projekts überprüft.
Sowas haben wir in der Firma - allerdings aus anderen Gründen.

Wenn man sich z.B: an die Regel hält keinerlei include Dateien unterhalb
des Webroots zu halten, oder allgemein direkt ausführbaren code nur in
einer Datei zu haben, ist das imho überflüssig.

> Das ist also in etwa wie mit den Nitices...

Wieso du meinst, dass es wie mit den Notices (meinst du doch, oder?) sei
ist mir nicht ganz klar. Oder meinst du einfach es könnte ein Hinweis
auf ein zukünftiges Problem sein?

regards,
Jens

Jens Himmelrath schrieb:
> Niels Braczek schrieb:

>> Man kann aber automatisch prüfen, ob diese potenzielle Sicherheitslü=
cke
>> geschlossen ist. Eine Datei, die die magische[tm] Konstante nicht
>> enthält, ist suspekt und wird gemeldet.
>
> Dafür müsste man aber einen Parser schreiben, der alle Dateien des
> Projekts überprüft.

Ja, fast. Für eine schnelle =DCberprüfung reicht aber ein grep.

> Wenn man sich z.B: an die Regel hält keinerlei include Dateien unterh=
alb
> des Webroots zu halten, oder allgemein direkt ausführbaren code nur i=
n
> einer Datei zu haben, ist das imho überflüssig.

Das kannst du nur beeinflussen, wenn du wirklich Herr über das Projekt
bist. Bei vielen Open Source Projekten muss man die Strukturen so
hinnehmen wie sie kommen.

>> Das ist also in etwa wie mit den Nitices...
>
> Wieso du meinst, dass es wie mit den Notices (meinst du doch, oder?)

Ja, klarer Fall von "dicke Finger"...

> sei
> ist mir nicht ganz klar. Oder meinst du einfach es könnte ein Hinweis=

> auf ein zukünftiges Problem sein?

Genau das meinte ich damit.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Niels Braczek wrote:
> Jens Himmelrath schrieb:
>> Niels Braczek schrieb:
>
>>> Man kann aber automatisch prüfen, ob diese potenzielle Sicherheitslücke
>>> geschlossen ist. Eine Datei, die die magische[tm] Konstante nicht
>>> enthält, ist suspekt und wird gemeldet.
>> Dafür müsste man aber einen Parser schreiben, der alle Dateien des
>> Projekts überprüft.
>
> Ja, fast. Für eine schnelle Überprüfung reicht aber ein grep.

Spontan weiß ich nicht wie.
Wie heisst denn der Befehl um in einem Ordner sammt Unterordnern nach
Dateien zu suchen die "XXXX" nicht enthalten? Gibt es dafür einen Einzeiler?

regards,
Jens

Jens Himmelrath wrote:
>Niels Braczek wrote:
>> Jens Himmelrath schrieb:
>>> Niels Braczek schrieb:
>>
>>>> Man kann aber automatisch prüfen, ob diese potenzielle Sicherheitslücke
>>>> geschlossen ist. Eine Datei, die die magische[tm] Konstante nicht
>>>> enthält, ist suspekt und wird gemeldet.
>>> Dafür müsste man aber einen Parser schreiben, der alle Dateien des
>>> Projekts überprüft.
>>
>> Ja, fast. Für eine schnelle Überprüfung reicht aber ein grep.
>
>Spontan weiß ich nicht wie.
>Wie heisst denn der Befehl um in einem Ordner sammt Unterordnern nach
>Dateien zu suchen die "XXXX" nicht enthalten? Gibt es dafür einen Einzeiler?

grep -rL XXXX *

schöne grüße, steffen

steffen bruentjen wrote:
> Jens Himmelrath wrote:
>> Niels Braczek wrote:
>>> Jens Himmelrath schrieb:
>>>> Niels Braczek schrieb:
>>>>> Man kann aber automatisch prüfen, ob diese potenzielle Sicherheitslücke
>>>>> geschlossen ist. Eine Datei, die die magische[tm] Konstante nicht
>>>>> enthält, ist suspekt und wird gemeldet.
>>>> Dafür müsste man aber einen Parser schreiben, der alle Dateien des
>>>> Projekts überprüft.
>>> Ja, fast. Für eine schnelle Überprüfung reicht aber ein grep.
>> Spontan weiß ich nicht wie.
>> Wie heisst denn der Befehl um in einem Ordner sammt Unterordnern nach
>> Dateien zu suchen die "XXXX" nicht enthalten? Gibt es dafür einen Einzeiler?
>
> grep -rL XXXX *

Da habe ich das -L in der manpage doch gestern übersehen. Danke.

Scheint auch wunderbar zu funktionieren, nur eins irritiert mich: Dort
steht: "The scanning will stop on the first match."
Was heißt das - denn er hört ja nicht nach dem ersten Fund auf...

regards,
Jens

On Tue, 22 Jan 2008 08:50:54 +0100 Jens Himmelrath wrote:
> > grep -rL XXXX *

> Da habe ich das -L in der manpage doch gestern übersehen. Danke.

> "The scanning will stop on the first match."
> Was heißt das - denn er hört ja nicht nach dem ersten Fund auf...

Nach dem ersten Match _je_File_. Weitersuchen waere Verschwendung,
da ja ohnehin nur die Files ohne Match angezeigt werden sollen.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan: das zarte Sehnen!
(Sloganizer)

Stefan Froehlich wrote:
> On Tue, 22 Jan 2008 08:50:54 +0100 Jens Himmelrath wrote:
>>> grep -rL XXXX *
>
>> Da habe ich das -L in der manpage doch gestern übersehen. Danke.
>
>> "The scanning will stop on the first match."
>> Was heißt das - denn er hört ja nicht nach dem ersten Fund auf...
>
> Nach dem ersten Match _je_File_. Weitersuchen waere Verschwendung,
> da ja ohnehin nur die Files ohne Match angezeigt werden sollen.

*vordenkopfschlag* klar.

regards,
Jens