Brainstorm webapi vulnerabilities between the operator and a user and between users.

[nejucomo]

Problem: The webapi interface design seems to presume the node operator and users are mutually trusting. There is some demand for "public" web gateways to content in a LAFS network, where the users and gateway operator do not fully trust each other.

Resolution: This ticket is resolved when the vulnerabilities are enumerated to the operator coming from users, to the users from the operator, and from the users between themselves.

Bonus Points awarded for each of: configuration options which reduce a given vulnerabily's risk; workarounds which do not require code patches (external tools are ok); and outlines of code patches to reduce the vulnerability.

Related Tickets:

• #1663 is for documenting the complete URL tree in a concise table.
• #860 is a user request for a public gateway that does not expose the introducer furl.
• #587 points out that any webapi user may upload content (even without using capabilities).

[nejucomo]

User vulnerabilities to the gateway.

Fundamentally, a web gateway is an entity-in-the-middle, so users are vulnerable to:

• Every capability (and transitively reachable capability) is leaked to the gateway.
• A stock web browser won't perform any integrity checks, so the gateway can arbitrarily modify content.
• The gateway decrypts content, so the user has no confidentiality guarantees against the gateway.

These vulnerabilities compromise much of the utility of LAFS; never-the-less, the usefulness of making content available to public web users (without any custom software) is great enough that there's demand for a "public gateway".

Mitigation brainstorm: The situation could potentially improved by moving integrity and confidentiality support into the browser- if for example the user loaded javascript from a trusted site, which could then proxy encrypted requests through different HTTP interfaces to the underlying LAFS network.

[nejucomo]

User vulnerabilities from other users.

Capabilities may be leaked across browsers. For example, one user, by browsing ongoing or completed operations may be able to acquire the capabilities used by another user.

(I am not currently familiar enough with the operation / status features to have confidence about this situation.)

Mitigation brainstorm: Restrict operation / status features such that only the user initiating an operation has a "capability" (distinct from the existing filesystem read/write/verify capabilities) to view the status of that operation.

[nejucomo]

Operator vulnerability to users: Arbitrary upload.

Users can upload arbitrary content (such as by a PUT /uri request), so any accounting based on the gateway's identity cannot distinguish between users. (I am not familiar with the work on accounting. This vulnerability may soon be moot.)

Workaround: Blocking non-GET requests is sufficient to prevent content upload or modification.

[nejucomo]

Network vulnerability to users: Leaked introducer furl.

Any user of the webapi can learn the introducer furl, which in some use cases is undesirable.

[nejucomo]

A mitigation for comment:5 would be to improve the introduction system and/or accounting to separate out capabilities for discovering storage nodes, introducing storage nodes, or requesting storage. (Again, I'm unfamiliar with the current state of accounting, so this vulnerability may soon be well mitigated.)

[zooko]

I think this one is currently solved with regard to authority over files (excluding authority over operations -- see "ophandles" below), at least if we exclude "cross-user scripting" or "cross-user reference forgery" issues.

Replying to nejucomo:

User vulnerabilities from other users.

Capabilities may be leaked across browsers. For example, one user, by browsing ongoing or completed operations may be able to acquire the capabilities used by another user.

There is a Recent Upload Download page, but it doesn't use caps that grant more authority than the storage index does.

Mitigation brainstorm: Restrict operation / status features such that only the user initiating an operation has a "capability" (distinct from the existing filesystem read/write/verify capabilities) to view the status of that operation.

I think the current approach is even better: you can see the status of the operations of other users, but you can't get authority over the files involved.

ophandles

This one could be problematic. See docs/frontends/webapi.rst​ for the docs about ophandles. They are chosen by the wapi client, so if the user's client software chooses guessable ophandles, then the user could be accidentally allowing other users of the same gateway to cancel their operations. I'm not sure if ophandles can be used for anything other than canceling and checking the status of operations. I propose we open a separate ticket for this specific issue -- ophandles could be guessable and gateways could be shared among users.

[zooko]

Replying to nejucomo:

Network vulnerability to users: Leaked introducer furl.

Any user of the webapi can learn the introducer furl, which in some use cases is undesirable.

Workaround (low confidence): Blocking requests to the webapi / url prevents the user from learning the introducer furl. Warning: This may not be sufficient; I recommend waiting for more community confidence in this workaround before relying on it.

This is #860.

[zooko]

Replying to nejucomo:

Operator vulnerability to users: Arbitrary upload.

This is #1447.

[nejucomo]

Note, this use case has come up in another form in #1283. Windows services provide monitoring and scheduling features, but they are system-wide.

[nejucomo]

Note, this use case has also come up in #2045 which is related to Debian "daemonification" and might imply a system-wide daemon with separate user clients.

[nejucomo]

Replying to zooko:

Replying to nejucomo:

Operator vulnerability to users: Arbitrary upload.

This is #1447.

I disagree. #1447 is for implementing a specific (easy to implement) policy: No uploads at all.

However there are many more potential policies (which are not yet implemented) for upload, such as requiring users to provide some proof of allocated storage on a set of servers along the lines of the accounting roadmap.