I see us having several options, here:
1. Disable this feature
2. Make this feature optional and configurable, with the default being /disabled/
3. Lock-down the process that allows certain paths to protect the webapp when this feature /is/ used
I think that #2 is a good idea in general: I suspect that most people don't actually use this feature, so disabling it will certainly eliminate this attack vector.
#3 might be touchy, since any file in a webapp - not just in WEB-INF or META-INF - could potentially be sensitive. It's a reasonable assumption that things in WEB-INF and META-INF should be protected by this particular feature, but it might not be straightforward since the "layout" directory is relative to the webapp, and then the layout selected by the request parameter will be relative to that. We may have to normalize the path and then compare it to known "sensitive" path prefixes. I'm not sure how to get the container to normalize a path for us, though. Maybe we just need to look for ".." in the layout name and ignore anything that looks like that. Suggestions are certainly welcome.
Certainly, templates or servlets, etc. themselves need to be exempt from these measures in case programmers want to use templates that are outside the norm: these security rules should probably only be applied when the layout is being selected from the request parameters. Request attributes, for instance, should be considered trusted.