2

I'm realizing that I have a bit of a security hole on my sites, specifically when it's in development mode.

The problem is that you can access the User Guide / API Browser without being logged in. Now the User Guide isn't a big deal, but the API Browser is a bit of a concern as all of my code is visible through it. I'm a bit concerned because some of my development sites are available publicly so others can access then (although they've blocked from being indexed).

I've taken a look at Controller_Userguide and it isn't extended from another controller as other controllers as (such as template). Instead it's the final controller. This being the case doesn't allow me to extend the controller at and something to the before() method.

I thought of excluding the module when users aren't logged in, but I can't because the auth module isn't loaded yet.

I am already only including the user guide (and other modules) when on the development site, so this helps, but I wouldn't call this security.

Any other ideas on how to accomplish this?

Darryl Hein
  • 142,451
  • 95
  • 218
  • 261

1 Answers1

2

Is there any reason to allow logged in users to view the userguide?

I would add something like this to the bootstrap

//Add modules that are only relevant to local development
if(Kohana::$environment == Kohana::DEVELOPMENT)
{
    Kohana::modules(array_merge(Kohana::modules(), array(
        'codebench'  => MODPATH.'codebench',  // Benchmarking tool
        'userguide'  => MODPATH.'userguide',  // User guide and API documentation
        'unittest'   => MODPATH.'unittest',   // Unit testing
    )));
}

then any public facing sites just change the $environment to something else like STAGING or TESTING

Kohana::$environment = Kohana::TESTING //In the bootstrap file

Alternatively

SetEnv KOHANA_ENV TESTING //to the .htaccess file

OPTION 2 - Load the auth module first

I've just tried this, seems to work for me. In your bootstrap file, load the modules like this:

/**
 * Enable modules. Modules are referenced by a relative or absolute path.
 */
Kohana::modules(array(
    'auth'       => MODPATH.'auth',       // Basic authentication
    'cache'      => MODPATH.'cache',      // Caching with multiple backends

    'database'   => MODPATH.'database',   // Database access
    'image'      => MODPATH.'image',      // Image manipulation
    'orm'        => MODPATH.'orm',        // Object Relationship Mapping
));

//Add modules that are only relevant to testing
if(Kohana::$environment == Kohana::DEVELOPMENT and Auth::instance()->logged_in())
{
    Kohana::modules(array_merge(Kohana::modules(), array(
        'codebench'  => MODPATH.'codebench',  // Benchmarking tool
        'userguide'  => MODPATH.'userguide',  // User guide and API documentation
        'unittest'   => MODPATH.'unittest',   // Unit testing
    )));
}

Option 3 - Isolating the API browser

There is a config option in the userguide config:

// Enable the API browser.  TRUE or FALSE
    'api_browser'  => TRUE,

which you could set to false if the user isn't logged in, similar to the loading of the modules above. The is currently a bug with it that crashes the userguide template because it can't find the route to the API.

IF you want to go to the effort to get this to work (until there is an update), then copy /modules/userguide/views/userguide/template.php to /application/views/userguide/template.php and then replace lines 28 to 30 with this:

<li class="api">
    <a href="<?php echo (Kohana::$config->load('userguide.api_browser') === TRUE)?Route::url('docs/api'):'#'; ?>"><?php echo __('API Browser') ?></a>
</li>

and put this in /application/config/userguide.php:

<?php defined('SYSPATH') or die('No direct script access.');
$config = array();
if(Kohana::$environment == Kohana::DEVELOPMENT and Auth::instance()->logged_in())
{
    $config['api_browser'] = FALSE;
}
return $config;
Cubed Eye
  • 5,581
  • 4
  • 48
  • 64
  • I do this already, but my concern is that if the development site is available publicly then the user guide (and the others) are also accessible publicly (along with all my proprietary code for clients). – Darryl Hein Mar 27 '12 at 06:48
  • only if the environment is set to development though, if it not then the userguide module is never loaded, thus anyone can't get access to it – Cubed Eye Mar 27 '12 at 06:50
  • Maybe I'm confused, but in my case, the development site is public so anyone can access the user guide and API browser. Here's an example of someone else's API browser that's public on his dev site: http://dev.morgan.ly/kohana/v3.2/guide/api/Deputy (and indexed by Google). – Darryl Hein Mar 27 '12 at 06:53
  • Your addition only hides the link, it doesn't block access to the API. Big difference between hiding the link and actually blocking access. – Darryl Hein Mar 27 '12 at 06:55
  • Option 1 is pretty much the same thing. Still totally accessible to the public on dev. Sadly, this is why I'm asking the question. – Darryl Hein Mar 27 '12 at 07:05
  • Have you change the `Kohana::$environment` variable on the public sites, because if it's not Kohana::DEVELOPMENT it shouldn't load the userguide module at all. Which means noone should have access to it – Cubed Eye Mar 27 '12 at 07:07
  • My production sites are set as Kohana::PRODUCTION as they should be and the user guide is not accessible on this. But this is *not* the problem. The problem is on my *publicly accessible* development sites. Here, anyone that knows the address can access the user guide. – Darryl Hein Mar 27 '12 at 07:10
  • Kohana also has Kohana::STAGING and Kohana::TESTING as $environment options for this purpose. We use Kohana::STAGING when the site goes on to the public accessable sites before production so that we can remove the loading of userguide/unittest/codebench from the bootstrap that's what the code above does for us. – Cubed Eye Mar 27 '12 at 07:14
  • Sorry Cubed Eye, I'm not sure you're understanding. On a dev site, the user guide is still accessible without authenticating (by logging in). Your suggestions don't solve this. – Darryl Hein Mar 27 '12 at 07:15
  • I'm still going to hold out for something better (or a revision to the user guide), but this does work. – Darryl Hein Mar 27 '12 at 08:08
  • 1
    The DEVELOPMENT environment is not made for just development sites. Its purpose is for sites which are local or accessible from a private network and are not publicly accessible. You should not set environment to development on any publicly available sites. You should stick with Option 2 and create a more robust check which suits your needs. – Haralan Dobrev Apr 03 '12 at 19:26