Skip to content
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

Add requirements or recommendations about allow/deny lists for reference target retrieval #4037

Open
handrews opened this issue Aug 17, 2024 · 2 comments
Labels
re-use: ref/id resolution how $ref, operationId, or anything else is resolved security: meta Metadata in and about the specification
Milestone

Comments

@handrews
Copy link
Member

As multi-document OADs become more important due to both new use cases and an increasing number of OADs that are far too large to work with as a single document, we should be more clear about the resource location and retrieval process.

In particular, there is a security risk to fetching resources from arbitrary locations. We should at least RECOMMEND some sort of allow/deny functionality, and require (MUST) a sensible default behavior.

For example, it's conceivable that a poorly designed API runtime tool running at improperly elevated privilege could be induced to load a sensitive file, get confused, and display it in an error message over the network. Or, a tool that does something bad like eval() fetched JSON could be sent a malicious bit of JavaScript instead.

@handrews handrews added re-use: ref/id resolution how $ref, operationId, or anything else is resolved security: meta Metadata in and about the specification labels Aug 17, 2024
@handrews handrews added this to the v3.2.0 milestone Aug 17, 2024
@miqui
Copy link
Contributor

miqui commented Aug 25, 2024

@handrews
If you have something like this:

paths:
  /users:
    get:
      summary: Get all users
      responses:
        '200':
          $ref: './components/responses.yaml#/UserListResponse'

How does your proposal work in this split, but local file example? I like your idea btw.

@handrews
Copy link
Member Author

@miqui First I want to make clear that I do not want to mandate any specific pre-determiend allow/deny configuration (except that I think the default should be "deny all" and you should have to configure either a specific allow list or "allow all", which should probably be named "enable gaping security hole") ;-P

We could encourage some "sensible" common configurations, like "anything in this (local or remote) directory or any subdirectory of it is allowed." That's would handle the very typical configuraiton where the entry document is in a directory, and the "split" documents are in sub-directories mirroring the intended JSON/YAML structure of the un-split document. That would place the $ref in your example within the allowed reference target scope.

But (if that is the only allow-rule), if someone changed it to $ref: https://this-is-a-bad-place.com/malware.yaml, attempts to resolve that changed reference would fail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
re-use: ref/id resolution how $ref, operationId, or anything else is resolved security: meta Metadata in and about the specification
Projects
None yet
Development

No branches or pull requests

3 participants
@handrews @miqui and others