This repository was archived by the owner on Apr 12, 2024. It is now read-only.
fix(sce/urlUtils): Use baseURI for same-origin checks, and bump base#href to RESOURCE_URL #15537
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When a base tag is set in the page, relative links will be resolved to its href attribute. However, isSameOrigin currently checks against the location, so relative links wouldn't be considered same-origin for security purposes. This commit changes to baseURI: it should behave the same when baseURI is left to the default value, but that preserves the implicit trust in relative URIs when baseURI is changed.
It's hard to understand the ramifications of base href, but it allows changing the destination of relative links elsewhere in the document. Spooky action at a distance is enough to put it on the list of dangerous attributes.
IE seems to require base to be in head, and clean up after testing.
rjamet
changed the title
|
Something's wrong with IE9, I think that's an unrelated test that accepts example.com because setting the base#href to null didn't reset the baseURI in earlier tests. I'll try to fix it over the holidays. |
|
It's the same, I didn't see that... @adob's PR looks better than mine too (but he doesn't do the base change, which I should probably have split off mine). How do you prefer we move forward? |
|
If you think @adob's PR is better and since it was submitted first, we can merge that in and then you can add the base change on top of that (i.e. in a new PR). How does that sound? |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a base tag is set in the page, relative links will be resolved to its href
attribute. However, isSameOrigin currently checks against the location, so relative
links wouldn't be considered same-origin for security purposes. This commit changes
to baseURI: it should behave the same when baseURI is left to the default value, but
that preserves the $sce's implicit trust in relative URIs when baseURI is changed (which
was #15144).
And while I'm at it, bump base#href to RESOURCE_URL, since it affects security behavior.
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Bug fix for #15144 + fix the wrong base#href context.
What is the current behavior? (You can also link to an open issue here)
Base#href is just URL context, isUrlSameOrigin looks at the location for same-origin checks.
Does this PR introduce a breaking change?
Yes, if you dynamically set base#href or rely on your old origin being trusted after changing baseURI. I don't think that represents many apps, but it's hard to tell?
======
"End of the week" turned out to be optimistic, I'm sorry about the delay :/
I was wary of the way baseURI is handled, which differs a lot depending on browsers. Try setting base href="data:text/", and a href="html,foo", you'll see that chrome sets the baseURI but sets the href to the empty string, while Firefox keeps the href but doesn't set the baseURI. It's all very strange and I was afraid the checks wouldn't follow the behavior of the browser, but it's a red herring in this case. Angular just shouldn't let base href be controlled by an attacker (= RESOURCE_URL).