Tony Collen wrote:
Browsing the livesites, on a whim I tried this URL:
http://dir.salon.com/?cocoon-view=content
and it worked! Obviously someone deploying Cocoon should be aware that this view is "on" by default, and may reveal data in your page you might not want. I have yet to see "bad" data get exposed, but there's always the possibility.
Well, the cocoon "view" was designed to be a standard way for external crawlers or spiders to gather 'semantically meaningful' data from URLs served by cocoon.
yes, there is the possibility of bad data exposed.
Do we want the views turned off by default, and have a message in the sitemap about enabling the views? Would it make more sense to have thename of the "cocoon-view" parameter be able to be changed via configuration? Say I wanted the parameter to be my-view instead of cocoon-view. Security through obscurity?
Ok, some thoughts:
1) security thru obscurity is bad habit and we should avoid this.
2) views do not cause a security problem for someone that *knows* what views are and why they are there
3) but I agree that not many do.
4) if we make that parameter configurable, the *WHOLE* point of having views disappears since crawlers don't have a way to tell how to ask for a specific view.
NOTE: a crawler should be allowed to ask for a specific view setting an HTTP header in the request. The use of the 'cocoon-view' parameter is a hack. We are aware of this. It's a hack because no browser allows you to set the http headers directly, nor there is a portable way to do this via javascript. Since views are useful for debugging, we allowed this way of asking for views.
So, at the end, I would do:
1) turn off views from the default sitemap. NOTE: this will turn off the ability to make static snapshots of your webapp from the cocoon CLI!
2) write a pretty detailed comment in the default sitemap telling what views are, how they work briefly and what potential security issues do they make.
3) keep the view parameter name hardcoded as it is.
Thoughts? anybody against this?
What about simply adding an IP matcher in the view that would restrict access to the view to a reserved set of clients (localhost by default), and direct others to a nice page, or simply a 404 error ? This would leave the door open to local debugging and crawnling, and would firmly close it to remote "attacks".
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
