Skip to content

Numerous improvements to security considerations #487

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.

Sign up for GitHub

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

Merged
merged 6 commits into from
Nov 16, 2017
Merged

Numerous improvements to security considerations #487

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
7a25d4f
Add CREF for "self" link sub-path
handrews Nov 14, 2017
489dd5e
Clean up target attribute security considerations
handrews Nov 14, 2017
8a27a0c
Reference RFC 8288 in Security Considerations
handrews Nov 14, 2017
c0373a3
Move "self" link security bit to last subsection
handrews Nov 14, 2017
f314d36
Add a bit more about target attribute authority
handrews Nov 14, 2017
e3a4ffd
Security considerations for "content*"
handrews Nov 14, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 46 additions & 21 deletions jsonschema-hyperschema.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -563,7 +563,7 @@
</section>
</section>

<section title="Link Target Attributes">
<section title="Link Target Attributes" anchor="targetAttributes">
<t>
All properties in this section are advisory only. While keywords such
as "title" and "description" are used primarily to present the link
Expand Down Expand Up @@ -2382,28 +2382,35 @@ Link: <https://api.example.com/trees/1/nodes/456> rev=up
</section>

<section title="Security Considerations" anchor="security">
<t><cref>Need to reference the core and validation security considerations.</cref></t>
<section title='"self" Links'>
<t>
JSON Hyper-Schema defines a vocabulary for JSON Schema core and concerns all
the security considerations listed there. As a link serialization format,
the security considerations of <xref target="RFC8288">RFC 8288 Web Linking</xref>
also apply, with appropriate adjustments (e.g. "anchor" as an LDO keyword rather
than an HTTP Link header attribute).
</t>
<section title="Target Attributes">
<t>
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.
As stated in <xref target="targetAttributes"/>, all LDO keywords describing
the target resource are advisory and MUST NOT be used in place of
the authoritative information supplied by the target resource in response
to an operation. Target resource responses SHOULD indicate their own
hyper-schema, which is authoritative.
</t>
</section>
<section title="Target Attributes">
<t>
If the hyper-schema in the target response matches (by "$id") the hyper-schema
in which the current LDO was found, then the target attributes MAY be
considered authoritative.
<cref>
This whole section needs more work, but I do like having security
concerns around target interactions consolidated and addressed as a whole.
Need to add something about the risks of spoofing by "$id", but given
that other parts of the specification discourage always re-downloading
the linked schema, the risk mitigation options are unclear.
</cref>
</t>
<t>
The "targetMediaType" property in link definitions defines the expected
format of the link's target.
However, this is advisory only, and MUST NOT be considered authoritative.
Clients MUST NOT use the value of "targetSchema" to aid in the interpretation
of the data received in response to following the link, as this leaves
"safe" data open to re-interpretation.
</t>
<t>
When choosing how to interpret data, the type information provided by the
Expand All @@ -2421,11 +2428,29 @@ Link: <https://api.example.com/trees/1/nodes/456> rev=up
precautions for "targetSchema".
</t>
<t>
The "targetSchema" keyword has similar security concerns to that of
"targetMediaType".
Clients MUST NOT use the value of this property to aid in the interpretation
of the data received in response to following the link, as this leaves
"safe" data open to re-interpretation.
Protocol meta-data values conveyed in "targetHints" MUST NOT be considered
authoritative. Any security considerations defined by the protocol that
may apply based on incorrect assumptions about meta-data values apply.
</t>
<t>
Even when no protocol security considerations are directly applicable,
implementations MUST be prepared to handle responses that do not
match the link's "targetHints" values.
</t>
</section>
<section title='"self" Links'>
<t>
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.
<cref>
It is no longer clear what was intended by the "sub-path" option in
this paragraph. While paths are defined as a hierarchical system
by RFC 3986, there semantics of the hierarchy are not defined.
</cref>
</t>
</section>
</section>
Expand Down
16 changes: 16 additions & 0 deletions jsonschema-validation.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,7 @@
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC3987 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3987.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4329 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4329.xml">
<!ENTITY RFC5322 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY RFC5890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
<!ENTITY RFC5891 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml">
Expand Down Expand Up @@ -1351,6 +1352,20 @@
(with so-called "catastrophic backtracking"), resulting in a denial-of-service
attack.
</t>
<t>
Implementations that support validating or otherwise evaluating instance
string data based on "contentEncoding" and/or "contentMediaType" are at
risk of evaluating data in an unsafe way based on misleading information.
Applications can mitigate this risk by only performing such processing
when a relationship between the schema and instance is established
(e.g., they share the same authority).
</t>
<t>
Processing a media type or encoding is subject to the security considerations
of that media type or encoding. For example, the security considerations
of <xref target="RFC4329">RFC 4329 Scripting Media Types</xref> apply when
processing JavaScript or ECMAScript encoded within a JSON string.
</t>
</section>

<!--
Expand Down Expand Up @@ -1385,6 +1400,7 @@
&RFC3986;
&RFC3987;
&RFC4291;
&RFC4329;
&RFC5890;
&RFC5891;
&RFC6570;
Expand Down