shapj@us.ibm.com wrote:
>
> David Nicol's story about using cookies for the help desk seems like a
> reasonable strategy, and (perhaps to his surprise) I don't feel that
> kernel-protected capabilities are necessarily required for that
> application. It depends mostly on what the help desk application lets the
> user do.
>
> A couple of thoughts on that application, though:
>
> You might want to have a look at Tyler Close's droplets architecture
> (contact tyler@waterken.com). It provides a way to build capabilities into
> URLs, which is nice in your application. You can imagine generating a URL
> for a form (one that becomes unusable after a limited amount of time) and
Building capabilities into URLS (aka bookmarkable sessions) is a bad
idea, as it allows for data theft through a variety of javascript hacks
that access the "about:cache" page. POST-stype form submission is
therefore
preferred for all forms offering anything hidden, and revealing the
capability in the URL -- something like
http://www.tipjar.com/cgi/give?rec=shapj@us.ibm.com&amo=10&password=possum
(where the capability is the password) is vulnerable to cache dumping attacks.
Someone had a cache dumping example web page up a while ago -- point your web browser at the page, enter your e-mail, and it e-mails you any URLS in your cache containing what look like credit card numbers that it finds -- scary stuff, part of why I have a throwaway UID I switch to before running Navigator with javscript turned on. Setting up a throwaway UID on a linux machine is trivial.
Therefore, the weak security at tipjar time cards
(http://www.tipjar.com/timecards) is bolstered by always including
client
IP address into the log -- if someone steals your bookmarkable URL,
which
you can invalidate at any time by switching your password from your home
page, and just holding on to the verification code -- if they should try
to
alter your logs in any way you will have their e-mail address.
Maybe I should add change of client IP-address to the events which get
logged
into the time card.
I'd like to formally declare what exactly the motivations are for the
various
security mechanisms in tipjar time cards, but I'm not sure how to go
about
documenting them. My mechanism is to think about possible attacks as if
it
was a life-or-death Go problem, and proceed when I have achieved a
solution
that makes sense to me, a method with obvious problems for a formal
correctness
and provability standpoint.
Comments?
David Nicol 816.235.1187 nicold@umkc.edu
"Light a match, don't curse the fart" -- Stephen Tobias