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

No "Path Segment Normalization"? #28

Closed
kanongil opened this issue Feb 13, 2017 · 6 comments
Closed

No "Path Segment Normalization"? #28

kanongil opened this issue Feb 13, 2017 · 6 comments
Assignees
Labels
bug
Milestone

Comments

@kanongil
Copy link
Member

@kanongil kanongil commented Feb 13, 2017

@hueniverse

This comment has been minimized.

Copy link
Member

@hueniverse hueniverse commented Feb 13, 2017

Cause no one cared about this until now?

@kanongil

This comment has been minimized.

Copy link
Member Author

@kanongil kanongil commented Feb 13, 2017

I could probably do a PR for this if you think it is likely to get merged. It should make hapi safer by never including "./" and "../" path segments in the routing.

Note that normalization can change the matched route when such relative paths are used. As far as I know, it should not be an issue in browsers, which applies the normalization to outbound requests.

It is also somewhat unlikely that it affect any other clients negatively, but it will be a breaking change (unless it's a non-default option).

@hueniverse

This comment has been minimized.

Copy link
Member

@hueniverse hueniverse commented Feb 13, 2017

So the idea is to turn /a/./../b into /b?

@kanongil

This comment has been minimized.

Copy link
Member Author

@kanongil kanongil commented Feb 13, 2017

Pretty much, yes.

As I said, browsers already do it before sending a request, so no change in behavior there. Even modern versions of curl does it (see https://daniel.haxx.se/blog/2013/07/30/dotdot-removal-in-libcurl/). Makes sense to do it at the server level as well, removing potential attack vectors.

@kanongil

This comment has been minimized.

Copy link
Member Author

@kanongil kanongil commented Feb 13, 2017

Actually, I think the current behavior could be considered a bug.

If I interpret the RFC correctly, requests for http://server/a should in fact always generate the exact same response as http://server/b/../a.

@hueniverse

This comment has been minimized.

Copy link
Member

@hueniverse hueniverse commented Feb 14, 2017

I'll take a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.