WBCE CMS Forum

WBCE CMS – Way Better Content Editing.

Du bist nicht angemeldet.

#1 29.08.2015 23:10:12

norhei
Developer

no direct file access

In my files i started using the variant from my fork whithout asking:

//no direct file access
if(count(get_included_files()) ==1){$z="HTTP/1.0 404 Not Found";header($z);die($z);}

In some of my forks i used this vor several reasons:

  1. It works whithout any WB_KONSTANT, so if i ever decide to change constants from WB_PATH to WBCE_PATH there is no trouble.

  2. If a page is called that schould not be found , it shall return Plain and Dirty  404 not found.

  3. It is a waste of ressource to load or include anything like an error handler or some securestuff on a page  that schould not be found.

  4. If you give a plain 404 instead of an error, its a bit harder for scripts to identify your CMS

  5. Its pretty short :-)


To be true have no idea why Lepton or DV thought they need to include some stuff in this thing.

So i asking here : "Is this ok?"
Maybe its even worth to make this the default way of handling "no direct file access".

Offline

#2 29.08.2015 23:39:59

marmot
Mitglied

Re: no direct file access

norhei schrieb:

So i asking here : "Is this ok?"
Maybe its even worth to make this the default way of handling "no direct file access".

To me this are three questions:
- how to find out if a file is included (doesn't matter to me as long as it works)
- what to do if a file was accessed directly (file not found can be a bit confusing but it's a bit more difficult for attackers to guess filenames, so once again I don't prefer something)
- because of the previous I wouldn't determine a fixed rule but if there were one I would try to follow  smile

Offline

#3 30.08.2015 07:24:23

norhei
Developer

Re: no direct file access

count(get_included_files() returns 2 ore more if there is more than the directly called file.
If it is set to one its a direct call.
That was the shortest way i found that was not using a system constant.

The only disadvantage i can think of is that the default 404 set in .htaccess will not fire. I guess thats the reason why in old WB the decided for a redirect to ../index.php  so at least it did show the startpage sooner or later in the redirect chain.

But including something like this from BC CMS does look like overkill to me. :

// include class.secure.php to protect this file and the whole CMS!
if (defined('CAT_PATH')) {	
	include(CAT_PATH.'/framework/class.secure.php'); 
} else {
	$root = "../";
	$level = 1;
	while (($level < 10) && (!file_exists($root.'/framework/class.secure.php'))) {
		$root .= "../";
		$level += 1;
	}
	if (file_exists($root.'/framework/class.secure.php')) { 
		include($root.'/framework/class.secure.php'); 
	} else {
		trigger_error(sprintf("[ <b>%s</b> ] Can't include class.secure.php!", $_SERVER['SCRIPT_NAME']), E_USER_ERROR);
	}
}
// end include class.secure.php

Maybe Webbird can tell us a few words about this.
As i am always trying to figure out what was done why, either in old WB and in its forks.

Offline

#4 30.08.2015 09:02:21

cwsoft
Mitglied

Re: no direct file access

Either stick to ../index.php or use your approach. Agree the Lepton reverse search shouldn't be default. However I really like the if not defined WB_VERSION because off it's clarity and more explicit character. The WB_VERSION can easily replaced with any other constant in all index.php files with a simple Editor like Notepad++ or Sublimetext with one simple search and replace call. Just my two cents.


Account inactive since 2018/11/17.

Offline

#5 30.08.2015 20:50:57

norhei
Developer

Re: no direct file access

Agree the Lepton reverse search???
Can you tell me more about ?

Offline

#6 31.08.2015 09:29:15

webbird
Administrator

Re: no direct file access

The class.secure.php adds some protection, as mentioned in the comments. For example, it does not allow to include the config.php directly, except it's explicitly allowed. L* 1.x used to have the list of files that are allowed to include the config.php directly in the class.secure.php, while BC has a database table and registration interface for this. Dunno about L* 2.x.

Yes, I know the code seems to be overkill, we often discussed it "then". But it's also safe (works for) for WB, L* and BC, and does some more than only checking a constant.

Dunno why it should be secure to check for "any" included files...


Ich habe eine Amazon-Wishlist. wink Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

#7 07.09.2015 15:52:58

cwsoft
Mitglied

Re: no direct file access

If we use a class to secure WBCE, I would prefer an autoloader. For direct file access, I would stick to the constant.


Account inactive since 2018/11/17.

Offline

#8 21.09.2015 10:45:13

norhei
Developer

Re: no direct file access

We basically got two problems:

  1. We need to identify if a file is included or not.

  2. We need to decide what to do as a result of this.


1. We need to identify if a file is included or not.
The most simple way to solve this is use a Websitebaker constant and check for its presence.

if (defined('WB_PATH')){} //Websitebaker
if (defined('CAT_PATH')){}//Black Cat

Advantage is that we check for inclusion and for presence of WB(CE).
Disadvantage is that we need to change tons of files if we ever decide to rename that Constant not just corefiles but an endless number of module files that rely on this too. Plus the class or whatsover is only functional if WB is present

The second way is to do a plain check for inclusion:

if(count(get_included_files()) ==1){}

Advantages are, functional in any enviroment(portable, especially usefull for classes), renaming constants has no effect(easy to maintain).
Disadvantage, cannot find one...


2. We need to decide what to do as a result of this. 

One thing i really don't like is having an endless header in almost any file. But to be true it would be really nice to have a way to do  more than just got to Index.php or print  404, especially as this 404 wont comply whith the custom 404 page possibly set in the .htaccess, as it is set after .htaccess is processed.

On a direct call of the file we lack all information that we could use to target any usefull inclusion, so a search like that one used in BC or maybe Lepton is the only way to include another file that handles the 404 or the error message or whatever.  Inclusion of some file from the web isn't a good idea either as  fopen/curl nay not be allowed. The only compromise i see is compressing the code so that i fits into a maximum of 1-2 Lines of Code.

Example:

// redirect invalid file acces to 404.php or maybe another handler if present, else die 404
if(count(get_included_files()) ==1){
    function i ($f=__FILE__) {
        $f=dirname($f); $p=$f."/404.php";
        if ($f=".") {$z="HTTP/1.0 404 Not Found";header($z);die($z);}
        if (is_file($p)) include ($p);
        i ($f);
    }
    i();
}

// COMPRESSED

// redirect invalid file acces to 404.php or maybe another handler if present, else die 404
if(count(get_included_files()) ==1){function i($f=__FILE__){$f=dirname($f); $p=$f."/404.php";
if($f="."){$z="HTTP/1.0 404 Not Found";header($z);die($z);}if(is_file($p)){include ($p);exit();}i($f);}i();}

 

Disadvantage, it looks ugly.
Advantage, it opens the path to a lot of new options. (full custom 404, log attacks, customised error handling.)


Other options how to handle the access to a file that should not be accessed are:

die("Cannot access this file directly"); 

The worst of all:

  • Nonsense page gets listed in Google.

  • Gives information about CMS used(hey we found a system file)

  • Nothing ussefull is displayed for the user

header("Location: ../index.php");
header("Location: /foo.php",TRUE,301); // this is even better
  • Index Page is shown and index page is listed in google.

  • Still gives information about the CMS as you can easyly test the response on a automated way.

  • The Startpage is displayed, this is far more usefull to the User.

$z="HTTP/1.0 404 Not Found";header($z);die($z);
  • Google does not list this page.

  • Only scenario this gives information is when we use custom 404 in .htaccess

  • No usefull information to user, but do we want give usefull information to an attacker?


Opinions please!

Offline

#9 21.09.2015 17:30:29

cwsoft
Mitglied

Re: no direct file access

Ich präferiere die einfachste und explizite Lösung: WB_PATH gefolgt von einem einfachem die; ohne Text und einer robots.txt im Rootverzeichnis der alle Systemordner einschliesst.

Die Pseudosicherheit erhöht sich nicht durch irgendwelche Verschleierungstaktiken, da der HTML Code einer mit WB generierten Seite das verwendete CMS recht schnell erkennen lässt, z.B. durch die eingebundenen CSS und JS Dateien. Und Notfalls definiert man halt ne WB_PATH, also auch kein Problem.

Wenn einer ein CMS angreifen will, schaut er im Quellcode nach möglichen schwächen, die meisten sind ja Open Source.

Beitrag geändert von cwsoft (21.09.2015 17:33:05)


Account inactive since 2018/11/17.

Offline

#10 21.09.2015 18:31:39

norhei
Developer

Re: no direct file access

Bei der Sicherheit geht es einfach drum mit Informationen geizig zu sein , es wird immer möglich sein ein CMS zu identifizieren, aber die Frage ist mit welchem Aufwand. Es wäre schon sinnvoll die Identifizierungsmerkmale langsam einfach mal verschwinden zu lassen.(wenn man grade die Gelegenheit hat)

Persönlich würde ich im Moment  1. mit der unabhängigen Variante bevorzugen, da es einfach auf lange Sicht Arbeit spart und bei der 2 vermutlich den redirect , und die komplexe Variante erst später.  Allerdings nicht wegen der Sicherheit , sondern wegen Google (ist nicht schön wenn leere Seiten oder ne Fehlermeldung im Index stehen, ja das führt auch zu Abwertungen) Wer schon mal den Sitemap Creator von Google probiert hat, weiß auch das der ALLE Dateien indexiert. Und wenn ein User mal bein Link eingeben den Dateinamen vergisst, landet er zumindest auf der Startpage . Aber garnichts ausgeben ist wie Du ja schon oben Lesen konntest die schlechteste aller möglichen Lösungen.

Nachtrag
Und dann vor allem in allen Dateien einheitlich, damit man alles weitere mit Seach and Replace erledigen kann.

Beitrag geändert von norhei (22.09.2015 08:11:37)

Offline

Fußzeile des Forums

up