-
Notifications
You must be signed in to change notification settings - Fork 9
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
Import vulnerabilities #43
Comments
I susepct that ShEx's issues are almost identical JSON-LD's issues (or owl:imports, or XInclude). Can we just crib your solution when you get there?
I think these three vulnerabilities are the same as for dereferencing the initial document (be it a schema, JSON-LD doc, OWL ontology). Web Arch caveat emptor?
I think embedding could help efficient caching of mutable resources but you'd never want the embedded form to trump the dereferenced. If you want the embedded form to win, you don't need the IMPORT (or @context dereference).
Yeah, by having a language where IMPORTs can have IMPORTs, we have an exploitable recursion.
Fascinating. We could implement that like:
|
poking @gkellogg to see what we can steal from JSON-LD 1.1
Come to think if it, that's pretty much the same as generating an infinite schema, modulo more per-request cost in non-pipelined HTTP connections. I think the biggest vulnerability would have been to clients with a less-than-graceful handling of circular imports, but that's expicitly tested in 2RefS1-Icirc, where 2RefS1-Icirc circularly imports 2RefS1-Icirc and 2RefS2-Icirc.
Did JSON-LD ever provide any guidance like that? |
The import feature creates vulnerabilities similar to the JSON-LD remote context loading. In the case of JSON-LD, the document loader provides a means of avoiding accessing remote resources, although it's still come under a fair amount of criticism (See w3c/json-ld-syntax#108 and w3c/json-ld-api#14 for example).
The spec should address this concern and/or provide mitigations. One area that JSON-LD may pursue in the future is the use of integrity checks (ala https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity).
The text was updated successfully, but these errors were encountered: