-
Notifications
You must be signed in to change notification settings - Fork 27.4k
Consider base URL when deciding if a URL is allowed by 'self' URL policy #15144
Comments
Sounds good to me too, a base href is a sign that the destination is trusted, that's in line with the same-origin whitelist. (Small caveat, base href doesn't seem to require a RESOURCE_URL to be set in bindings, and I'm not entirely sure whether it affects things that can run scripts, like script src. If it does affect these, it definitely should be a RESOURCE_URL context. I'll write a PR.) |
Maybe it is indeed a good idea to also sanitize |
That's implicit in the resource url contract: the default whitelist won't allow different protocols than the current page, and that's also why a resource_url is valid in URL context. I don't really know how weird things like base href="data:text/html" behave (at least this hasn't executed javascript: URLs in a while), but you'd have to whitelist them first for it to work. I'll run some tests before the end of the week and write a PR at least for the context thing. |
Page authors can use the `<base>` tag in HTML to specify URL to use as a base when resovling relative URLs. This can cause SCE to reject relative URLs on the page, because they fail the same-origin test. To improve compatibility with the `<base>` tag, this commit changes the logic for matching URLs to the 'self' policy to allow URLs that match the protocol and domain of the base URL in addition to URLs that match the loading origin. **Security Note:** If an attacker can inject a `<base>` tag into the page, they can circumvent SCE protections. However, injecting a `<base>` tag typically requires the ability to inject arbitrary HTML into the page, which is a more serious vulnerabilty than bypassing SCE. Fixes #15144 Closes #15145
Page authors can use the `<base>` tag in HTML to specify URL to use as a base when resovling relative URLs. This can cause SCE to reject relative URLs on the page, because they fail the same-origin test. To improve compatibility with the `<base>` tag, this commit changes the logic for matching URLs to the 'self' policy to allow URLs that match the protocol and domain of the base URL in addition to URLs that match the loading origin. **Security Note:** If an attacker can inject a `<base>` tag into the page, they can circumvent SCE protections. However, injecting a `<base>` tag typically requires the ability to inject arbitrary HTML into the page, which is a more serious vulnerabilty than bypassing SCE. Fixes #15144 Closes #15145
Page authors can use the `<base>` tag in HTML to specify URL to use as a base when resovling relative URLs. This can cause SCE to reject relative URLs on the page, because they fail the same-origin test. To improve compatibility with the `<base>` tag, this commit changes the logic for matching URLs to the 'self' policy to allow URLs that match the protocol and domain of the base URL in addition to URLs that match the loading origin. **Security Note:** If an attacker can inject a `<base>` tag into the page, they can circumvent SCE protections. However, injecting a `<base>` tag typically requires the ability to inject arbitrary HTML into the page, which is a more serious vulnerabilty than bypassing SCE. Fixes angular#15144 Closes angular#15145
Angular SCE currently rejects perfectly valid relative URLs in some situations when a tag is used. For example, if the page contains
<base href="http://www.example.com">
, Angular will start to reject relative URLs like 'foo.template.html'. Full example at https://plnkr.co/edit/3sFwq1d2d7wiWVBx4OHnThe root cause is that the urlIsSameOrigin() function in urlUtils.js matches against location.href instead of, or in addition to, document.baseURI.
Angular should permit URLs if protocol/host/port matches the base URL being used.
Affects AngularJS v1.5.8.
The text was updated successfully, but these errors were encountered: