How to stop users accessing templates directly

[Pe...@blm.gov]

My web app uses the Velocity View Servlet with a mapping "*.vtl" (I use
.vtl in preference to .vm for my templates; .vm I reserve for VelociMacro
files). Users should be accessing the system with URLs with the pattern
"*.do", which maps to Struts. The Struts ActionForwards then reference
*.vtl URIs for the presentation step. All fairly straightforward, I think.

The problem is, what's to stop a user typing in the name of one of my .vtl
templates directly into their browser address bar? (or maybe worse,
generating a POST request that contains all the context data so that it
appears to render correctly)?

There must be a way to secure this. A Filter or Valve, maybe? (The webapp
will be deployed on Tomcat 5.0, 5.5 and possibly 6). What do people here
do?


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org

Re: How to stop users accessing templates directly

[Nathan Bubna <nb...@gmail.com>]

We use Spring Security (aka Acegi), but a simple Filter could do this too.

On Fri, Aug 22, 2008 at 9:17 AM,  <Pe...@blm.gov> wrote:
>
> My web app uses the Velocity View Servlet with a mapping "*.vtl" (I use
> .vtl in preference to .vm for my templates; .vm I reserve for VelociMacro
> files). Users should be accessing the system with URLs with the pattern
> "*.do", which maps to Struts. The Struts ActionForwards then reference
> *.vtl URIs for the presentation step. All fairly straightforward, I think.
>
> The problem is, what's to stop a user typing in the name of one of my .vtl
> templates directly into their browser address bar? (or maybe worse,
> generating a POST request that contains all the context data so that it
> appears to render correctly)?
>
> There must be a way to secure this. A Filter or Valve, maybe? (The webapp
> will be deployed on Tomcat 5.0, 5.5 and possibly 6). What do people here
> do?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org

Re: How to stop users accessing templates directly

[Pe...@blm.gov]

The application is designed to be self-contained, i.e. that we don't rely
on having Apache on the front. That's not to say that we can't or wouldn't
put Apache into the mix but in general we've found that Tomcat can handle
things using Filters and a properly thought out
server.xml/catalina.properties configuration in a way that's just as
secure, more efficient and easier to configure than the old Apache/Tomcat
combo.

Claude Brisson <cl...@renegat.net> wrote on 08/22/2008 02:57:46 PM:

> If you're using Apache in front of Tomcat, it's also very easy to forbid
> some URLs to the outside world. In fact, along with its ability to
> handle static files in an optimal way, Apache rewriting and security
> scripting features are very good reasons to use it in front of the J2EE
> container.
>
>   Claude
>
> Le vendredi 22 août 2008 à 12:35 -0600, Peter_Ford@blm.gov a écrit :
> > I've written a Filter - it needs more testing but it appears to be
doing
> > the job.
> >
> > Thanks, all.
> >
> > Peter_Ford@blm.gov wrote on 08/22/2008 11:39:30 AM:
> >
> > > I don't think that'll help:
> > >
> > > 1 - the mappings in web.xml are such that *.vtl URLs will be directed
to
> > > the VelocityViewServlet;
> > > 2 - the templates are actually in a JAR in WEB-INF/lib/ - they're not
> > > available as static content via the default servlet.
> > >
> > > With this setup, any *.vtl URLs will be handled by the View Servlet,
> > which
> > > will process the requests by merging with whichever template is
> > requested.
> > >
> > >
> > > Charles Harvey III <ch...@alloy.com> wrote on 08/22/2008 11:23:57
AM:
> > >
> > > > Put your templates in /WEB-INF/templates.  Than nobody can access
them
> > > > and there is no need for a filter.
> > > >
> > > >
> > > > Charlie
> > > >
> > > >
> > > > Peter_Ford@blm.gov said the following on 8/22/2008 12:17 PM:
> > > > > My web app uses the Velocity View Servlet with a mapping "*.vtl"
(I
> > use
> > > > > .vtl in preference to .vm for my templates; .vm I reserve for
> > > VelociMacro
> > > > > files). Users should be accessing the system with URLs with the
> > pattern
> > > > > "*.do", which maps to Struts. The Struts ActionForwards then
> > reference
> > > > > *.vtl URIs for the presentation step. All fairly straightforward,
I
> > > think.
> > > > >
> > > > > The problem is, what's to stop a user typing in the name of one
of my
> > > .vtl
> > > > > templates directly into their browser address bar? (or maybe
worse,
> > > > > generating a POST request that contains all the context data so
that
> > it
> > > > > appears to render correctly)?
> > > > >
> > > > > There must be a way to secure this. A Filter or Valve, maybe?
(The
> > > webapp
> > > > > will be deployed on Tomcat 5.0, 5.5 and possibly 6). What do
people
> > > here
> > > > > do?
> > > > >
> > > > >
> > > > >
---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> > > > > For additional commands, e-mail: user-help@velocity.apache.org
> > > > >
> > > > >
> > > > >
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> > > > For additional commands, e-mail: user-help@velocity.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> > > For additional commands, e-mail: user-help@velocity.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> > For additional commands, e-mail: user-help@velocity.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org

Re: How to stop users accessing templates directly

[Claude Brisson <cl...@renegat.net>]

If you're using Apache in front of Tomcat, it's also very easy to forbid
some URLs to the outside world. In fact, along with its ability to
handle static files in an optimal way, Apache rewriting and security
scripting features are very good reasons to use it in front of the J2EE
container.

  Claude

Le vendredi 22 août 2008 à 12:35 -0600, Peter_Ford@blm.gov a écrit :
> I've written a Filter - it needs more testing but it appears to be doing
> the job.
> 
> Thanks, all.
> 
> Peter_Ford@blm.gov wrote on 08/22/2008 11:39:30 AM:
> 
> > I don't think that'll help:
> >
> > 1 - the mappings in web.xml are such that *.vtl URLs will be directed to
> > the VelocityViewServlet;
> > 2 - the templates are actually in a JAR in WEB-INF/lib/ - they're not
> > available as static content via the default servlet.
> >
> > With this setup, any *.vtl URLs will be handled by the View Servlet,
> which
> > will process the requests by merging with whichever template is
> requested.
> >
> >
> > Charles Harvey III <ch...@alloy.com> wrote on 08/22/2008 11:23:57 AM:
> >
> > > Put your templates in /WEB-INF/templates.  Than nobody can access them
> > > and there is no need for a filter.
> > >
> > >
> > > Charlie
> > >
> > >
> > > Peter_Ford@blm.gov said the following on 8/22/2008 12:17 PM:
> > > > My web app uses the Velocity View Servlet with a mapping "*.vtl" (I
> use
> > > > .vtl in preference to .vm for my templates; .vm I reserve for
> > VelociMacro
> > > > files). Users should be accessing the system with URLs with the
> pattern
> > > > "*.do", which maps to Struts. The Struts ActionForwards then
> reference
> > > > *.vtl URIs for the presentation step. All fairly straightforward, I
> > think.
> > > >
> > > > The problem is, what's to stop a user typing in the name of one of my
> > .vtl
> > > > templates directly into their browser address bar? (or maybe worse,
> > > > generating a POST request that contains all the context data so that
> it
> > > > appears to render correctly)?
> > > >
> > > > There must be a way to secure this. A Filter or Valve, maybe? (The
> > webapp
> > > > will be deployed on Tomcat 5.0, 5.5 and possibly 6). What do people
> > here
> > > > do?
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> > > > For additional commands, e-mail: user-help@velocity.apache.org
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> > > For additional commands, e-mail: user-help@velocity.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> > For additional commands, e-mail: user-help@velocity.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org

Re: How to stop users accessing templates directly

[Pe...@blm.gov]

I've written a Filter - it needs more testing but it appears to be doing
the job.

Thanks, all.

Peter_Ford@blm.gov wrote on 08/22/2008 11:39:30 AM:

> I don't think that'll help:
>
> 1 - the mappings in web.xml are such that *.vtl URLs will be directed to
> the VelocityViewServlet;
> 2 - the templates are actually in a JAR in WEB-INF/lib/ - they're not
> available as static content via the default servlet.
>
> With this setup, any *.vtl URLs will be handled by the View Servlet,
which
> will process the requests by merging with whichever template is
requested.
>
>
> Charles Harvey III <ch...@alloy.com> wrote on 08/22/2008 11:23:57 AM:
>
> > Put your templates in /WEB-INF/templates.  Than nobody can access them
> > and there is no need for a filter.
> >
> >
> > Charlie
> >
> >
> > Peter_Ford@blm.gov said the following on 8/22/2008 12:17 PM:
> > > My web app uses the Velocity View Servlet with a mapping "*.vtl" (I
use
> > > .vtl in preference to .vm for my templates; .vm I reserve for
> VelociMacro
> > > files). Users should be accessing the system with URLs with the
pattern
> > > "*.do", which maps to Struts. The Struts ActionForwards then
reference
> > > *.vtl URIs for the presentation step. All fairly straightforward, I
> think.
> > >
> > > The problem is, what's to stop a user typing in the name of one of my
> .vtl
> > > templates directly into their browser address bar? (or maybe worse,
> > > generating a POST request that contains all the context data so that
it
> > > appears to render correctly)?
> > >
> > > There must be a way to secure this. A Filter or Valve, maybe? (The
> webapp
> > > will be deployed on Tomcat 5.0, 5.5 and possibly 6). What do people
> here
> > > do?
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> > > For additional commands, e-mail: user-help@velocity.apache.org
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> > For additional commands, e-mail: user-help@velocity.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org

Re: How to stop users accessing templates directly

[Pe...@blm.gov]

I don't think that'll help:

1 - the mappings in web.xml are such that *.vtl URLs will be directed to
the VelocityViewServlet;
2 - the templates are actually in a JAR in WEB-INF/lib/ - they're not
available as static content via the default servlet.

With this setup, any *.vtl URLs will be handled by the View Servlet, which
will process the requests by merging with whichever template is requested.


Charles Harvey III <ch...@alloy.com> wrote on 08/22/2008 11:23:57 AM:

> Put your templates in /WEB-INF/templates.  Than nobody can access them
> and there is no need for a filter.
>
>
> Charlie
>
>
> Peter_Ford@blm.gov said the following on 8/22/2008 12:17 PM:
> > My web app uses the Velocity View Servlet with a mapping "*.vtl" (I use
> > .vtl in preference to .vm for my templates; .vm I reserve for
VelociMacro
> > files). Users should be accessing the system with URLs with the pattern
> > "*.do", which maps to Struts. The Struts ActionForwards then reference
> > *.vtl URIs for the presentation step. All fairly straightforward, I
think.
> >
> > The problem is, what's to stop a user typing in the name of one of my
.vtl
> > templates directly into their browser address bar? (or maybe worse,
> > generating a POST request that contains all the context data so that it
> > appears to render correctly)?
> >
> > There must be a way to secure this. A Filter or Valve, maybe? (The
webapp
> > will be deployed on Tomcat 5.0, 5.5 and possibly 6). What do people
here
> > do?
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> > For additional commands, e-mail: user-help@velocity.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org

Re: How to stop users accessing templates directly

[Charles Harvey III <ch...@alloy.com>]

Put your templates in /WEB-INF/templates.  Than nobody can access them
and there is no need for a filter.


Charlie


Peter_Ford@blm.gov said the following on 8/22/2008 12:17 PM:
> My web app uses the Velocity View Servlet with a mapping "*.vtl" (I use
> .vtl in preference to .vm for my templates; .vm I reserve for VelociMacro
> files). Users should be accessing the system with URLs with the pattern
> "*.do", which maps to Struts. The Struts ActionForwards then reference
> *.vtl URIs for the presentation step. All fairly straightforward, I think.
>
> The problem is, what's to stop a user typing in the name of one of my .vtl
> templates directly into their browser address bar? (or maybe worse,
> generating a POST request that contains all the context data so that it
> appears to render correctly)?
>
> There must be a way to secure this. A Filter or Valve, maybe? (The webapp
> will be deployed on Tomcat 5.0, 5.5 and possibly 6). What do people here
> do?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org