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

        Tyler Johnson created issue -
        Tyler Johnson made changes -
        Field Original Value New Value
        Salesforce Case [5007000000GublN]
        Tyler Johnson made changes -
        Affects Version/s 1.8.2-EE-GA_P02 [ 10226 ]
        Affects Version/s 2.0.1 [ 10255 ]
        Affects Version/s EE-2.0.0.GA [ 10263 ]
        Tyler Johnson made changes -
        Assignee Jack van Ooststroom [ jack.van.ooststroom ]
        Ken Fyten made changes -
        Fix Version/s EE-1.8.2.GA_P03 [ 10251 ]
        Assignee Priority P2
        Jack Van Ooststroom made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Assignee Priority P2

          People

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

            Dates

            • Created:
              Updated:
              Resolved: