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

Further investigation into this problem:

What needs to happen is a user needs to access the secret url so that a cookie is set in the browser.

Then another user using the same browser session can access the page via the normal url.

This can happen in a school type situation where different people use the same machine.

To fix: have the secreturl cookies be killed on logout rather than closing of browser.

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.

Patch for "master" branch: https://reviews.mahara.org/3873

Reviewed: https://reviews.mahara.org/3873
Committed: http://gitorious.org/mahara/mahara/commit/9bceca2b8a782aa61564b860a4db8743aa920cdd
Submitter: Robert Lyon (<email address hidden>)
Branch: master

commit 9bceca2b8a782aa61564b860a4db8743aa920cdd
Author: Aaron Wells <email address hidden>
Date: Wed Oct 29 01:41:13 2014 +1300

Clear secreturl access cookies on logout

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.

Change-Id: Ia75f58015ab2cb54c9184cdc8b5bf32dfe543733

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.

There is a way to keep the URL out of the browser history, as I mentioned here: https://bugs.launchpad.net/mahara/+bug/1385564/comments/5 .

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.

Patch for "1.10_STABLE" branch: https://reviews.mahara.org/4034

Patch for "1.9_STABLE" branch: https://reviews.mahara.org/4035

Patch for "1.8_STABLE" branch: https://reviews.mahara.org/4036

Reviewed: https://reviews.mahara.org/4034
Committed: http://gitorious.org/mahara/mahara/commit/163b6f5114be2e56e58cfb100bacbcabb74f862f
Submitter: Robert Lyon (<email address hidden>)
Branch: 1.10_STABLE

commit 163b6f5114be2e56e58cfb100bacbcabb74f862f
Author: Aaron Wells <email address hidden>
Date: Wed Oct 29 01:41:13 2014 +1300

Clear secreturl access cookies on logout

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.

Change-Id: Ia75f58015ab2cb54c9184cdc8b5bf32dfe543733

Reviewed: https://reviews.mahara.org/4035
Committed: http://gitorious.org/mahara/mahara/commit/78e8b1084c5f29ef2aad034c5855d81aad9c2ee5
Submitter: Robert Lyon (<email address hidden>)
Branch: 1.9_STABLE

commit 78e8b1084c5f29ef2aad034c5855d81aad9c2ee5
Author: Aaron Wells <email address hidden>
Date: Wed Oct 29 01:41:13 2014 +1300

Clear secreturl access cookies on logout

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.

Change-Id: Ia75f58015ab2cb54c9184cdc8b5bf32dfe543733

Reviewed: https://reviews.mahara.org/4036
Committed: http://gitorious.org/mahara/mahara/commit/3e4d5e5786381ea590c77ce119a1e08fd9f38e3b
Submitter: Robert Lyon (<email address hidden>)
Branch: 1.8_STABLE

commit 3e4d5e5786381ea590c77ce119a1e08fd9f38e3b
Author: Aaron Wells <email address hidden>
Date: Wed Oct 29 01:41:13 2014 +1300

Clear secreturl access cookies on logout

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.

Change-Id: Ia75f58015ab2cb54c9184cdc8b5bf32dfe543733