[cap-talk] Webkeys vs. the web

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:
> [...] It's fairly straightforward
> to implement a link in which the page obtained by following it normally,
> is different to the page obtained by copying the URL using
> "Copy Shortcut/Link Location" and then opening that URL in another
> window, tab, or browser. For example:

> «a href="urlToCopy"
>    onclick="javascript:window.location.href='urlToFollow'; return false;"»

(Firefox seems to have a strange behaviour that I would consider a bug:
if urlToFollow does not exist, then it will go to urlToCopy instead.
If you then press the Back button, it goes to an error page for
urlToFollow. Wierd. IE doesn't do this, it just shows the error page.)

A minor variation of this allows the followed URL to be different from
the URL shown in the address bar: navigate a frame instead of the toplevel
window.

However, that doesn't allow the URL in the address bar to change when a
link is followed. To do that, it's possible to use a form submitted
to urlToCopy using POST, in which urlToFollow is passed as a hidden
input field (sample code at the end of this email). The server should
check that the urlToCopy is actually the properly attenuated version of
the urlToFollow (otherwise it would be possible for an attacker to use
this to spoof the address bar for that site).


Now we are in a position to do delegation tracking: suppose that
urlToCopy obtains a page that requires authentication from the principal
who uses it (how principals are authenticated is an orthogonal issue).
If the authenticated principal is different from the one that provided
the URL (which is easy for the server to detect), then it can be membraned.

Note that the urlToCopy doesn't need to be specific to any particular
user/principal. I hadn't realized that it was feasible to do delegation
tracking using sharable capabilities represented as data; that's not
entirely obvious (although possibly I just hadn't thought about it
carefully enough).

Of course this does not prevent the user from obtaining the urlToFollow
from the page source. But by the usual argument involving proxying, that
is not a problem: we are not trying to prevent users from obtaining these
URLs deliberately, only from delegating them accidentally.


Sample code (angle brackets replaced as before):

«!doctype html»
«html»
  «head»
    «script language="JavaScript"»
      function linkTo(urlToCopy, urlToFollow) {
        try {
          var linkForm = document.getElementById("linkForm");
          var followInput = document.getElementById("followInput");

          followInput.value = urlToFollow;
          linkForm.action = urlToCopy;
          linkForm.submit();
          return false;
        } catch (e) {
          alert("bug: following URL in href instead of urlToFollow");
          return true;
        }
      }
    «/script»
  «/head»
  «body»
    «!--
    This is difficult to test fully without a server to accept the POST,
    but if you change it to method="get", it's possible to see that the
    'follow' parameter is being set correctly, i.e. something like

      urlToCopy?follow=urlToFollow

    will be shown in the address bar, if urlToCopy exists.
    (Of course, that would defeat the object, but it is a partial
    test that works on FF 3.0.8 and IE 7.0.6001.18000.)
    --»

    «form id="linkForm" method="post"
          action="javascript:alert('bug: linkForm not initialized');"»
      «input type="hidden" name="follow" id="followInput" value=""»
    «/form»

    «noscript»«p»
    TODO: run wording past HCI expert.
    JavaScript is disabled. If you copy a link from the address bar
    or by using "Copy Link Location" or "Copy Shortcut", it may grant
    more authority than you expect.
    «/p»«/noscript»

    «noscript» «a href="urlToFollow"»link«/a» «/noscript»
    «script»
      window.document.write('«a href="urlToCopy" '+
        'onclick="javascript:return linkTo(\'urlToCopy\', '+
        '\'urlToFollow\');">link«/a»');
    «/script»
  «/body»
«/html»

-- 
David-Sarah Hopwood ⚥