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 [EMAIL PROTECTED]
804 N. Kenmore Street +01-703-525-3580
Arlington VA 22201
Craig McClanahan
--
Rob Leland [EMAIL PROTECTED] (+01-202-544-0533)
CGH Technologies
FAA ATA 200 Lab
RE: *.jsp back door issue
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: November 15, 2000 8:51 PM To: [EMAIL PROTECTED] Subject: Re: *.jsp "back door" issue 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. Can you clarify this (I don't have the Servlet 2.3 specs around right now, but will look this up myself later if needed. I have actually noticed that Resin 1.2 and TomCat 3.2 differ in this respect. If you have declarative security set for your paths, and you come in from the browser, but servlet engines will redirect you to a login if needed, and check roles on access. If you then internally do a forward to another url, Resin will agian check roles, while TomCat will not. Are you saying that Resin is not compliant with the Servlet 2.3 specs, and TomCat is?
Re: *.jsp back door issue
Colin Sampaleanu wrote: -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: November 15, 2000 8:51 PM To: [EMAIL PROTECTED] Subject: Re: *.jsp "back door" issue 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. Can you clarify this (I don't have the Servlet 2.3 specs around right now, but will look this up myself later if needed. Sorry ... I was headed for an airplane and didn't have time to write out an example. Consider the following security constraint: security-constraint web-resource-collection web-resource-nameAll JSP Pages/web-resource-name url-pattern/pages/*/url-pattern /web-resource-collection auth-constraint !-- No roles listed here -- /auth-constraint /security-constraint In a servlet 2.3 container (such as Tomcat 4.0), this is interpreted to mean that there is no direct access at all to any URL like: http://localhost:8080/myapp/pages/menu.jsp but you are allowed to use a request dispatcher to access them. This is because security constraints are to be checked only on the *original* URL, not on the forward/include. Thus, if you want to ensure that a page is accessed only via the controller servlet, you can give it a URL path within the "pages" subdirectory, and the container will take care of this for you. I have actually noticed that Resin 1.2 and TomCat 3.2 differ in this respect. If you have declarative security set for your paths, and you come in from the browser, but servlet engines will redirect you to a login if needed, and check roles on access. If you then internally do a forward to another url, Resin will agian check roles, while TomCat will not. Are you saying that Resin is not compliant with the Servlet 2.3 specs, and TomCat is? As I mentioned earlier, this behavior was not specified explicitly in servlet 2.2, so you cannot count in consistent behavior. (In fact, the person who wrote this part of Tomcat 3.2 *intended* it to act the way Orion does -- it's a bug that it doesn't :-). If Resin 1.2 claims to implement servlet 2.2, they are OK (since it's not specified). If they claim to implement servlet 2.3, they need to review the following stuff in the Servlet 2.3 Proposed Final Draft spec, dated October 20, 2000, at http://java.sun.com/products/servlet/download.html: Section 12.2, third paragraph: The security model is declared in this way to apply to both static content part of the web application and to Servlets within the application that are requested by the client. The security model does not intervene between a Servlet using the RequestDispatcher to invoke a static resource or Servlet and the static resource or servlet being requested by a forward() or an include(). Craig
Re: Re[2]: *.jsp back door issue
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: *.jsp back door issue
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
Re: *.jsp back door issue
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
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
