[ 
https://issues.apache.org/jira/browse/WICKET-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebastiaan van Erk updated WICKET-4427:
---------------------------------------

    Comment: was deleted

(was: Hi,

Thanks for looking at this issue, but I have several issues with the proposed 
fix.

1) It does not address the real problem: why is a file "x%20" resolved to "x" 
on the file system in the first place (if I request x%20 then I expect it to 
open x%20 and not x).
2) PackageResourceGuard is an implementation of an interface, namely of 
IPackageResourceGuard with one method boolean accept(final Class<?> scope, 
final String path). As it stands, the same problem can occur with other 
implementations, and in fact, it is strange that if I accept "x%20" for 
whatever reason with this *interface*, that it should suddenly return a 
resource with a different path.

When debugging to find the real reason this went wrong, I found it to be 
related to this code:

        public ExtensionResourceNameIterator(String path, final String 
extension)
        {
                if ((extension == null) && (path.indexOf('.') != -1))
                {
                        // Get the extension from the path provided
                        extensions = new String[] { "." + 
Strings.lastPathComponent(path, '.') };
                        path = Strings.beforeLastPathComponent(path, '.');
                }
                else if (extension != null)
                {
                        // Extension can be a comma separated list
                        extensions = Strings.split(extension, ',');
                        for (int i = extensions.length - 1; i >= 0; i--)
                        {
                                extensions[i] = extensions[i].trim();
                                if (!extensions[i].startsWith("."))
                                {
                                        extensions[i] = "." + extensions[i];
                                }
                        }
                }
                else
                {
                        extensions = new String[1];
                        extensions[0] = ".";
                }

                this.path = path;
                index = 0;
        }

Basically, this enumerator gets passed the real extension of the file, *and 
then processes it*, *AFTER THE RESOURCE GUARD CHECK HAS ALREADY BEEN DONE*.

I don't know at which point it is necessary to initialize this iterator from a 
single string containing a comma separated list of extensions, but to split 
this string and process it here is doing it at the wrong level because it 
cannot distinguish between 1 extension with a comma in it and multiple 
extensions and also not (due to the trim) between extensions with leading or 
trailing white space. The splitting should probably be being done at the point 
where the extension is clearly a value from configuration property.

All in all, the previous fix did not actually fix the problem, it just removed 
a symptom of the problem for one implementation of IPackageResourceGuard.

To prove this, note that the above extension processing does two things: split 
on , and trim. This means that another way to subvert the check is to use the 
extension ".properties,xml", i.e., using the url:

http://localhost:8080/wicket-4427/resources/test/test.properties,xml)
    
> test
> ----
>
>                 Key: WICKET-4427
>                 URL: https://issues.apache.org/jira/browse/WICKET-4427
>             Project: Wicket
>          Issue Type: Test
>            Reporter: Sebastiaan van Erk
>            Assignee: Peter Ertl
>            Priority: Trivial
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to