RE: [coldbox:11952] Modules and web accessible resources

Communities ColdBox HMVC
1

So basically, we’re saying that there’s no way to make a pubicly-distributable module that you can say “just drop this in your modules folder and it is guarunteed to work”.

If you write a module that has web-accessable static content, you would have to have a caveat that says, “Please copy the following folder of images, js, and css, etc out into your web root or create a virtual directory”.

I don’t think there is any other way (short of proxying those static files via a CF page), but I just want to make sure.

Thanks!

~Brad

2

I think I have a couple of potential solutions for blocking access to
files in modules installed under the webroot:

Option 1: webserver filtering

Use .htaccess and web.config files so that webservers are directed to
block requests to certain assets.

Option 2: Application.cfc OnRequestStart interception

Install modules under the webroot. Add handling in Application.cfc
onRequestStart to redirect the user away from pages we don't want them
to be able to access. This will probably need to be a configurable
list because we would want some .cfc files to be accessible
(proxies). I might be able to place an Application.cfc file in the
module root and have that extend the base application's
Application.cfc so it could all be contained within the module. If
not, this will require the module installer to make changes to their
base.cfc.

Option 3: ColdBox interceptor

A better option might be to use a ColdBox interceptor to handle this
security and ModuleConfig.cfc can act as an interceptor, so the Module
itself could handle security for itself without the need for a
separate Application.cfc. The installer would still need to modify
the base application's Application.cfc to handle all ColdFusion
requests though, not just index.cfm. Asking the framework to process
all ColdFusion requests might have some unintended consequences
though.

Long Term: Core Framework enhancement

I think the best solution will be for ModuleConfig.cfc to have a new
group of settings that explicitly allows webAccessible content
(everything should be blocked by default) as well as a group of
settings that explicity blocks web accessible content (so you can
block a file in a package that is allowed). These settings should
accept both folder paths and file paths. Also add a setting for an
event to run when a blocked resource is requested.

I think in order for the Modules pattern to be successful it's
important to be able to install them under the webroot without
exposing everything in them.

3

I think people are forgetting one thing…

Conventions…

If you change these to suit your application, then nobody but you and anyone else who has access to your application knows your directory path.

That means your modules, handlers and everything else can’t be discovered.

In older spaghetti style code, or code not in a framework then feel free to try to hide your code.

Not to mention that even if you don’t change the conventions, the .cfc’s are governed by the application.cfc are they not?

4

Andrew,

I'm not a fan of security by obscurity.

If I browse to a .cfc file, let's say a model object in my module,
ColdFusion challenges me for the administration password. If I enter
it I get a page that documents methods, arguments, and output of the
component. We've placed our components outside the webroot. We're
looking at possibly converting to a modules architecture and it just
occurred to me that they would be accessible over the web and I
wondered if there was a way around that.

Also, I was hoping to create and release a module that could just be
dropped into any application without additional configuration.

5

Seth, you do realize that ColdBox conventions fully support moving your model, etc, outside the webroot, correct? I’ll admit to not fully reading this thread, but I’ve known Andrew for many years - if only virtually - and I know that he would never suggest security through obscurity.

Based upon the comments that I have read, I think you’ll want to look into the “AppMapping” setting. That allows you to create a mapping to your application root and then the conventions take over from there. I’m pretty sure that’s what Andrew was alluding to.

HTH

6

Seth, you do realize that ColdBox conventions fully support moving your model, etc, outside the webroot, correct?

Matt, Seth’s original post was about how to write a module that anyone can install (with minimal effort) that contains static assets (images, js, css) which needs to be web-accessible.
Seth is my coworker and we do keep almost everything out of the webroot via external locations and therein lies the problem-- your static assets are no longer web accessible wtihout asking people who use your module to create web server mappings to them. Based on that issue, Seth was exploring the option of requiring the module be IN the webroot (for the sole purpose of the assets being automatically available) and then trying to decide if that presented a security issue. (thus the discussion on securing them)

Thanks!

~Brad

7

Gotcha. I had forgotten the content of the initial post, and as I admitted, I had not fully read the thread. My apologies. I shall shut up and go back to sleep now. :slight_smile:

8

If you are challenged for a username and password, this is from the CF Administrator.

What I mean is that CB allows for the conventions to be different to what it says is the norm, and even if you you don’t change the the cfc will only ever be available to the administrator.

This maybe different if your are not using SES.

But lets say you have your models in the default convention, and you have a service in there called userService. If you try the following URL

www.mydomain.com/model/

You will get an exception error for an invalid event.

If you try

www.mydomain.com/model/userService.cfc

you will also get an invalid event

So by convention you are protected.

Now views are different, but again by convention you don’t have to follow the standar nameing convention, I don’t and nobody but I knows what these directories are, but even if someone does then again it is by convention. Just place an application.cfm in the views with a and you are protected.

I must admit this comes up every now and then, and I am convinced people think that because the cfc’s are not underneath the webroot they are not protected…

Wrong!!!

Even if you don’t use SES they are heavily protected, because any cfc that is loaded will be loaded through the application.cfc, the first thing it does is load up ColdBox and try to see if it is a known handler/action, and if it is not then bingo you get an exception error.

Views are different, but as I said you can very easily put an application.cfm in there with a and nobody will know the difference, or you could send the user anywhere you want, or just throw and error in your application.cfm

But the point is you don’t need to worry about the components or views being accessible…

So if you read threads going back almost 2 years, I made this clear then and it stands today.

And it is not security by obscurity in anyway shape or form, so why would you think it is?

9

btw I threw the challenge 2 years ago, and gave the url for anyone who can guess my conventions and get to any of the files to do so.

And not one person has been able to do so, I have seen many attempts in the logs and still yet to see one person succeed.