Document attacks based on poorly secured discovery mechanism

[elf-pavlik]

This is related to #9
An example scenario:

1. User authenticates with a compromised application
2. The application is allowed to make modifications to the discovery mechanism
3. Compromised application inject location controlled by the attacker for financial records into the discovery mechanisme
4. Now other applications storing financial records will store it in the location controlled by the attacker

[elf-pavlik]

More advanced attack, could possibly migrate all existing user's data, of interest to the attacker, to attacker's controlled storage. Since raw IRIs are often not visible to the user, they possibly wouldn't even notice that the attacker is now hosting their current and yet-to-be-created data.

[michielbdejong]

Good point. Reminds me of Trusting Trust :)

Basically, I guess the moral is that editing the main webid doc should require a lot of trust, on a par with "root" access to the pod. The Authorization Agent should make this very clear to the end user. A profile editor that is not fully trusted should only be allowed to edit extended webid docs.

[angelo-v]

There should also be warnings in the way todays apps inform you about "log in from a new location": "You added a completely new storage at http://malicious.example. Was that really you?"

[elf-pavlik]

@angelo-v, We assume here that the app is colluding with the attacker, either a malicious app or a compromised app. Which part of the system would be responsible for warning the user?

[angelo-v]

I don't have a technical solution, I am merely describing what I would expect from a user perspective.

It could be a trusted agent /app that keeps a look on that or the pod (provider?)

But it could be also certain apps like umai for recipes. If it discoveres a new location for recipes (added by a malicious app) it could make the user aware and let them confirm.

[elf-pavlik]

But it could be also certain apps like umai for recipes. If it discovers a new location for recipes (added by a malicious app), it could make the user aware and let them confirm.

Does it assume that other apps using that data, eg. umai , keep some cache for example in local storage and whenever they do discovery they compare it to what they have cached?

My first countermeasure will be to only have a trusted agent (e.g. SAI authorization agent) to have access to modify the discovery mechanisms. All the other apps, which have the lowest trust level in the whole ecosystem of Solid product classes, always start by asking the User's authorization agent for specific access. If new entries have to be created in the discovery mechanism, the authorization agent takes care of that based on the user's authorization for the app requesting access.

Allowing random apps to touch the discovery mechanism is setting oneself up for failure from the start.

[TallTed]

In #12 (comment), please note that sequences of actions (a/k/a steps) should be represented as ordered lists. Unordered (bullet) lists should be used for parallel things

[renyuneyun]

I was prompted to take a read at #9 (from the discussion last week at SolidOS meeting) and maybe leave some of my cents to the topic. As the PR is merged, probably this issue is the best place to comment on (because my point also relates to this topic)?

tl;dr: I agree that there are security issues as covered in these two posts. But I don't think it is a good idea to separate the discussion, and (more importantly) to propose separate solutions. We should only have one mechanism.
Unless we can find a mechanism compatible with existing Solid Spec and Solid implementation (or requiring very minimal changes), changing Solid Spec or changing Solid implementation should be both acceptable. I cannot find such a mechanism without any changes, so I'm proposing a mechanism below, which requires slight evolvement to Solid Spec.

---

Basically, the two questions are the same: how do we prevent a (potentially malicious, but attractive) application from modifying important triples. For #9 it was the oidcIssuer, for here it is the publicTypeIndex.
Indeed, from the "sensational" point of view, the identity is more important, and type index (or other discover mechanisms) is less important that it, but more important than, e.g., name of the user.
But my counterargument is: how do we know there is not a 3rd level of important data (e.g. public keys) that we need to protect, and do we need a separate discussion for that and a separate mechanism? How about a 4th, 5th, ...?

So, my view is: we need one mechanism to deal with all these situations. The level of "importance" is not (somewhat) arbitrarily determined by us, but by the user -- for practical reasons, we can set defaults, but users should be allowed to make their own decisions.

Then the question is: what mechanism?

My view is similar to the things @elf-pavlik and @angelo-v mentioned above: a "confirmation" step for the user (and also an explanation within it), and the user can configure (and Solid, e.g. CSS, can provide a default) which "agent"/"component" (called "special agent" below) [s]he wants to use for the confirmation step (called "special authorization" below).
But I don't think SAI (literally) should be used for this -- this job of (special) authorization should be made separate from SAI, and leave the interoperability part back to the core of SAI. My view is that this special mechanism should be transparent/invisible to the App. If completely transparent/invisible is not possible, the App should not need a separate library for handling this.
The "level of important" should be part of the configuration set by the user. Again, we can have defaults, but the user must be able to override and customize. Thus, this configuration should also be stored in the Pod (i.e. under Solid Protocol) in general; and this configuration should also be subject to the same mechanism.

More concretely, for the two cases #9 and this issue mentioned, we can have the following:

