[cap-talk] Webkeys vs. the web
chip at fudco.com
Mon Mar 23 13:27:17 EDT 2009
Tyler Close <tyler.close at gmail.com> wrote:
>On Sun, Mar 22, 2009 at 3:15 PM, Chip Morningstar <chip at fudco.com> wrote:
>> Approach #2 is to have every page in this system include a "powerbox module"
>> and use a session cookie so that when I load the powerbox module, the backend
>> populates it with my stuff but when you load it it populates it with your
>> stuff. The session cookie in this scenario ends up being, in essence, a webkey
>> that is held in a cookie (and handed around like a cookie), which makes me very
>If you augment a shared page with private information, you make the
>user vulnerable to clickjacking. The attacker, knowing the URL of the
>shared page, directs an invisible frame to that page. The attacker
>then tempts the user to click at the screen coordinates where the
>private functionality will be added.
>I suggest you make an account-like object that keeps track of all the
>user's resources. When the user joins the application, they bookmark
>their account object. This is the only bookmark they ever have to
>create. All other pages can be found by navigating from their account
>object. If you are worried about getting at the resource from a new
>browser, you could implement a logon interface, or email the URL, etc.
Clickjacking is, indeed, a threat I am concerned about. However, as I said in
my original statement of the problem, *requiring* the user to make a bookmark
is a non-starter. Requiring a bookmark is one of those "eat your vegetables"
solutions that simply assumes away the problem.
The challenge is how to get from a page with a publicly known URL to a page
with an unguessable URL without forcing the user to engage in strange and
unfamiliar actions. In an ideal world where people already understood the
threats and the appropriate countermeasures, a mandatory bookmark would not
seem strange, but that's the not the world we are dealing with.
More information about the cap-talk