On Wed November 26 2008, Toshio Kuratomi wrote:
Till Maas wrote:
> How big the regression is if users have to log in for every
> they click on, depends on how often this happens. I believe that links to
> FAS are not exchanged very often, therefore it will not hurt very much. I
> guess there is also not so often a need to use FAS with tabs. But maybe
> there are people who have to use FAS more often. With Bodhi it is
> contrary, because there it is normal to get mails with links if someone
> added a comment to a package or for testers to exchange links to Bodhi
> updates. Also links to Bodhi updates are used in Bugzilla comments. There
> it would have a much bigger impact on the efficiency of testing new
> package updates imho.
Pretty much agreed on this analysis. My one note is that in my usage,
at least, I already have to login most of the time when clicking on a
link in bugzilla or email due to my session having expired already.
But in the future you would have to do this for every link everytime, even if
you use many of them in a short timeframe.
> Regarding the time needed for auditing applications: There may
still be a
> lot of other vulnerabilites in these applications which cannot be fixed
> automatically. Therefore they still need to be written carefully. But
> maybe a compromise would be to require the token for all requests by
> default and then whitelist the ones, that are not meant to change state,
> e.g. requests like:
I thought of doing this but it still allows things to be insecure if
what a method does gets changed and the whitelisting isn't updated.
What it am apllication writer does not require authentication for some action
that should require authentication? With this reasoning you could also
require that every request has to be authenticated.
Also do the actions behind a certain request / URL really change that often?
OTOH, if a whitelist of methods isn't updated when a form goes
merely showing information to changing data, you lose the CSRF protection.
If you also do not add proper authentication if a method gets updated to show
confidential information, you lose the protection of the confidential
Is it maybe possible to modify the functions behind the API that are used to
change state to require a valid token? Then the author of the webapplication
needs to activly work agains the CSRF protection instead of accidently
> Another way would be to not change the session id if a user
> supply the username/password again only because the token was missing. It
> would probably be enough to ask the user only to click a link that
> contains the matching token in case the token is missing.
Not changing the token can have security ramifications as it allows the
browser to specify what the visit key will be once the user is
this ATM but there could be something that I'm not thinking of or
browser security holes could introduce something in this area.
How is it different to keep the same session id after sending a valid session
id and token to the server than to keep it after sending a valid session and
a username / password combination?
> On the
> downside it has a high impact on usability
This is the one I don't know about. It will change my usage a bit since
I'll need to start clicking on links to the other apps in present app
pages to open new tabs. But when I usually open links from external
sources I'm already used to having to re-login due to the session
expiring. So we need feedback here, do you often click on multiple
things in close proximity and wouldn't be able to change to clicking
within the app? Are you able to
If I send you a bunch of links that point to Bodhi updates and your job is to
add one comment to each update, then you have to provide your username and
password once for each link. Currently you would only login once for the
first link and open the others afterwards. I use as often as possible direct
links from mails or bookmarks, because clicking through the webapp to get to
a certain location takes a lot more time.
> or makes the automatic CSRF
> protection a lot more complicated.
This one's untrue as seen in the revised proposal.
The revised proposal is not yet as usable as the current situation.
> Also securing all requests may cost a lot
> of performance, because more requests need to be made.
This one is probably not correct either. If the token and the tg-visit
match, there's no extra request. If the token and tg-visit do not
match, there's one extra request from FAS to the database. There are no
extra json calls.
If one has to click through the webapp instead of clicking directly on a link,
there are also a lot more requests. Also if one can have multiple valid
session ids, then more need to be stored on the server.
Or best of all, can we add some other check that allows us to
the present usability and still refuse state-changing events if they
haven't been marked as such.
Imho this is not possible, because to refuse state-changing events, you need
to be able to distinguish them from other events. If you have an algorithm
for this, you can use it to mark thes events.