Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue #6473 - canonicalPath refactor & fix alias check in PathResource (Jetty-10) #6478

Merged
merged 6 commits into from Jun 29, 2021

Conversation

lachlan-roberts
Copy link
Contributor

Issue #6473

Merge of PR #6474 and PR #6477 for Jetty-10.

lachlan-roberts and others added 3 commits June 29, 2021 10:57
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
* Reverted %-escape handling for URI query parts.
* Performing canonicalization in ServletContext.getResource(),
  and improving alias checking in ContextHandler.getResource().
* Performing canonicalization checks in Resource.addPath() to avoid
  navigation above of the root.
* Test added and fixed.
* Various cleanups.
* Improved javadoc and comments

Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
@lachlan-roberts lachlan-roberts added this to In progress in Jetty 10.0.6/11.0.6 FROZEN via automation Jun 29, 2021
Jetty 10.0.6/11.0.6 FROZEN automation moved this from In progress to Review in progress Jun 29, 2021
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
Copy link
Contributor

@gregw gregw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry to be pendantic

Co-authored-by: Greg Wilkins <gregw@webtide.com>
@sbordet sbordet self-requested a review June 29, 2021 08:41
public interface HttpURI
{
/**
* Violations of safe URI interpretations
*/
enum Violation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class was called Ambiguous so this is a breaking change.

Also, why does it not implement ComplianceViolation, which seems to summarize the violation concept?

On a closer look, I think this class here is a complete duplicate of UriCompliance.Violation.
It's here because in 9.4.x we don't have UriCompliance (so it's a merge side-effect).
Should it not be completely removed, so that in 10 we only use UriCompliance.Violation?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ambiguous was public for a few releases, but not used in any interfaces at all, so I think it is OK to change.
But worth investigating if we can actually use UriCompliance.Violation here....

* @return Set of violations in the URI.
*/
Collection<Violation> getViolations();

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment above, I think methods that expose Violation should be removed or changed to use UriCompliance.Violation.

@@ -1216,6 +1298,10 @@ else if (c == '/')
{
switch (encodedValue)
{
case 0:
// Byte 0 cannot be present in a UTF-8 sequence in any position
// other than as the NUL ASCII byte which we do not wish to allow.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fix indentation.

return violation.getMessage();
}
return null;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See previous comment. This mapping from HttpURI.Violation to UriCompliance.Violation should not be necessary.
HttpURI should just use UriCompliance.Violation.

@@ -2305,6 +2308,8 @@ public InputStream getResourceAsStream(String path)
@Override
public Set<String> getResourcePaths(String path)
{
if (path == null)
return null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should not the logic here be similar to getResource()? I think we should canonicalize here too.

And also in getRealPath().

I think we need to review the ServletContext implementation more carefully.

UriCompliance.Violation.NON_CANONICAL_AMBIGUOUS_PATHS)));
assertThat(_connector.getResponse(request), Matchers.allOf(
startsWith("HTTP/1.1 200"),
containsString("pathInfo=/path/ambiguous/.././info")));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like a legit test. Why was it removed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

becaues the compliance mode it was testing no longer exists.

@@ -420,8 +419,7 @@ else if (_servletContext instanceof ContextHandler.Context)
}
else
{
URL u = _servletContext.getResource(pathInContext);
r = _contextHandler.newResource(u);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this changed? Can _servletContext never be other than ContextHandler.Context?

@@ -471,6 +471,7 @@ public static String decodePath(String path, int offset, int length)
if (u == 'u')
{
// UTF16 encoding is only supported with UriCompliance.Violation.UTF16_ENCODINGS.
// This is wrong. This is a codepoint not a char
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be fixed then? 9.4.x too?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope - this is just how we implemented %u. It is not strictly correct, but let's not improve a feature we really want to remove.

Signed-off-by: Greg Wilkins <gregw@webtide.com>
@sbordet sbordet merged commit 3c32afa into jetty-10.0.x Jun 29, 2021
Jetty 10.0.6/11.0.6 FROZEN automation moved this from Review in progress to Done Jun 29, 2021
@sbordet sbordet deleted the jetty-10.0.x-6473-normalize-only-once branch June 29, 2021 13:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

3 participants