struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kent R. Spillner (JIRA)" <j...@apache.org>
Subject [jira] Created: (WW-3142) Convention plugin support for default actionless dispatcher results exposes raw source code of index.jsp files on Google AppEngine
Date Sat, 30 May 2009 08:04:42 GMT
Convention plugin support for default actionless dispatcher results exposes raw source code
of index.jsp files on Google AppEngine
----------------------------------------------------------------------------------------------------------------------------------

                 Key: WW-3142
                 URL: https://issues.apache.org/struts/browse/WW-3142
             Project: Struts 2
          Issue Type: Bug
          Components: Plugin - Convention
    Affects Versions: 2.1.6
         Environment: Google AppEngine Java SDK v1.2.1, Struts v2.1.7-SNAPSHOT, xwork-2.1.4
            Reporter: Kent R. Spillner


As initially documented in [WW-3114], a bug exists in either Struts or AppEngine which causes
the raw source code of JSP files under WEB-INF to be served to clients as plain/text.  This
potentially is a very serious security hole, although limited in scope.  Although potentially
a bug in AppEngine only, I'm logging this as a separate JIRA issue with Struts because I believe
Struts can easily be improved to avoid the bug altogether.

The problem is caused by an extra path separator character at the beginning of the filename
"/index.jsp"

Assume the file WEB-INF/content/index.jsp exists and a request for the URL http://<app>.appspot.com/
then:

ConventionUnknownHandler#handleUnknownAction() line 136 explicitly sets "/index" as the last
path component before the file extension, but that's ok because servletContext.getResource(path)
on line 194 returns a non-null value on AppEngine even with the double slash.  The if block
beginning on line 141 is skipped because the action name is empty, but line 172 is executed
because resource isn't null.  At this point, resource.path still includes the double slash
and resource.ext is "jsp"

This behavior seems correct to me, and nothing explicitly uses the path in ConventionUnknownHandler#buildActionConfig()
lines 206-224.  I guess the code that has difficulty with the double slash is buried somewhere
in ResultConfig.Builder or ActionConfig.Builder, but I haven't looked into the xwork source
yet.

If anyone has any pointers or suggestions for further promising areas of the code to look
into to in order to correctly solve this, I'd greatly appreciate it!

Thanks in advance!

Best,
Kent



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message