Skip to content

add security note about accessing urls #1600

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

add security note about accessing urls #1600

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
160b151
add security note about accessing urls
gregsdennis Apr 26, 2025
6ef050f
update security note on URL access to actually address security issues
gregsdennis May 3, 2025
7237028
Update specs/jsonschema-core.md
gregsdennis May 7, 2025
522b4ef
remove mention of specific attacks
gregsdennis May 16, 2025
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
7 changes: 7 additions & 0 deletions specs/jsonschema-core.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1990,6 +1990,13 @@ A malicious schema author could place executable code or other dangerous
material within a `$comment`. Implementations MUST NOT parse or otherwise take
action based on `$comment` contents.

When encountering an IRI that also represents a valid file system or network
location, implementations are discouraged to automatically an operation to
access that location. Schema authors should take care when configuring
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The audience of the spec isn't schema authors and we shouldn't be speaking directly to them. We've moved away from that in other places and I think we should stick to that as a policy.

We can say the same thing this is saying, but from the perspective of the implementation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is probably the one place where it should be okay to address the schema author. They should know the risks of using an implementation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's fine to want to say this to to schema authors. I just don't think the spec is an effective way to do that. Few schema authors will actually read the spec. It's not for them. It's for implementers. Schema authors read documentation. If we want to address schema authors like this, that's the place to do it, not the spec.

I think we can include the same message just shift the language to address the implementer instead of the schema author. For example.

Suggested change
access that location. Schema authors should take care when configuring
access that location. Implementations that choose to support retrieval over untrusted
connections should require users to configure the implementation to enable that
functionality.

implementations to operate over a file system or network as this could expose
the host system to various security vulnerabilities, such as man-in-the-middle
attacks or data leaks.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want to sound alarmist, but RCEs are also a potential if there's the potential of bad parsing and maliciuos intent. I think MitM is a low risk, but a noteable consideration.

How do you imagine data leaks might happen? By virtue of making a request to a URL from a system which should be invisible?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A misbehaving implementation with access to the internet could send your data to another server, unrequested. To avoid this we instruct implementations to not make network calls by default. Thus making use of the network is opt-in, suggesting that the user understands the risks.

I can add the RCE risk to the list.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sure there are nuances that I'm not familiar with in this area, but I don't see any of these things as risks worth mentioning.

A misbehaving implementation with access to the internet could send your data to another server, unrequested

I don't see how that's possible. We're talking about retrieving schemas over a network. Information is coming into the system, never out. The only data that could be leaked is what public schemas your network is accessing.

I think MitM is a low risk, but a noteable consideration.

I see MitM as essentially the same thing as data leakage. MitM is about covertly intercepting communications that are thought to be done privately. If you're retrieving a publicly available schema there's no need for MitM because the schema is already public. Again, the only information that could be exposed is which schemas you're accessing.

RCEs are also a potential if there's the potential of bad parsing and maliciuos intent.

I'm not sure what you mean by this. It would need to be code send by the attacker that gets executed by the implementation that isn't intended to be executed by the implementation. I don't see how that's possible.


## IANA Considerations

### `application/schema+json`
Expand Down
Loading