1. In the configuration, oidcIssuer and publicTypeIndex within WebID + Solid WebID Profile are "protected"
2. When the Solid Service receives requests to change triples, it asks the special agent whether this should be permitted (I would anticipate this is a blacklist-ish check, so won't be too complicated);
3. If the special agent says user authorization is needed, it (through some mechanism to be determined, e.g. automatically? browser extension?) redirects the user to the special authorization page, where the user sees the action, and potentially some warnings or explanations
4. If the user approves, the agent says "approve" to the Solid Service, and the data is updated.

Although I tried to minimize affects, this requires some changes to Solid spec, because the Solid Service needs to do two additional things compared to now:

1. Be registered with this special agent
2. Ask and wait for reply from the special agent

All other actions are performed by the special agent. So the agent can also be fully autonomous if needed.

The agent can run from anywhere; the user can dynamically [de-]register it whenever [s]he wants; the Solid service can have a fall-back agent which approves anything. (Of course, protocol needs to be defined for the interaction. But that should not be complicated.)
(Alternatively, define a standard specification for controlling the agent behaviour, and make that a part of Solid Spec and the agent a built-in to the Solid Service.)

A tempting scenario is to be combined with a browser extension: the user is only deemed "online" if the browser extension is activated, and the special agent will only ask the user in that case, and rejects in all other cases. (Or, even, the browser extension itself is the special agent; but that has problems if the user somehow lost access to the same browser extension.) Because it's a browser extension, it can easily start a pop-up or new tab. That can make the special authorization mechanism completely transparent/invisible to the App.

[elf-pavlik]

Thank you, @renyuneyun, for sharing your insights.

The "level of important" should be part of the configuration set by the user. Again, we can have defaults, but the user must be able to override and customize. Thus, this configuration should also be stored in the Pod (i.e. under Solid Protocol) in general; and this configuration should also be subject to the same mechanism.
[...]
In the configuration, oidcIssuer and publicTypeIndex within WebID + Solid WebID Profile are "protected"

I want to clarify if you are discussing it with the assumption of resource-level access control or if you are considering exploring triple-level access control. Your comment suggests access control support is needed based on some triple patterns instead of just working on the resource level.

Besides protecting the WebID documents from where typically everything is "following their nose." How do you see the management of the type index itself? In SAI, the user's Authorization Agent is the highly trusted party with exclusive access to modify the equivalent of type indexes. Every app in the authorization flow requests what 'types' of data it works with, and the user grants or denies that access at their Authorization Agent. If, based on that, a space needs to be designated for some new 'types' of data, the Authorization Agent is responsible for taking care of it. In your approach, which party/component is responsible for designating new spaces for new 'types' of data?

[renyuneyun]

Sorry for taking quite some time to respond, as other stuffs were occupying time.

I want to clarify if you are discussing it with the assumption of resource-level access control or if you are considering exploring triple-level access control. Your comment suggests access control support is needed based on some triple patterns instead of just working on the resource level.

That is an important observation. I was indeed talking about triple-level access control, for this special mechanism. I'm aware WAC and ACP are both resource-level mechanisms, and do not intend to evolve to triple-level yet.

Compared to triple-level mechanisms, document-level mechanisms features:

• Potentially compatible with existing access control mechanisms
• No more

Compared to a document-level mechanism, triple-level mechanisms has the following benefits:

• No need to enforce separation nor location of conceptually-the-same documents in a special way (determined by the proposer, not the Pod owner)
• Applies to any resource whenever needed, even if it's app-generated
• No changes for the App developers shall be needed -- they don't have to carefully consider how resources are organised (i.e. requiring to transfer to new schema/layout thus leaving a lot of broken Apps and libs)
  • Depending on the implementation, this may not even need to introduce an additional library or function call

To me, that's a clear signal to prefer triple-level mechanisms. This is not a full access control policy language (at least yet), so it doesn't have to be so carefully thought about, compared to, e.g., ACP. Existing access control mechanisms won't be broken as they are the main ones, and this special mechanism only applies to "critical" things.

How do you see the management of the type index itself? ... In your approach, which party/component is responsible for designating new spaces for new 'types' of data?

As a response in-line-with this issue topic, for things equivalent/similar to SAI's Authorization Agent, I don't think that needs to be separately introduced, as manual authorization can be performed by the special agent/pop-up. For example, for Type Index, they may be set as protected resources as well (in either triple-level or document-level), and the user makes manual special authorization whenever they are to be updated. Or, if they are not that sensitive (i.e. the same App doesn't have to request permission every time it updates the TI), ACP is the choice as it can assign and deny permissions based on both WebID and ClientID.

(The discussion below are out of bound. Please safely ignore them if wanting to keep the discussion alinging with the topic.)

As a response out-of this issue topic, my answer would be to rely on alternative more automated mechanisms, such as the perennial data terms of use (disclaimer: I'm the author of that paper). They would make the whole flow of authorization more automated:

1. The user first assigns policies for their data (i.e. data policy).
   • Different data are expected to have different policies, whenever necessary.
   • Primirarily, the policies talk about the expectations of how they can/cannot be used, not about which application can/cannot use them.
2. Apps come with their policies (i.e. app policy).
   • The app policy describes how they intend to use which data.
   • Combined with other parts of the policies, I believe that is similar to the "type" of SAI's Authorization Agent?
3. The policy engine can make decisions of authorization based on their compatibility check results.
4. Manual interventions may also be introduced if the user is online.

See also the Spec or meta repo for detailed information.

Of course, more work is needed before that can be realised in real-world, in particular regarding how can the user write these data policies efficiently, and how "data" is designated. SAI's existing exploration of shape trees can be useful. Also, maybe SAI's Authorization Agent can be transformed to a behaviour-learning component that learns and proposes data policies for the user.