Edit: I've replaced localStorage from the initial comment with cookies, my initial idea that localStorage is the problem was wrong.
Edit 2: Updated whole issue to say it is not mashlib related, but only requires any app login

Description

When logging in, solidcommunity stores a session cookie (nssidp.sid) that can be used for authentication. For html files running on *.solidcommunity.net this cookie will be attached to the request. If a malicious user creates a html file on victim.solidcommunity.net and the victim is logged, opening this html file gives the attacker full access to the pod.

Exploit

Preconditions:

1. Alice has used any app to login with NSS, thus the nssidp.sid session cookie is stored.
2. Alice gave Evil append access to a folder or file on Alice's pod

A simple exploit could look like this:

1. Evil saves exploit.html on Alice's pod (see below for example content)
2. Alice opens exploit.html, for instance by clicking on a link or being redirect by an app
3. requests made by exploit.html automatically attach the session cookies, and thus have read/write/create permissions of the whole pod (the same permissions as the logged in person)
4. exploit.html can make arbitrary requests on Alice's pod

exploit.html could be similar to following (abusing read access to private resources):

<script>
  fetch('/private/secret.txt')
    .then(res => res.text())
    .then(text => alert(text))
</script>

Impact

The result is, that an app or webId can escalate their permissions to the level of the logged in user. Thus, giving anyone append permissions to one file gives them control over the whole pod.

The required user interactions are either:

• logged in with any app and using an app that has append permissions on a file
• logged in with any app and giving a user append permissions on 1+ files and clicking on a phishing link

Note that I would have expected the exploit would work even if the html file is hosted on another pod (evil.solidcommunity.net). However, it seems it sends the session cookie but results in 403 when accessing the private resources. For me this 403 is unexpected, but I guess the server checks the sender domain with regards to the session cookie.

Migitation

The problem arises, because NSS sets a session cookie on solidcommunity.net and serves user-generated html files on solidcommunity.net. This cookie is attached to requests to solidcommunity.net and subdomains.

The solutions I see currently are:

1. remove the cookie
2. sandbox served html files
3. not serve html files

All of these are breaking changes.

Remarks

Related to: https://forum.solidproject.org/t/is-it-secure-for-pods-to-serve-html-files/6379/6 (about sandboxing / not serving html files)