You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Joel Schneider <js...@cariboulake.com> on 2000/11/14 21:08:09 UTC
*.jsp "back door" issue
Description of Problem:
A typical Struts based web site might be configured to have requests
matching the pattern"*.do" sent to the ActionServlet. After a request is
handled by its Action class, processing is typically forwarded to a .jsp
page.
However, it's also possible for users to directly request a .jsp page.
When this happens, the JSP container (in my case, Orion) will process the
.jsp page without any involvement by the ActionServlet. Some .jsp pages
may yield unexpected results when called in this manner.
Examples:
"Normal" Scenario
1. client requests "edit.do"
2. ActionServlet dispatches request to EditAction instance.
3. EditAction forwards processing to "edit.jsp"
4. client receives response handled by ActionServlet
"Bad" Scenario
1. client requests "edit.jsp"
2. JSP container processes "edit.jsp" without using ActionServlet
3. client receives response _not_ handled by ActionServlet
Quick and Dirty Workaround:
To insure that requests are handled by the ActionServlet, I subclassed the
ActionServlet and added code to set a request attribute named
"ActionServlet":
private static final Boolean boolTrue = new Boolean(true);
...
request.setAttribute("ActionServlet", boolTrue);
Then, near the top of each .jsp file, I inserted the following scriptlet,
which causes requests not processeded by the ActionServlet to be
redirected to a ".do" URL:
<%
if(request.getAttribute("ActionServlet") == null) {
StringBuffer sb = new StringBuffer(request.getServletPath());
sb.setLength(sb.length() - 3);
sb.append("do");
response.sendRedirect(sb.toString());
}
%>
(The above code should really be placed in a custom tag, but this serves
well enough for purposes of illustration.)
Questions:
1. Would it make sense to add a similar capability to Struts proper
(modifying ActionServlet and adding a new custom tag), to provide a
standard mechanism for handling this situation?
2. Is there some better, yet portable way to handle this?
Joel
Re: Re[2]: *.jsp "back door" issue
Posted by Joel Schneider <js...@cariboulake.com>.
On Wed, 15 Nov 2000, Oleg V Alexeev wrote:
> Hello David,
>
> Tuesday, November 14, 2000, 11:19:40 PM, you wrote:
>
> DG> Joel Schneider wrote:
>
> >> However, it's also possible for users to directly request a .jsp page.
> >> When this happens, the JSP container (in my case, Orion) will process the
> >> .jsp page without any involvement by the ActionServlet. Some .jsp pages
> >> may yield unexpected results when called in this manner.
>
> DG> Put those JSP pages in a directory under WEB-INF; for example, WEB-INF/jsp.
> DG> Files under the WEB-INF directory cannot be directly accessed.
>
> But pages can be redirected - not forwarded only. How can we do it in
> this case?
>
It should be possible to redirect to the "*.do" mappings defined in
action.xml. Simply redirect to, for example, "/login.do", etc.
Joel
Re[2]: *.jsp "back door" issue
Posted by Oleg V Alexeev <go...@penza.net>.
Hello David,
Tuesday, November 14, 2000, 11:19:40 PM, you wrote:
DG> Joel Schneider wrote:
>> However, it's also possible for users to directly request a .jsp page.
>> When this happens, the JSP container (in my case, Orion) will process the
>> .jsp page without any involvement by the ActionServlet. Some .jsp pages
>> may yield unexpected results when called in this manner.
DG> Put those JSP pages in a directory under WEB-INF; for example, WEB-INF/jsp.
DG> Files under the WEB-INF directory cannot be directly accessed.
But pages can be redirected - not forwarded only. How can we do it in
this case?
--
Best regards,
Oleg mailto:gonza@penza.net
Re: *.jsp "back door" issue
Posted by Joel Schneider <js...@cariboulake.com>.
On Tue, 14 Nov 2000, David Geary wrote:
> Joel Schneider wrote:
>
> > Description of Problem:
> >
> > A typical Struts based web site might be configured to have requests
> > matching the pattern"*.do" sent to the ActionServlet. After a request is
> > handled by its Action class, processing is typically forwarded to a .jsp
> > page.
> >
> > However, it's also possible for users to directly request a .jsp page.
> > When this happens, the JSP container (in my case, Orion) will process the
> > .jsp page without any involvement by the ActionServlet. Some .jsp pages
> > may yield unexpected results when called in this manner.
>
> Put those JSP pages in a directory under WEB-INF; for example, WEB-INF/jsp.
> Files under the WEB-INF directory cannot be directly accessed.
>
>
> david
Thanks for the excellent tip!!
Joel
Re: *.jsp "back door" issue
Posted by David Geary <sa...@tri-lakesonline.net>.
Joel Schneider wrote:
> Description of Problem:
>
> A typical Struts based web site might be configured to have requests
> matching the pattern"*.do" sent to the ActionServlet. After a request is
> handled by its Action class, processing is typically forwarded to a .jsp
> page.
>
> However, it's also possible for users to directly request a .jsp page.
> When this happens, the JSP container (in my case, Orion) will process the
> .jsp page without any involvement by the ActionServlet. Some .jsp pages
> may yield unexpected results when called in this manner.
Put those JSP pages in a directory under WEB-INF; for example, WEB-INF/jsp.
Files under the WEB-INF directory cannot be directly accessed.
david
RE: *.jsp "back door" issue
Posted by Reena Gupta <re...@healthstream.com>.
unsubscribe
-----Original Message-----
From: Robert Leland [mailto:Robert@freetocreate.org]
Sent: Thursday, November 16, 2000 8:12 AM
To: struts-user@jakarta.apache.org
Subject: Re: *.jsp "back door" issue
Great ! Did Duane Fields (WDJSP) contact you ? He indicated that he had a
much
more comprehensive package that he had written for a client
that he would donate to struts.
Originally, I had the token tied in with the standard hidden field
name. I was going to rework the code into a better form, so let
me know if I can be of help on this, even if it to document !
-Rob
"Craig R. McClanahan" wrote:
> Robert Leland wrote:
>
> > > ActionServlet and added code to set a request attribute named
> > > "ActionServlet":
> > >
> > > private static final Boolean boolTrue = new Boolean(true);
> > > ...
> > > request.setAttribute("ActionServlet", boolTrue);
> > >
> >
> > I submitted some code back in about Oct 10 to struts-dev
> > that would prevent that senario. It also used a hidden
> > field in the form. It set a "token"
> > in both the 'session' and 'request'. The token was
> > an MD5 encoded 'single' use field. See
> > "Web Development with JavaServer Pages", Fields, Kolb (taglib.com)
> >
>
> I've been toying with this particular approach ... not only can it be
> used to solve the "back door" problem as stated, you can also use it to
> help deal with the dreaded "back button" problem where the user resubmits
> a form again.
>
> >
> > Even though the page can be accessed initially w/o the use of
> > the Action Servlet, when it is submitted it does go through
> > the Action Servlet. Since the token is good for only one
> > submit event the token could be checked at the action servelet level,
> > or more flexabily in the ActionForm itself. It takes about
> > 1 lines of code to perform the check.
> > if (!Token.IsValid()) {};
> >
> > --
> > Robert Leland Robert@free2create.org
> > 804 N. Kenmore Street +01-703-525-3580
> > Arlington VA 22201
>
> Craig McClanahan
--
Rob Leland Robert@freetocreate.org (+01-202-544-0533)
CGH Technologies
FAA ATA 200 Lab
Re: *.jsp "back door" issue
Posted by Robert Leland <Ro...@freetocreate.org>.
Great ! Did Duane Fields (WDJSP) contact you ? He indicated that he had a
much
more comprehensive package that he had written for a client
that he would donate to struts.
Originally, I had the token tied in with the standard hidden field
name. I was going to rework the code into a better form, so let
me know if I can be of help on this, even if it to document !
-Rob
"Craig R. McClanahan" wrote:
> Robert Leland wrote:
>
> > > ActionServlet and added code to set a request attribute named
> > > "ActionServlet":
> > >
> > > private static final Boolean boolTrue = new Boolean(true);
> > > ...
> > > request.setAttribute("ActionServlet", boolTrue);
> > >
> >
> > I submitted some code back in about Oct 10 to struts-dev
> > that would prevent that senario. It also used a hidden
> > field in the form. It set a "token"
> > in both the 'session' and 'request'. The token was
> > an MD5 encoded 'single' use field. See
> > "Web Development with JavaServer Pages", Fields, Kolb (taglib.com)
> >
>
> I've been toying with this particular approach ... not only can it be
> used to solve the "back door" problem as stated, you can also use it to
> help deal with the dreaded "back button" problem where the user resubmits
> a form again.
>
> >
> > Even though the page can be accessed initially w/o the use of
> > the Action Servlet, when it is submitted it does go through
> > the Action Servlet. Since the token is good for only one
> > submit event the token could be checked at the action servelet level,
> > or more flexabily in the ActionForm itself. It takes about
> > 1 lines of code to perform the check.
> > if (!Token.IsValid()) {};
> >
> > --
> > Robert Leland Robert@free2create.org
> > 804 N. Kenmore Street +01-703-525-3580
> > Arlington VA 22201
>
> Craig McClanahan
--
Rob Leland Robert@freetocreate.org (+01-202-544-0533)
CGH Technologies
FAA ATA 200 Lab
Re: *.jsp "back door" issue
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Robert Leland wrote:
> > ActionServlet and added code to set a request attribute named
> > "ActionServlet":
> >
> > private static final Boolean boolTrue = new Boolean(true);
> > ...
> > request.setAttribute("ActionServlet", boolTrue);
> >
>
> I submitted some code back in about Oct 10 to struts-dev
> that would prevent that senario. It also used a hidden
> field in the form. It set a "token"
> in both the 'session' and 'request'. The token was
> an MD5 encoded 'single' use field. See
> "Web Development with JavaServer Pages", Fields, Kolb (taglib.com)
>
I've been toying with this particular approach ... not only can it be
used to solve the "back door" problem as stated, you can also use it to
help deal with the dreaded "back button" problem where the user resubmits
a form again.
>
> Even though the page can be accessed initially w/o the use of
> the Action Servlet, when it is submitted it does go through
> the Action Servlet. Since the token is good for only one
> submit event the token could be checked at the action servelet level,
> or more flexabily in the ActionForm itself. It takes about
> 1 lines of code to perform the check.
> if (!Token.IsValid()) {};
>
> --
> Robert Leland Robert@free2create.org
> 804 N. Kenmore Street +01-703-525-3580
> Arlington VA 22201
Craig McClanahan
Re: *.jsp "back door" issue
Posted by Robert Leland <Ro...@free2create.org>.
> ActionServlet and added code to set a request attribute named
> "ActionServlet":
>
> private static final Boolean boolTrue = new Boolean(true);
> ...
> request.setAttribute("ActionServlet", boolTrue);
>
I submitted some code back in about Oct 10 to struts-dev
that would prevent that senario. It also used a hidden
field in the form. It set a "token"
in both the 'session' and 'request'. The token was
an MD5 encoded 'single' use field. See
"Web Development with JavaServer Pages", Fields, Kolb (taglib.com)
Even though the page can be accessed initially w/o the use of
the Action Servlet, when it is submitted it does go through
the Action Servlet. Since the token is good for only one
submit event the token could be checked at the action servelet level,
or more flexabily in the ActionForm itself. It takes about
1 lines of code to perform the check.
if (!Token.IsValid()) {};
--
Robert Leland Robert@free2create.org
804 N. Kenmore Street +01-703-525-3580
Arlington VA 22201
Re: *.jsp "back door" issue
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Joel Schneider wrote:
> Description of Problem:
>
> A typical Struts based web site might be configured to have requests
> matching the pattern"*.do" sent to the ActionServlet. After a request is
> handled by its Action class, processing is typically forwarded to a .jsp
> page.
>
> However, it's also possible for users to directly request a .jsp page.
> When this happens, the JSP container (in my case, Orion) will process the
> .jsp page without any involvement by the ActionServlet. Some .jsp pages
> may yield unexpected results when called in this manner.
>
Besides David Geary's suggestion, another approach is supported by the servlet
API if you are using container-managed security for your application. You can
define a security constraint that lists no roles as being allowed, which the
servlet container will interpret as not allowing access to anyone directly
from a request. You can forward to (or include) such a page -- just not
request it directly.
Note that this behavior was not clearly specified in the 2.2 servlet spec, so
your mileage might vary there -- but all 2.3 containers are required to act
this way.
>
> Examples:
>
> "Normal" Scenario
> 1. client requests "edit.do"
> 2. ActionServlet dispatches request to EditAction instance.
> 3. EditAction forwards processing to "edit.jsp"
> 4. client receives response handled by ActionServlet
>
> "Bad" Scenario
> 1. client requests "edit.jsp"
> 2. JSP container processes "edit.jsp" without using ActionServlet
> 3. client receives response _not_ handled by ActionServlet
>
> Quick and Dirty Workaround:
>
> To insure that requests are handled by the ActionServlet, I subclassed the
> ActionServlet and added code to set a request attribute named
> "ActionServlet":
>
> private static final Boolean boolTrue = new Boolean(true);
> ...
> request.setAttribute("ActionServlet", boolTrue);
>
> Then, near the top of each .jsp file, I inserted the following scriptlet,
> which causes requests not processeded by the ActionServlet to be
> redirected to a ".do" URL:
>
> <%
> if(request.getAttribute("ActionServlet") == null) {
> StringBuffer sb = new StringBuffer(request.getServletPath());
> sb.setLength(sb.length() - 3);
> sb.append("do");
> response.sendRedirect(sb.toString());
> }
> %>
>
This kind of thing would be trivial to embed in a custom tag as well. The
only things of concern to me are:
* It assumes that there is a corresponding action for every page,
with the same name. That is not true for the applications I tend
to write -- the names of the business functions (/saveSubscription.do)
tend to be totally independent of the names of the corresponding
JSP page that ultimately gets displayed (/mainMenu.jsp).
* It hard codes the knowledge that you are using extension mapping for
the controller servlet, and also hard codes the actual extension used,
into every single page. This makes changes to that choice very
painful.
>
> (The above code should really be placed in a custom tag, but this serves
> well enough for purposes of illustration.)
>
> Questions:
>
> 1. Would it make sense to add a similar capability to Struts proper
> (modifying ActionServlet and adding a new custom tag), to provide a
> standard mechanism for handling this situation?
>
> 2. Is there some better, yet portable way to handle this?
>
> Joel
Craig