-
Notifications
You must be signed in to change notification settings - Fork 148
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
Surfacing capability URLs #657
Comments
Closed
That's interesting. To start with, OAuth URLs and the class of 'sensitive' URLs (with tokens that change security capability, with URL:username and URL:password tokens) etc. don't have similar security indicators; sharing these are just as dangerous. There's of course, the requirement that developers are expected to implement 'capability' URLs correctly to this end, providing appropriate contextual information, in whatever standardized form they will have to appear as, to browsers and servers. There are also other web-based [non-standardized derivatives](https://patents.justia.com/patent/9864867) that use URI components for security capabilities.
…On Wed, Sep 11, 2024 at 4:54 PM Yoav Weiss ***@***.***> wrote:
There are a lot of capability URLs
<https://www.w3.org/TR/capability-urls/> out there, but both browsers and
servers are oblivious to the fact that a certain URL is a capability one.
If browsers were aware of capability URLs (e.g. through an attribute on
the link that got the user to open them), they could have e.g. warned users
if they are trying to share these URLs.
If well-meaning secure-context servers were aware of capability URLs (e.g.
through a header that the capability-aware browser would attach to the
relevant request), they could make sure that they don't find themselves in
the server logs.
I'm not 100% sure what less-well-meaning servers can do with capability
URLs from other origins, but presumably they should not be seeing these
(secure-context) requests unless the origin (or the user, or their
machine's administrator) trusted them to inspect the request.
I'd love folks' thoughts!
—
Reply to this email directly, view it on GitHub
<#657>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJUZPP2I466FOHOUFBLWWF3ZWAR7JAVCNFSM6AAAAABOAXVHWKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGUYTSNBWGE4TSNQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are a lot of capability URLs out there, but both browsers and servers are oblivious to the fact that a certain URL is a capability one.
If browsers were aware of capability URLs (e.g. through an attribute on the link that got the user to open them), they could have e.g. warned users if they are trying to share these URLs.
If well-meaning secure-context servers were aware of capability URLs (e.g. through a header that the capability-aware browser would attach to the relevant request), they could make sure that they don't find themselves in the server logs.
I'm not 100% sure what less-well-meaning servers can do with capability URLs from other origins, but presumably they should not be seeing these (secure-context) requests unless the origin (or the user, or their machine's administrator) trusted them to inspect the request.
I'd love folks' thoughts!
The text was updated successfully, but these errors were encountered: