Security considerations for OAS and json schema

[ioggstream]

I expect

Security considerations for OAS and json schema.

They must clarify that referenced resources are usually dereferenced, and that related risks should be assessed, including:

• retrieval of non https resources
• loops and cycles
• ...

Is there something already baked on that ?

@jdesrosiers @darrelmiller

[jdesrosiers]

Security considerations: : See the "Security Considerations" section of {{jsonschema}}

Interoperability considerations: : See the "General Considerations" section of {{jsonschema}}

I've been meaning to port over these two sections from the current JSON Schema specification, but I haven't had the time yet. Here's the direct link to the security consideration section, https://json-schema.org/draft/2020-12/json-schema-core.html#rfc.section.13. Loops and cycles are covered, retrieval of non-https resources is not.

[ioggstream]

@jdesrosiers IMHO it's ok to leave the security/interoperability considerations in the JSON Schema specification document and integrate there the missing information (e.g. retrieval of other documents). Consider that considerations (:P) are not supposed to contain normative statements, which should be moved into the specifications (e.g. since "Validators MUST NOT fall into an infinite loop", are validators that falls in inf-loop non compliant with the spec?)

The issue remains for OAS, which does not seem to come with Security considerations, but I @darrelmiller is welcome to correct me.

[jdesrosiers]

IMHO it's ok to leave the security/interoperability considerations in the JSON Schema specification document

The problem is that there is no one place for us to link to this information. There are many dialects in use and not all of them are defined by the JSON Schema organization. Most notably that includes OpenAPI and MongoDB. I was thinking we could have this information in this document so all others don't need to repeat it in their custom dialect documentation. However, we do leave the door wide open for all kinds of dialects, even ones very different than the official releases. So, I think we need a sort of hybrid approach here. This document should only include security considerations related to dialect selection and then inform the reader to look up the security considerations specific to the dialects their implementation will support.

[ioggstream]

@jdesrosiers sounds reasonable but I suggest to file a PR on that so that we can discuss on the specific content.

[darrelmiller]

@ioggstream The OAS specification does not have a security considerations section. It probably should. I would say the primary concerns are being able to create loops with $refs and the fact that $refs can access external documents with arbitrary URLs. Also the externalValue property of an example object can reference any external resource of any media type.

[ioggstream]

@darrelmiller to me, it is ok to create a page on the OAS website / repo and reference that page instead of baking complete security considerations in this specification.

Here we can just briefly mention the use of $ref if you / @jdesrosiers think it is appropriate.

Please let me know so that we can move forward

[darrelmiller]

@ioggstream I think a simple mention of external references would be sufficient in the OAS media type registration.

[ioggstream]

Ok, but those reference needs to exist before publication ;) where can we place them?

Even an initial page is ok to create a reference.

[darrelmiller]

@ioggstream Sorry, I misunderstood. I thought by

Here we can just briefly mention the use of $ref

you meant within the media type registration document. I can talk with the OAS folks about creating a security considerations document.

[ioggstream]

@darrelmiller thanks. Since there are general considerations valid for both jsonschema and OAS, in #49 I added references to [OAS] and filed a very short section in this document which I think it's worth having.

In [OAS] I just found a security reference in https://spec.openapis.org/oas/latest#rich-text-formatting but I think that a long document can be sorted out. I could be happy to support the editing in OAS.

If #49 is OK for you, we can leave this to jsonschema discussion.

[ioggstream]

@jdesrosiers sorry for the late reply WRT where to store Security Considerations for Json Schema

that there is no one place for us to link to this information.

IMHO just file a section in the current spec. If you want I can file a PR.

There are many dialects in use and not all of them are defined by the JSON Schema organization.

IMHO we should just focus on the latest spec: aka "Best is enemy of good":

• considerations on the latest draft are a good starting point even for dialects;
• you could add guidelines for what dialect writers MUST/SHOULD define;

This document should only include security considerations related to dialect selection
and then inform the reader to look up the security considerations specific to the dialects their implementation will support.

Since iiuc there are differences in the JSON Schema community about how/where to define this dialect selection, this approach might take longer though. WDYT about the light approach used in #49 for OpenAPI?

[darrelmiller]

@ioggstream We discussed this topic in the OpenAPI call this week. We will publish a security considerations document in the OpenAPI GitHub repo to address this requirement.

[ioggstream]

@darrelmiller thanks! Let me know if you need some feedback. I hope once I close some of those I-D to have more time to support OAS specifications.

[darrelmiller]

@ioggstream There is a security considerations document in the OAS project now. https://github.com/OAI/OpenAPI-Specification/blob/main/SECURITY_CONSIDERATIONS.md Future versions of the specification will likely incorporate this text.

[ioggstream]

@darrelmiller PTAL at OAI/OpenAPI-Specification#3620