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

Closed
wants to merge 6 commits into from
Closed

add security note about accessing urls #1600

Changes from 3 commits
Commits
Show all changes
6 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
823d864
Update specs/jsonschema-core.md
gregsdennis Jun 7, 2025
d867301
update security paragraph after suggestion commit
gregsdennis Jun 7, 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 from automatically making an operation to
access that location. Schema authors should take care when configuring
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