GuestXHR
 
Search this site

maciej-challenge








The following flow charts sketch out a simple implementation of Maciej's challenge problem using the credential and Origin free GuestXHR proposal. The primary goal of this design was to preserve both the user interface and network communication pattern used in Maciej's CORS-with-Origin implementation. As you'll see, the two solutions are almost identical from this perspective. Maciej's implementation is described in slides 18 and 19 of the slide deck attached to his email to the web-apps list.
In the permission grant phase (shown above), the user asks the calendar site (Server A) to create a new "add event" permission for the upcoming events site (Server B). As a result, Server A creates a corresponding secret "secret123" and transmits it to Server B, via the browser. In detail:
  1. The user navigates to Server A's access grant page. Server A may recognize the user via an unguessable URL parameter (such as the shown "s=..."). Alternatively, the user may be recognized via a cookie, assuming defenses against clickjacking and CSRF are in place.
  2. Server A returns a web page with the access grant user interface.
  3. The user selects a known event source, or enters the URL for a new event source. This URL is the value of the identifier B.
  4. Server A generates a new unguessable token (secret123), and stores the association (user, B, secret123). The new token is transmitted to Server B via a browser redirect. The redirect avoids the need for server-to-server communication and lets the browser fill in the identifier for the user on Server B. In the redirect, Server A is identified by a URL for the event submission resource. For example, "https://calendar.example.com/add".
  5. The web browser automatically follows the redirect.
  6. Server B returns a web page with the access grant confirmation user interface. For example, the page may say: "I just received a request to add a calendar to your profile. Did you initiate this request? <yes> <no>". This user interface also informs the user of any prior access grant from Server A. The page may also allow the user to select a petname for the access grant, such as "my work calendar" or "my personal calendar". This petname can be used by the event site's user interface when asking the user which calendar to submit an event to. The access grant confirmation page must be protected against clickjacking, since the user is identified by a cookie, rather than a URL argument.
  7. The user confirms the calendar configuration.
  8. Server B confirms the confirmation.


The upcoming event site can now exercise it's "add event" permission by explicitly passing the corresponding secret via a GuestXHR POST request. Since the request is sent via GuestXHR, neither the user's credentials, nor those of the upcoming event site, are used in the request, so there is no possibility of a CSRF-like attack. As discussed at Tuesday's TPAC meeting, Maciej's solution is vulnerable to a CSRF-like attack by Server A on Server B if the "add event" URL provided by Server A actually refers to a resource on Server B.

Attachments (2)

  • gxhr-add-event.svg - on Nov 4, 2009 8:53 PM by Mark Miller (version 1)
    18k View Download
  • gxhr-grant.svg - on Nov 4, 2009 8:53 PM by Mark Miller (version 1)
    27k View Download