struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Musachy Barroso (JIRA)" <>
Subject [jira] Updated: (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 15:35:44 GMT


Musachy Barroso updated WW-3142:

    Fix Version/s: 2.1.8
         Assignee: Musachy Barroso

setting fix version to 2.1.8, I will look into it as soon as I have internet (currently checking
mail on some coffee shop :)). Thanks for the research Kent.

> Convention plugin support for default actionless dispatcher results exposes raw source
code of index.jsp files on Google AppEngine
> ----------------------------------------------------------------------------------------------------------------------------------
>                 Key: WW-3142
>                 URL:
>             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
>            Assignee: Musachy Barroso
>             Fix For: 2.1.8
>         Attachments: struts2-plugin-convention-default-actionless-result.diff
> 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
> Assume the file WEB-INF/content/index.jsp exists and a request for the URL http://<app>
> 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
> 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.

View raw message