Luis, it probably wouldn’t hurt putting into the examples or main application.cfc, some newer developers to ColdBox might not think you can lock it down further.
Regards,
Andrew Scott
I try to use a cdn for the CSS and images. Pricing is so reasonable
and it really adds value to the user. In Portal (GutHub) you can see I
have a cdn folder. When deployed to the server those assets elk be
pushed to the cdn and unavailable on the production box.
I control the cdn path via an environments function in the ColdBox cfc.
Aaron Greenlee
http://aarongreenlee.com/
Twitter: aarongreenlee
@Andrew:
Re custom conventions and/or custom logic in Application.cfc, please
see my post to this thread beginning with '@Louis'.
Re onError as a way to cover these crashing urls, I personally don't
think that's a better idea than not allowing known invalid urls to run
in the first place.
Re SES, ColdBox SES only comes into play when ColdBox runs, which with
the default Application.cfc, it doesn't if a site visitor hits a cfm
directly.
Re web server rewrite rules, you could definitely tighten things up
with rewrite and/or access control rules. I personally prefer having
as much of the application's logic as possible in the application
itself, not the environment.
Anyway, as I said in the '@Louis' post, the point isn't that there
aren't ways to deal with this, it's that the default Application.cfc
has some IMO undesirable behaviors that aren't discussed in the docs
and that you might want to be aware of. It's also that since the
default Application.cfc is generated by ColdBox, it might be good if
there was a app-creation option or documented alternate version that
worked differently in this respect.
To put it differently, I'd suggest that the defaults should reflect
common best practices. The ability to gradually convert a legacy site
to ColdBox is definitely valuable, but probably not the mainstream
case.
Dave
Den, if the Apache root is the pub dir of this app, how to you set up
multiple apps, some of which may not involve ColdBox or even CF at
all? Each app as its own named virtual host, so you hit them as
http://someapp.myserver.com? Alternatively you could start with a
default deny rule, and add allows for each app's pub directory or
equivalent.
Just wondering how you typically do this. Thanks,
Dave
This focuses on CFML, but the concepts are applicable for PHP, etc.:
I generally use named VirtualHosts, tho most apps have their own WAR
context, so I'm not forced to give them their own vhost
(blah.com/oneapp, blah.com/anotherapp, or just blah.com). I use
mod_proxy_ajp + rewrites to let Apache serve static content and only
forward certain requests to the CFML app.
For local development, I have a modified Jetty context +
URLRewriteFilter, that allows me to replicate this behavior without
needing apache + vhost entries, tho the build script allows me to add
them easily when I want/need to. I'm a project whore, so this gives
me the flexibility to quickly be up and running. =) Great for
sharing projects / getting new devs rolling without fuss, too.
The Apache ServerRoot is an empty dir that I deny access to, same as
the default vhost, in case anything slips through.
Since I use a script for generating & adding the vhosts, I have an
include from httpd.conf to a httpd-cfml.conf file, which then includes
the application's httpd.conf, which I store in the application's
conf/httpd/${build.type}/appname.conf file (generated from a
build/conf/appname.conf template). I'm a big fan of includes, so
generally it actually goes a bit further, ex:
conf/httpd/prod/rewrites.inc
conf/httpd/prod/appname.inc (includes rewrites.inc)
conf/httpd/prod/appname.ssl.inc (vhost includes appname.inc)
conf/httpd/prod/appname.conf (includes appname.inc and optionally ssl.inc)
Using includes generally limits the number of places I need to change
things to a 1:1 ratio.
I use build properties and build "types" (bundles of properties), so
it's pretty easy to customize things like server httpd.conf locations
for the various build types, or even pass them in on the command line
while running the build target (it's all Ant based).
Long and short of it is, 99.9% of everything is stored with the app,
and the build script + build properties adds the flexibility to do
deploy it however needed.
Further, 99.9% of all my applications are projects-- as apposed to
having one project with several applications.
All this has evolved over the years, and I like it, personally. YMMV. =)
:Den
Guys, I already have enough on my plate for 3.0.0 so can I delegate this to the group please?
Can somebody create a simple security in the Application.cfc template, test it and push it back to us? This would be of great help. We can also code review it here in this thread if necessary.
So here are the specs:
- Add to the Application.cfc template a way to lock down the folders used by the conventions:
- handlers, config, views, layouts, plugins, modules, interceptors
- Add an easy way to remove/add to this secured folder list from the Application.cfc
Luis F. Majano
President
Ortus Solutions, Corp
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
(Mine is a little custom, but)
Why not just do:
if(findNoCase(‘index.cfm’, listLast(arguments.targetPage, ‘/’)))
{
//Reload Checks
reloadChecks();
processColdBoxRequest();
}
else
{
abort();
}
What else do you need?
Mark
Then you are more than welcome to try to guess my views on my blog then, if
you don't know the conventions path then you are not going to be able to
view my views. That was the point I was trying to make, although if you
don't change the error pages to remove the information guessing becomes a
little easier.
And I stand by that statement as well, although I have used custom code in
the Application.cfc before to lock the site down further so that only
ColdBox events/handlers could be run it was a no brainer to add.
Regards,
Andrew Scott
http://www.andyscott.id.au/
From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of Dave Merrill
Sent: Tuesday, 9 November 2010 11:13 PM
To: coldbox@googlegroups.com
Subject: Re: [coldbox:6633] Re: ColdBox allows direct access to cfm files
anywhere in your app@Andrew:
Re custom conventions and/or custom logic in Application.cfc, please see
my
post to this thread beginning with '@Louis'.
Re onError as a way to cover these crashing urls, I personally don't think
that's a better idea than not allowing known invalid urls to run in the
first
place.
Re SES, ColdBox SES only comes into play when ColdBox runs, which with the
default Application.cfc, it doesn't if a site visitor hits a cfm directly.Re web server rewrite rules, you could definitely tighten things up with
rewrite and/or access control rules. I personally prefer having as much of
the
application's logic as possible in the application itself, not the
environment.
Anyway, as I said in the '@Louis' post, the point isn't that there aren't
ways to
deal with this, it's that the default Application.cfc has some IMO
undesirable
behaviors that aren't discussed in the docs and that you might want to be
aware of. It's also that since the default Application.cfc is generated by
ColdBox, it might be good if there was a app-creation option or documented
alternate version that worked differently in this respect.To put it differently, I'd suggest that the defaults should reflect common
best
practices. The ability to gradually convert a legacy site to ColdBox is
definitely
Mark,
ColdProxy.cfc calls will be blocked/aborted as well then when using
your statement.
So I think you just return json data in your handlers when using ajax right?
Ernst
I must admit I am not Mark, but can I ask a silly question what is the
ColdBoxProxy actually for. I have never used it in any of my remote calls,
and to date still don't see the need to either.
Regards,
Andrew Scott
http://www.andyscott.id.au/
From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of Ernst van der Linden
Sent: Wednesday, 10 November 2010 11:06 AM
To: coldbox@googlegroups.com
Subject: Re: [coldbox:6665] Re: ColdBox allows direct access to cfm files
anywhere in your appMark,
ColdProxy.cfc calls will be blocked/aborted as well then when using your
statement.
So I think you just return json data in your handlers when using ajax
right?
Ernst
> Then you are more than welcome to try to guess my views on my blog
> then, if you don't know the conventions path then you are not going to
> be able to view my views. That was the point I was trying to make,
> although if you don't change the error pages to remove the information
> guessing becomes a little easier.
>
> And I stand by that statement as well, although I have used custom
> code in the Application.cfc before to lock the site down further so
> that only ColdBox events/handlers could be run it was a no brainer to
add.
Andrew,
There are different ways to get data out of a ColdBox application. One
option is calling a handler which returns data and the other is though
the colboxproxy.
I use the coldboxproxy a lot to render (query/struct) data e.g.
calling a method, pass in a return format and the proxy converts the
data to the requested format (xml/json)..
So you don't need to change anything if you have a Flex frontend.
For ajax calls which should return html, I use the handler option.
Ernst
Yeah see I do the same thing, but I use an API when it comes to Flex and the
API is an event that is a wrapper to the correct handler.
So I guess I am proxying the event, but not using the ColdBoxProxy, so I
stand by what I said I still don't see a use for it.
Regards,
Andrew Scott
http://www.andyscott.id.au/
From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of Ernst van der Linden
Sent: Wednesday, 10 November 2010 11:38 AM
To: coldbox@googlegroups.com
Subject: Re: [coldbox:6667] Re: ColdBox allows direct access to cfm files
anywhere in your appAndrew,
There are different ways to get data out of a ColdBox application. One
option
is calling a handler which returns data and the other is though the
colboxproxy.
I use the coldboxproxy a lot to render (query/struct) data e.g.
calling a method, pass in a return format and the proxy converts the data
to
Mark's version is close to what I was thinking. But we want to make
this configurable, yes? As an API, how about these new configs, with
their defaults:
<Setting name="AllowedFiles" value="index.cfm"/>
<Setting name="AllowedDirectories" value="remote,test"/><!--- are
these right? --->
If that was the plan, it'd probably be best to resolve all these items
to absolute paths at startup, then if I'm not mistaken (untested):
- Matching an allowed file would be listFindNoCase(allowedFiles,
COLDBOX_APP_ROOT_PATH & arguments.targetPath)
- Matching an allowed directory would be
listFindNoCase(allowedDirectories, COLDBOX_APP_ROOT_PATH &
getDirectoryFromPath(arguments.targetPath, '/'))
May need normalization of leading and trailing slashes and slash
direction. Should also optimize this to only do the respective tests
when AllowedFiles or AllowedDirectories aren't empty string.
I'm not sure about ColdProxy.cfc (haven't used it yet), but it sounds
like that should be allowed too. What exactly does that mean, proxy
users, that we allow anything the 'remote' directory? That's where the
above default for AllowedDirectories came from.
Thoughts?
Dave
Actually, that implementation is goofy.
Don't resolve to absolute paths, just leave them as they are except
for slash normalization, then (still untested):
- Matching an allowed file is listFindNoCase(allowedFiles, arguments.targetPath)
- Matching an allowed dir is listFindnoCase(allowedDirectories,
getDirectoryFromPath(arguments.targetPath, '/'))
Dave
how about these new configs, with their defaults:
You're right on all counts Brad, as usual.
For simplicity's sake, I was assuming only file and dir whitelists,
figuring that the folks integrating legacy apps appear not to have a
problem with things being wide open, so they'd leave both configs
blank, or blow this off and code their own.
Re settings not being available early, I figured it was ok to at least
init CB if needed, even on requests it wasn't going to process. A more
conservative and simpler approach might be to just set them in the
variables scope of Application.cfc, though that's kind of funky and
not like any other CB configs.
Re wildcards, I dunno. I'd hate to try a bunch of regex matches on
every request, but it certainly gives you more flexibility. My gut was
that a) in most cases there weren't a whole ton of specific files that
need to be accessible, and b) allowing spec'd directories covered many
of the cases where there were "classes" of accessible files
(remote...).
So like many things, it's a trade-off of simplicity and performance vs
generality. Maybe this really is something people have to hand code
for themselves according to their needs. If that's the case, maybe
having the docs alert people to the behavior and suggesting some
alternatives would be enough.
My suggestion still stands though, as a default approach that suits
many situations. Any other feedback?
Dave
Lol there goes simplicity out the window
Yeah… this is so much easier to manage through either .htaccess , or web server config… or even just dropping some Application.cfm’s with in them in certain folders.
IMHO this feels like a square peg in a round hole.
Mark
I wonder if it's because I'm new - that I pay heed to what Mr. Andrew
Scott says (oops, sorry Andrew - old habbit). 
He is right on several points. The mapping "answer" is the best
answer for concerns about "direct access to cfm". It's not exposed if
they can't find it.
I would encourage more people to google him and what ever CF problem
you may have. I have used (and continue to use) several of his
tutorials for my current project (which is just about done). His
tutorials are simple enough for me - that's means anyone can
understand them.
NOW, SINCE IT SEEMS WE GOT OF TOPIC, with "added security" .......
I offer you'all this ... Don't know if this will help, but here it
is ...
I have no idea if these steps are redundant.
I have no idea if some of these don't work.
All I know is that I sleep better at night with them active.
Remember, since I'm new to this realm - it's real simple.
1. I invoke my own Master Security cfc within "handlers.Main.cfc".
1. More specifically, I put it within this function
⁃ ... cffunction name="onRequestStart"
2. I put an Application.cfc within the directories with cfm's I
wanted to protect.
3. I put a crossdomain.xml within the directories with cfm's I wanted
to protect.
4. I put a "web.config" in the root directory.
My "Master Security cfc" can be and do - anything I want.
I am sure that I may have missed some things, but be kind - I am a
convert from php/Flex/AS3 along with desktop applications.
Thanks Rus I do my best to keep them as simple and quick as possible, sometimes it is not always possible.
I would like to add I am not against the locking down in the Application.cfc, but so far I don't see a solution that is going to please everyone. I think the best overall solution is to document it, and give some brief and simple examples. I sort of like the idea of locking/unlocking complete directories, but the approach might not be appealing to others either.
Because at the end of the day it really only needs to be as simple as Mark had described earlier.
Regards,
Andrew Scott
http://www.andyscott.id.au/