admin files. Back in time? Or maybe a "Patched"

Posted: Sun Oct 02, 2005 12:00 pm

Hi Folks

I'm hoping Raven, Chatserv, Bob and others will throw their two cents in on this one because I'm a tad baffled about it.

As everyone knows, after Nuke 7.4, there was an architectural change in how modules locate administrative functions. While I like the structure of having case/index/links moved into a consolidated directory, I really don't like the fact that they were moved from the /admin area to exist instead inside the modules themselves.

After looking back in history, I see that not much of a stink (beyond complaining how crazy FB is) was made about this major change; however, in contemplating the impacts, I see that in fact (at least from my perspective) they are fairly substantial towards the negative.

My first and primary concern about this change is that it obviously puts administrative files and functions into the unsecured public domain. What I mean exactly is that with CGI authentication established for /admin/ you would in fact be protecting access to all administration files; however, with /admin/ files being within the module directory (instead of at for example admin/modules/module_name/etc..), you are in fact not providing that level of authenticated protection in that while Nuke should prevent access by the "if ( !defined('ADMIN_FILE') )", you are physically not protecting the scanning of those files or potentially "probing" them as they exist outside that authenticated access only space.

This could be established by defining the location of each /module/admin/ for authentication in the .htaccess, but I see that as a very poor method of control for the obvious reasons of added physical work. Additionally, it does nothing from preventing an attempted scan by robots unless again, you do more work on the robots.txt as well, and that assumes that the bots in question abide by those rules. You also potentially create more ways to accidentally ban bots.

While I understand the ease that the new structure gives everyone (for knowing where admin functions are), I (on the other hand) don't believe that knowing that these files were (as in, where they used to exist before 7.5) in the admin/modules was that big of a deal. What's more, you'll notice that FB did nothing to address base core Nuke functions such as authors, backup, blocks, etc... Those still use the old method (instead of having something like /admin/modules/authors/index.php /admin/modules/authors/case.php and /admin/module/authors/links.php

In other words, I think it would be better to standardize and consolidate ALL of these functions to use this one methodology for the reasons:
1) All administrative functions can be centrally protected via CGI or other authentication against probing and attacks.
2) Ease of robots.txt configuration to protect administrative files
3) Ease of .htaccess and Nuke Sentinel authentication protection of administration files.
4) Standardizes admin methodogies for all modules including core modules.
5) Supports the ability to have other files (beyond index.php) exist for optional administrative files, where having those files using the old methodology (pre 7.5) exist in the /admin/modules directory (versus /admin/modules/MODULE_NAME/) could be problematic.

While I realize that once again, this creates a compatability issue, I think sooner or later, this issue should be addressed, if for no other reason that it standardizes the functionality versus how this exists now (scattered and with multiple call methodologies.)

I only raise this issue because I do not think that it is proper for administrative files to exist at all in the public /modules area and I think what I am proposing addresses all of the issues as well as provides a reasonable logic for file management.

Comments?
Steph

registered · Posted: Sun Oct 02, 2005 1:32 pm

Quote:

In other words, I think it would be better to standardize and consolidate ALL of these functions to use this one methodology for the reasons:
1) All administrative functions can be centrally protected via CGI or other authentication against probing and attacks.
2) Ease of robots.txt configuration to protect administrative files
3) Ease of .htaccess and Nuke Sentinel authentication protection of administration files.
4) Standardizes admin methodogies for all modules including core modules.
5) Supports the ability to have other files (beyond index.php) exist for optional administrative files, where having those files using the old methodology (pre 7.5) exist in the /admin/modules directory (versus /admin/modules/MODULE_NAME/) could be problematic.

Since I be the NS dude I'll address the a couple of these. The first is that NSN-Nuke was the first nuke to create and use the new structure for admin files Wink

It was a bit different but you can see that it is where mr. burzi stole it from.

On the protection of /admin/ is if you add similar code to your .htaccess file:

Code:

  <Files "admin">


    <Limit GET POST PUT>


      require valid-user


    </Limit>


    AuthName "Restricted by NukeSentinel(tm)"


    AuthType Basic


    AuthUserFile /path/to/your/.staccess


  </Files>

It will protect any directory or file with the word "admin" in them not matter how deeply buried in the site it is.

Posted: Sun Oct 02, 2005 3:08 pm

Actually, I believe that to be incorrect.

The directives given within <files> will be applied to any object with a basename (last component of filename) matching the specified filename.

I do not believe the above example would block any admin directory access. Further, it wouldn't block any nuke files either, as the are no files simply called "admin." The normal use of that function would be <Files "admin.php"> or use a wildcard such as "admin.*"; however, that also doesn't solve the directory problem at hand.

To make matters worse, you can't use wildcards to protect directory access and while you can write an extended definition for the <directory> expression, it would be very complicated by the fact that the "level" of the desired protection is actually at 2 different levels as well as protecting the baseline admin.php in the root.

For example:
/public_html/admin/
/public_html/modules/MODULE_NAME/admin/

As you can't use wildcards for the physical path in the directory call, this is more complicated than someone might initially think because you are trying to protect directories where the MODULE_NAME portion of the definition is dynamic. This would mean that you would be forced to write a directive for each module directory. Again, this is why I say in the original post that it is more physical work.

This again, is why it would be nice if they all existed in one place.
That would allow the expression <directory "/PHYSICAL PATH/admin/"> to cover all admin related functions (if they were all in the admin directory) and the above "files" call (with a wildcard) would protect the admin.php or admin.html files.

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

I fully understand you concerns and have to agree at this point. I never looked at it from that perspective. Since I still use the basic v6.9 structure, I never gave it much thought. However, I like the modularization and control that the current way offers. I haven't tested this, but it seems that something like this would work in .htaccess.

Code:

<Files ~ "^admin/index.php">


   <Limit GET POST PUT>


      require valid-user


   </Limit>


   AuthName "Restricted by NukeSentinel(tm)"


   AuthType Basic


   AuthUserFile /home/username/public_html/.staccess


</Files>

Or even

Code:

<Files ~ "^admin/">


   <Limit GET POST PUT>


      require valid-user


   </Limit>


   AuthName "Restricted by NukeSentinel(tm)"


   AuthType Basic


   AuthUserFile /home/username/public_html/.staccess


</Files>