Skip to content

build(dev-app): prevent directory traversal #18494

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

Merged
merged 1 commit into from
Feb 18, 2020

Conversation

jelbourn
Copy link
Member

No description provided.

@jelbourn jelbourn added pr: merge safe target: patch This PR is targeted for the next patch release labels Feb 13, 2020
@jelbourn jelbourn requested a review from devversion February 13, 2020 18:23
@jelbourn jelbourn requested a review from a team as a code owner February 13, 2020 18:23
@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Feb 13, 2020
Copy link
Member

@josephperrott josephperrott left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

@devversion devversion left a comment

Choose a reason for hiding this comment

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

LGTM. Mind giving context on why this came up?

@devversion devversion added pr: lgtm action: merge The PR is ready for merge by the caretaker labels Feb 13, 2020
@jelbourn jelbourn removed the action: merge The PR is ready for merge by the caretaker label Feb 14, 2020
res.end('Error: Detected directory traversal');
}
}

Copy link
Member

Choose a reason for hiding this comment

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

Would it be best to just disallow ../ in the requests? If we just want to go with that logic, then we could probably simplify it by doing it using path.relative? WDYT?

for (const rootPath of this._rootPaths) {
  const relativePath = path.relative(rootPath, path.join(rootPath, req.url));
  if (relativePath.startsWith('../')) { throw }
}

Copy link
Member Author

@jelbourn jelbourn Feb 15, 2020

Choose a reason for hiding this comment

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

I used the approach recommended by Google's security team. As I see it, it's safer because it ensures that, at the very end, the resolved URL didn't escape the webserver root.

My first approach wouldn't have caught all cases (https://wikipedia.org/wiki/Directory_traversal_attack#Variations_of_directory_traversal), and is more future proof in case mre ways of directory traversal are introduced.

Copy link
Member

Choose a reason for hiding this comment

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

Okay, that sounds reasonable.

I'm unsure about path.resolve though. The root paths are not file system paths in the dev-server, but rather Bazel manifest/runfile paths, so resolving paths from the cwd is incorrect. It doesn't impact the URL escape check in general, but it's technically not correct. It might be better to use path.relative to determine if the paths escapes the root path.

@jelbourn jelbourn added the action: merge The PR is ready for merge by the caretaker label Feb 18, 2020
@jelbourn jelbourn merged commit f3d43fe into angular:master Feb 18, 2020
jelbourn added a commit that referenced this pull request Feb 18, 2020
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Mar 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants