search

json-schema-org / json-hyperschema-spec

A *future* location for the JSON Hyper-Schema I-D sources.
14 stars 4 forks source link

equivalent to or a sub-path of the request URI? #5

Open handrews opened 6 years ago

handrews commented 6 years ago

From the Hyper-Schema Security Considerations:

When link relation of "self" is used to denote a full representation of an object, the user agent SHOULD NOT consider the representation to be the authoritative representation of the resource denoted by the target URI if the target URI is not equivalent to or a sub-path of the URI used to request the resource representation which contains the target URI with the "self" link.

Does anyone understand the "sub-path" part of this? It seems a bit related to the old pathStart keyword. I can't find anything in RFCs 3986, 4287 (where "self" was first defined), 7230, or 7231 that indicates anything special about URI "sub-path"s, with respect to "self" links or otherwise.

@awwright do you have any idea what this was about? @Julian?

awwright commented 6 years ago

I'm not sure where that came from either. It probably intends to refer to the origin instead, following the Web origin security model.

I would expect the definition of the "self" link relation to give us all the necessary security concerns, though... what about it poses a unique threat to Hyper-schema?

handrews commented 6 years ago

what about it poses a unique threat to Hyper-schema?

No clue. Should we just remove this subsection?

handrews commented 6 years ago

@awwright Reading through this again, I think that the case this is addressing is the one in the collection example (that I just reworked yesterday), where each element in the collection representation is in fact a full representation of the item, and therefore each element has both a "self" link and an "item" link.

The issue seems to be the question of whether you can safely assume that the context representation of those "self" links can be used in place of fetching a representation from the "self" link's target, saving a network operation.

In this case, the sub-path stuff seems to line up. In that example, the "URI used to request the resource representation which contains the target URI with the "self" link" is /things, while the target URIs of the "self" links of the two collection elements are /things/1234 and /things/6789 (or something like that).

Those are sub-paths of the collection URI, which means that according to this guideline, you can treat the embedded element representation within the collection representation as an authoritative full representation, and skip fetching individual elements.

A corollary of this is that "self" links SHOULD NOT (or even MUST NOT) be used when the context representation is not a valid full representation (defined as validating against the full representation's schema, I suppose, which does leave some leeway assuming optional fields).

I see the point of this, but it's explained in a very convoluted way and I have no idea if it is grounded in any larger theory or security framework.

awwright commented 6 years ago

Oops, I thought I emailed back something like Yeah, we should rewrite this.

handrews commented 6 years ago

@awwright I did end up putting in a more detailed CREF along the lines of that last comment. Sorry if I missed an email or something, we'll definitely revisit this in the next draft.

Julian commented 5 years ago

(/me is just searching through this repo looking for mentions you hit me with that I missed in the torrent of emails :)

I don't unfortunately recall either.

handrews commented 5 years ago

@Julian you can actually filter on the X-GitHub-Reason: mention header if your email client allows that. Although I think the reason keeps being "mention" forever on that issue. But if you're not mentioned on all that many it should help.

Julian commented 5 years ago

Hmmmm that does in fact sound useful thanks, let's see if I can make that do nice things.

On Tue, Dec 18, 2018, 01:17 Henry Andrews <notifications@github.com wrote:

@Julian https://github.com/Julian you can actually filter on the X-GitHub-Reason: mention header if your email client allows that. Although I think the reason keeps being "mention" forever on that issue. But if you're not mentioned on all that many it should help.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/json-schema-org/json-schema-spec/issues/485#issuecomment-448060116, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUIXvadtqilvN2LUBmZcr94JY_yKo1nks5u6EIhgaJpZM4QclZs .