Re: limits of end-user "testing"

[Chuck <chuck.lists () gmail com>]

On 11/16/05, Jeff Robertson <jeff.robertson () digitalinsight com> wrote:
...
> Is there *anything* that an end user can do in the way of checking for the
> Top 10 type of problems, that would be considered "fair use" (I know..
> copyright law term, not really applicable here) or "self-defense" rather
> than malicious?
...

In answer to the original question here, I think that there is one
thing that you can do to get some idea of the site security and that
is to sniff a session.  Run your session through WebScarab (or
equivalent) and look for the things below.  If the site uses SSL, you
will get a certificate error in your browser, but if you ignore that,
you will see all the plaintext in the proxy.  This list includes some
issues that may not apply to a bank, but may apply to other types of
sites.

- Does the post-login page do a 302 redirect to prevent someone from
being able to go back in the browser history to re-post the login?
- Is the password sent directly to the server or is it hashed in
Javascript before being sent? (the latter is better, especially if the
site is not SSL, and used on Yahoo! for example)
- Are pages with sensitive information marked to prevent caching (on
proxies or on the local browser)?
- Do forms get submitted with a GET or a POST?
- What is stored in Cookies?  Is it a random session identifier
(good), or other cleartext information like your account number,
userid, name, etc (bad).
- What is stored in hidden form fields?
- Do the forms appear to have some protection against CSRF (such as
random hidden fields)?
- When you logout, are your cookies cleared?

I'm sure that there are some things that I am forgetting here.  I
think it would be useful to put together a complete list of things to
look for in these cases where you can only sniff a session so please
respond if you can think of other things.  Thanks.

Chuck