>> Title : A More Granular Web Origin Concept >> Filename : draft-nir-websec-extended-origin-00.txt > I have just submitted this draft. The purpose of this is to address the case where a single portal hides several real servers behind it, by translating their URLs into URL that seem to be from that server. > > In that case the same origin policy is not enforced correctly, because cookies and scripts from one server behind the portal (for example, a mail server) can be shared and can affect pages form another server behind the same portal. > > This draft proposes a header that will tell the client (browser) what the real origin is, and allow the client to apply the SOP. Yoav, SSL VPNs that proxy a whole bunch of web sites via a single host are indeed a security problem as they break the same-origin protections that the individual web sites expect. However, I don’t think this draft’s solution is the best approach. It requires browsers to fix what SSL VPN’s have broken; and doesn’t provide much improvement until the new functionality is implemented in all browsers and deployed to most users. Wouldn’t it be better for SSL VPNs to use lots of sub-domains? For instance, to map internal sites to: https://a.sslvpn.example.com/webmail https://b.sslvpn.example.com/wiki/index.html https://c.sslvpn.example.com/stuff If the “Extended-Origin” HTTP header approach does proceed… 1] You don’t need multiple Extended-Origin headers for successive portals in a path. A portal about to insert a header can just take into account any existing value if present. That is, insert a single Extended-Origin response header that is unique for each combination of {original-domain; original-extended-origin-header-value}. 2] I think it would be better to serialize an extended-origin as an additional sub-domain, not a fragment. The sub-domain could have a prefix so it cannot (or is highly unlikely to) clash with a real sub-domain. Example: → GET https://sslvpn.example.com/xyz ← Extended-Origin: asdhgasghd → Origin: https://xb--asdhgasghd.sslvpn.example.com -- James Manger |
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.