ICEfaces
  1. ICEfaces
  2. ICE-6862

Blocking Servlet returns a HTTP 200 code instead of returning the correct HTTP error status

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.2-EE-GA_P02
    • Fix Version/s: EE-1.8.2.GA_P03
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      -

      Description

      We have a web security tool which the client runs and which tries to take advantage of known security issues. It basically bombards the web application with all kinds of URLs trying to access files or other programs. For example:

      http://server:8080/ipp-portal/block/cgi-bin/perl.sh

      Now, this of course does not work, but unfortunately the ICEfaces Blocking Servlet returns a HTTP 200 code in certain situations instead of correctly returning a HTTP error status.

      The request we have for the ICEfaces support touches two scenarios:

      1. When sending a bogus URL to the BlockingServlet while NO user session exists, the response to the client browser comes from the "SessionExpiredResponse" class und it contains a HTTP 200 code. We would like ICEfaces to return a HTTP error code instead. The two attached classes are patches of the original classes and show the desired behavior. We need to know from ICEfaces support if returning an error code causes any problems for other ICEfaces components and, if not, we would like receive patch from ICEfaces which inclides this fix.

      2. After a user session has been established, the response from the server for a bogus URL alternates between HTTP 500 and HTTP 200. Using the same URL you first run into an exception on the server while executing the "lifecycle.render(facesContext)" method in class com.icesoft.faces.webapp.http.core.JsfLifecycleExecutor (Line 19 in ICEfaces 1.8.2). This exception is caught in the class com.icesoft.faces.context.View (Line 78) and logged as "Unknown View" which in the end results in a ServletException and a HTTP 500 error on the client ... all correct so far. Now, every other time you invoke the same URL, the mentioned invocation of "lifecycle.render(facesContext)" DOES NOT throw an exception and as a result the browser receives a response with HTTP 200 code and an empty page.

      We need a solution that the response would reliably always return a HTTP 500 code.

        Activity

        Repository Revision Date User Message
        ICEsoft Public SVN Repository #24598 Tue May 17 06:36:26 MDT 2011 jack.van.ooststroom Fixed JIRA ICE-6862 : Blocking Servlet returns a HTTP 200 code instead of returning the correct HTTP error status; MainSessionBoundServlet's .*uploadHtml and .* should not have the SessionVerifier and simplified the MainServlet's dispatching logic has been simplified.
        Files Changed
        Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/MainSessionBoundServlet.java
        Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/MainServlet.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #24590 Mon May 16 15:56:22 MDT 2011 jack.van.ooststroom Fixed JIRA ICE-6862 : Blocking Servlet returns a HTTP 200 code instead of returning the correct HTTP error status
        Files Changed
        Commit graph ADD /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/NotFoundServer.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #24589 Mon May 16 15:31:19 MDT 2011 jack.van.ooststroom Fixed JIRA ICE-6862 : Blocking Servlet returns a HTTP 200 code instead of returning the correct HTTP error status
        Files Changed
        Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/MainSessionBoundServlet.java
        Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/MainServlet.java

          People

          • Assignee:
            Jack Van Ooststroom
            Reporter:
            Tyler Johnson
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: