Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: limits of end-user "testing" |
|---|---|
| Date: | Sun, 27 Nov 2005 12:03:58 -0500 |
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
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: limits of end-user "testing", Daniel |
|---|---|
| Next by Date: | Simple to exploit SQL Injection ?, Jason binger |
| Previous by Thread: | Re: limits of end-user "testing", Kurt Seifried |
| Next by Thread: | RE: limits of end-user "testing", Luke Fraser |
| Indexes: | [Date] [Thread] [Top] [All Lists] |