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

Agent confusion issue #23

Open
rkaw92 opened this issue Dec 20, 2018 · 7 comments
Open

Agent confusion issue #23

rkaw92 opened this issue Dec 20, 2018 · 7 comments

Comments

@rkaw92
Copy link

rkaw92 commented Dec 20, 2018

It seems that this implementation of the WebID TLS verifier does not handle fragment identifiers correctly.
Let us take the example snippet from the README, and modify the WebID URI (that represents a real person, not the Profile URI) so that it points to another fragment:

// ...
subjectaltname: 'URI:https://test_nicola.databox.me/profile/card#somebodyelse'
// ...

If we run the script, the verification passes:

webid.verify(validCert, function(error, agentURI) {
  console.log('error: %s', error);
  console.log('agentURI: %s', agentURI);
});

The below is printed:

error: null
agentURI: https://test_nicola.databox.me/profile/card#somebodyelse

Even though there is no fragment "somebodyelse" in the file!

This is bad - if using an aggregated RDF file with multiple fragments representing different persons (a normal use case, according to WebID spec examples), we are able to impersonate any of them, provided that our key (modulus/exponent) exists anywhere in the same file.

The query used for finding the person fragment should probably be tweaked.

@melvincarvalho
Copy link
Member

Good catch. I think it would be worth adding a test for this.

@rkaw92
Copy link
Author

rkaw92 commented Dec 21, 2018

I guess we should be adding a selector (is that the SparQL term?) that only regards statements about our particular subject (identified by the WebID IRI) when verifying, rather than querying by key only.

@kjetilk
Copy link
Member

kjetilk commented Feb 4, 2019

@RubenVerborgh it seems you're the closest to make an assessment about it, I'm pretty much at loss here.

@RubenVerborgh
Copy link
Member

Proposed solution is right; currently, it selects all keys in the file, does not filter webid.

@melvincarvalho
Copy link
Member

Agreed.

Suggest the solution would be to add a test, with multiple webids in a single document.

Then use sparql to follow your nose and fix the failing test..

@kjetilk
Copy link
Member

kjetilk commented Feb 4, 2019

OK, I'm unfamiliar with the code, and don't feel confident about fixing it, but concretely, this entails modifying the SPARQL query in
https://github.com/linkeddata/node-webid/blob/master/tls/index.js#L14
so that ?webid isn't a variable, but set to the actual WebID?

@RubenVerborgh
Copy link
Member

Indeed; we can also just string manipulate the query.

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

No branches or pull requests

4 participants