Re: "ClientSideTrojan" bug

[david () KASEY UMKC EDU (David L. Nicol)]

Kragen Sitaker wrote:

> d- server Z sends you an innocent-looking, but evil, form that gets
>    POSTed to server Y.
>
> The solution to case (d) is not clear to me.

I use this architecture for restricted-access CGI:  I issue a session
cookie, and check its return before allowing any action.  Which therefore
makes my sites vulnerable to a case d.  If Mallory builds a page with
an innocent looking form that really posts to my server, his data will
go there with full authorizations when my user clicks on his form, even with
javascript disabled.  I also insert protective javascript that does things
like alert("You have enabled javascript, which is known to be insecure!")

partial possible solutions to this problem are:
1:   issue a one-time password in reponse to any request that will effect
      a change of any sort, and require return of the one-time password

   this sacrifices a little ease-of-use for greater security

2a:   insist that your users switch to a special account or browser application
that they use exclusively for accessing your restricted-access service

2b:  insist that users log out, erasing their cookie and releasing their privelege,
before doing anything else.

2c:  Have authorizations time out quickly

All of these are about the same: you will have to submit Mallory's page
from within the authorized context to be compromised; training users to
minimize this risk is required.

I use a combination of b and c; and try to use a for accessing other
people's services.  The level of risk is proportional to how strictly
the guidelines are followed, returning us firmly back into the land
of social engineering.

If you need rock solid security, issue some proprietary client software
instead of fooling around with port 80.

__________________________________________________________________
                          David Nicol 816.235.1187 nicold () umkc edu