Bug Description

If a user (or group) creates a private page and gives it a secret URL, and then the page is accessed by the secret URL on a public computer and the user doesn't close their browser window afterwards, other users will also be able to access that page by its normal url or its secret URL.

This can defy user expectations of access rights.

Eg
1. group A admin creates a page and shares it only with the group, the page has the id=8
2. group A admin create a secret url for the page, eg /view/view.php?t=nFlSjpVuUCawH6TxP7A3
3. User 1, who is not in the group, goes to the page by its secret URL. (While using a computer at the library.)
4. User 1 then logs out, but doesn't close their browser window.
5. User 2 comes to the computer and goes to /view/view.php?id=8

Expected result - User 2 can't access the page as they don't know the secret url

The way Secret URL currently works, is that when you access the page by its Secret URL (i.e. /view/view.php?t=<secret token here>), we store that secret token in a "viewaccess" cookie in the browser. This cookie has a browser session lifetime.

Then, in can_view_view(), we check for that viewaccess cookie in addition to other checks. This means that, once you view a page by its secret URL, you can continue to view the page by its normal URL, until you close your browser window.

A similar system is in place for pages viewed by mnet, except that the URL has "mt=", the cookie is "mviewaccess", and can_view_view() makes sure you're logged in as an MNet user.

There's also a "caccess" cookie, which is set instead of viewaccess or mviewaccess if the page is in a collection. (Secret URLs for a page give access to the whole collection.) This is actually a mild bug -- it should be a separate "mcaccess" cookie for a collection page viewed via MNet.

Oh yeah, the reason why we have this separate access cookie, is to support a few typical use-cases:

Use case 1: You go to a Page by its secret URL. You navigate to the detail page for one of the artefacts on the page. Then on the artefact page, you click the link to go back to the Page itself. The link on the artefact page, having been generated automatically by Mahara, will be a link to the page's real URL, not its secret URL. So if we didn't have the cookie, you'd get "access denied".

Use case 2: You go to a Page by its secret URL. You interact with some block that uses JSON. The JSON script checks to make sure you have access to the page the block is on, by using can_view_view(). If you didn't have the cookie, the JSON script wouldn't know you have access to the page, and it would error out.

Use case 3: Someone emails you a secret URL link. You click on it, and your browser opens and you see the page, but you're not yet logged in to Mahara. You click around to a few artefact detail pages on the page, then you decide you want to leave a comment, so you log in. After login, you're on your dashboard. You use your browser history and go back to the most recent time you visited the Page itself, which thanks to your artefact clicking, will be the page's real URL not its secret URL. If the cookie was stored in $SESSION, it would have been cleared when you logged in, and you'd see "access denied".

After discussing this with Hugh, we decided on the following changes that should be made to improve the security of Secret URLs:

1. As Robert suggested, clear the access cookies when a user logs out. Users probably expect this to happen.

2. When an unathenticated user accesses a secret URL, make the access cookie expire after 1 hour (or some other reasonable span).

I also considered but rejected these ideas:

1. Clear the access cookie when you log in. I rejected this because it breaks Use case 3 in my previous comment.

2. Do a 301 redirect to the page's real URL immediately upon accessing it by its secret URL. This would prevent the secret URL from being stored in the browser history (in most modern browsers). But on further consideration, I think this would detract too much from usability. For instance, there's the legitimate use-case where a user clicks on a secret URL link in an email, and then bookmarks the page while looking at it. If we had 301'ed them to the page's real URL, then their bookmark would not contain the access token, and it would give them "Access Denied" when they tried to use it.

It's worth noting there's kind of a catch-22 here. The changes I'm suggesting (clearing the access cookie on logout, and putting a time limit on the access cookie for logged-out users) are both rather moot if the secret URL is still in the browser history.

BUT, if we take the secret URL out of the browser history, we significantly impact usability. Legitimate users, on private computers, will experience situations where they cannot use their browser history or bookmarks to access pages by secret URL, and as non-technical users they will probably not understand why.

All that we gain from these changes is that if a subsequent user on the same computer somehow stumbles across a link to the page by its normal URL, they will not be able to access it. But again, if the access cookie is present in the browser, then it means the browser window hasn't been closed, and that means the browser history will probably still be present, with the secret URL in it.

In fact I'd guess that in the reported case, students are probably using the browser history to find these pages in the first place. Which means these fixes won't help at all.

Hm, so maybe we should change this to "Won't fix" and tell people to secure their public computers better?

Another alternative would be to add some kind of public computer detection system, which forces the 301-redirect for secret URLs. But that would require the public computer to announce itself in some way, and there doesn't seem to be any kind of existing framework for that. I guess we could do something like store a list of IP addresses, but I bet many schools probably have their computers on dynamically assigned IP addresses.

I've pushed a patch to clear secret-url access cookies on logout. I'm also changing this one from "Private security" to "Public security" because it is more a problem with the setup of the public computers, than with Mahara itself.

Changed in mahara:

importance:

Critical → Low

information type:

Private Security → Public Security

summary:

- Can illegially access pages that contain a secret url by normal url+ Secret URLs used on public computers

summary:

- Secret URLs used on public computers+ Secret URLs used on public computers leak access to later users of the+ same browser session

summary:

Secret URLs used on public computers leak access to later users of the- same browser session+ same browser

Bug 1385564: This doesn't provide much additional security, because if
the access cookies are still in your browser session, then the secret URL
itself is probably still in your browser history. But if someone goes to
the trouble of logging out *and* clearing their browser history, this
will ensure that it actually does end the secreturl access cookie like
they'd expect.

It would be good if there was a way for mahara to tell the browser not to remember the history when accessing a secret url link - but as there doesn't seem to be a way to do that we will need to educate the user somehow about deleting their history or using private window when accessing a secret url.

You just have to do a 302-redirect to the page's real URL. But the problem is that it'll also keep the secret URL out of the address bar, and that will interfere with the user's ability to bookmark the URL, and I think that's too much of an impact on usability.

For that matter, kicking the secret URL out of the browser history would also have too negative an impact on usability. I know when I access Google documents that are shared with me by URL, for instance, I usually rely on my browser history (specifically, address-bar autocomplete) to return to the document later. That wouldn't work if we eradicated the secret URL from the browser history.

Bug 1385564: This doesn't provide much additional security, because if
the access cookies are still in your browser session, then the secret URL
itself is probably still in your browser history. But if someone goes to
the trouble of logging out *and* clearing their browser history, this
will ensure that it actually does end the secreturl access cookie like
they'd expect.

Bug 1385564: This doesn't provide much additional security, because if
the access cookies are still in your browser session, then the secret URL
itself is probably still in your browser history. But if someone goes to
the trouble of logging out *and* clearing their browser history, this
will ensure that it actually does end the secreturl access cookie like
they'd expect.

Bug 1385564: This doesn't provide much additional security, because if
the access cookies are still in your browser session, then the secret URL
itself is probably still in your browser history. But if someone goes to
the trouble of logging out *and* clearing their browser history, this
will ensure that it actually does end the secreturl access cookie like
they'd expect.