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

Signed Documents Can Be Modified In Certain Situations #117

Open
JaceHensley opened this issue Oct 8, 2020 · 2 comments
Open

Signed Documents Can Be Modified In Certain Situations #117

JaceHensley opened this issue Oct 8, 2020 · 2 comments

Comments

@JaceHensley
Copy link

JaceHensley commented Oct 8, 2020

jsonld-signatures@5.1.0
jsonld@2.0.2

When doing some testing I've come across a certain situation which will allow a signed document to be modified and still pass verification.

I've traced it back to this line in jsonld. So I wasn't sure if I should open a ticket there or here, please let me know if you'd like me to move this issue.

What's happening is if a "@type" entry is not mapped it is silently dropped from the expanded JSON and thus won't be a part of the digest. While unmapped properties are handled by the strict expansionMap provided in this library unmapped types are just dropped.

This means that the document can be modified after signing to add additional unmapped types and still be valid. On the other side it means that when signing you can unknowingly not sign the full document if you don't have all the "@type" values mapped properly.

I have made a reproducible test case here. To verify this issue you just need to:

npm i
npm run test
@dlongley
Copy link
Member

dlongley commented Oct 8, 2020

This is a known issue over in jsonld.js: digitalbazaar/jsonld.js#199

This happens because @type unmapped values are interpreted as relative URLs (relative to the document's base URL ... and if there is no base URL, they are dropped entirely, they are not treated as present in the document). We need a PR over there that will behave just like the expansionMap does that handles terms that do not use the base URL when expanding.

@JaceHensley
Copy link
Author

Okay cool, I'm seeing this happen before toRDF like that issue talks about. It happens in the expand.js. I'm fine with closing this issue in favor of that one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants