Prevent views being called directly (security question)

General
1

Security question: Coldbox allows to call views directly if there’s no handler present.
This basically means, if I have a file views/topsecret/supersecret.cfm I’m able to call this file directly via the url domain.com/topsecret/supersecret/.

Is there a way to prevent this file being called directly?

This is of course an extrem example, but we often splitting pages into small pieces like the navigation, footer, infoboxes, etc.
So, if someone is guessing the filename of a file as a fragment of a complete page he can see this fragment. But when this fragment requires parameters and lead to an error, because of missing parameters, there’s a chance to find out more details about the system.

Can I somehow make views a kind of “secure”?

Best
Michi

2

Good question!

  1. All production environments should reveal nothing on error pages - so that would be a priority if concerned with info leakage on error.

  2. I think it may be technically possible by ensuring there is a corresponding private handler for the view (I haven’t tried this out). But that probably isn’t practical really.

I guess it would be nice to be able to annotate a view as private - or have some convention that you can block in the URL. But I think the short answer is, no.

3

Since this is a coldbox thing, I’ll ask my question also in the cb channel. Maybe there is already an idea.

1 Like
4

Luis recommendation is cbsecurity (esp. Security Rules | cbSecurity). Which would be a really cool enhancement to Preside as a module/feature. You could do a lot of things with it.

Another approach was an application.cfm in every view folder returning a 404. But I think this doesn’t work for views that should be callable.

A way could be via naming convention. I remember, that page layouts begin wit an underscore. If the generalt handler in Preside checks for the filename and returns a 404 if the view starts with and underscore…

5

We would never be able to do that in Preside as it would be a backward compatibility problem - there is nothing stopping applications from creating public handlers that begin with an underscore.

Its a tricky one. I’m thinking though that we (Pixl8) very rarely, if ever have a public view without a corresponding handler. Potentially we could have a flag that just toggles this ability on/off. Stricky to test/know though really whether or not we actually have any of these “view file only” public endpoints.

I was thinking that it could potentially be something you did in your webserver. But again, you’d have to be sure that there were no valid public handlers/views that had underscores to start - or you would have to have more specific rules for your application to lock them down.

6

cough

	metaTags = renderView( "/general/_pageMetaForHtmlHead" );
	adminBar = renderView( "/general/_adminToolbar"        );

cough

But this is exactly what we do sometimes to split parts of the page. Even calling it with renderViewlet doesn’t change anything, because the view is rendered, if there’s no handler.

I also agree, it’s tricky. In cbsecurity Luis would do this with the following rule: { secureList : "^/views\/topsecret", match : "url" }. Having an option to secure files with a RegEx could work. Here, I’m responsible by myself for securing views. If I want to secure all vies beginning with an underscore, I can do this.
This would also be backwards compatible by leaving the regex empty.

7

These are intended to be private, so fine. What we cannot account for, is someone implementing a public view or handler that is intended as the main coldbox request event that starts with an underscore (so we can’t just make a blanket rule).

cbsecurity could work with your own rules and something we can look into adding. But I’d personally put those kind of regex rules in my webserver.

8

But intended to be private still allows calling them directly via and url (domain.com/general/_pageMetForHtmlHead). And the result of this view is outputed in the body of the generated page.

cbsecurity would be a nice addition anyway, but I agree, putting these rules in the webserver would be the better way.

9

Yes absolutely - its a problem. But I mean to say that we cannot provide any blanket rules at the core preside level.

Best I think we might be able to do is to have a feature flag that allows turning off direct view access without a handler for the main event. This will require going through Preside with a fine tooth comb and ensuring there are no views that do this.

1 Like