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: Non SSL Bank Login Forms |
|---|---|
| Date: | Fri, 19 May 2006 09:08:09 -0500 |
As users become more aware, the helpdesk get more calls from users asking if a login form is secure, because they don't see the lock icon. As in your case, the form itself is not SSL-secured, just the form action. This question has nearly reached "FAQ" status for some of our sites. Of course, there's a lot of overhead for a busy site if your login form happens to be on your home page. Rather than forcing users to log in up front, using SSL to secure the form itself only when a login becomes required (upon checkout for an e-commerce example) would mitigate this extra load. It also might reduce calls from increasing numbers of security-conscious users. Does securing the form itself with SSL provide any benefits besides customer peace-of-mind? Does it make it less likely that a badly coded login page would be the target of a cross-site scripting attack, etc.?
"Adam Tuliper" <amt@gecko-software.com> 5/19/2006 8:26 am >>>
Wil is correct, beware though, users do look for the little "lock" secure symbol in their browsers, so their perception is the form won't be secure even if posting to a secure url. This same scenario was brought to my attention from an end user wondering where the lock was on their page : ) -----Original Message----- From: Wil Clouser <clouserw@gmail.com> Sent: Fri, 19 May 2006 05:07:50 To: "wilson.amajohn@gmail.com" <wilson.amajohn@gmail.com> Cc: webappsec@securityfocus.com Subject: Re: Non SSL Bank Login Forms Hi John, The form itself is not sent over a secure connection, but the action of the form points to a secure destination. Since the browser initiates the request to the destination (and that connection is using SSL), the POST will be sent securely. Wil On 18 May 2006 14:57:49 -0000, wilson.amajohn@gmail.com wrote:
Hello all, my question is how can a form have a field that is secure
without using SSL. From my web programming experience I cannot understand a Bank's claim that their login form is secure when there is no SSL used. "Signing on to secure sites from an unsecure page is a common industry practice" The POST data has to get to the server if SSL is not used how can they claim it is secure? I hope I have clarified my question enough
Thanks John
-------------------------------------------------------------------------
Sponsored by: Watchfire Watchfire named worldwide market share leader in web application
security
assessment by leading market research firm. Watchfire's AppScan is
the
industry's first and leading web application security testing suite,
and
the only solution to provide comprehensive remediation tasks at
every
level of the application. See for yourself. Download a Free Trial of AppScan 6.0 today!
https://www.watchfire.com/securearea/appscansix.aspx?id=701300000007t9c
--------------------------------------------------------------------------
------------------------------------------------- Sent using http://www.DWmail.net, a free service Check your email [any email, anytime, anywhere] ------------------------------------------------- Disclaimer: DWmail.net is not responsible for the content sent via it's services. Additional header information is included regarding the source of an email. If you believe an email is junk you should look for the 'Originating IP' message header ------------------------------------------------------------------------- Sponsored by: Watchfire Watchfire named worldwide market share leader in web application security assessment by leading market research firm. Watchfire's AppScan is the industry's first and leading web application security testing suite, and the only solution to provide comprehensive remediation tasks at every level of the application. See for yourself. Download a Free Trial of AppScan 6.0 today! https://www.watchfire.com/securearea/appscansix.aspx?id=701300000007t9c -------------------------------------------------------------------------- *** *** *** *** *** *** *** *** *** *** CONFIDENTIALITY NOTICE This e-mail is intended for the sole use of the individual(s) to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. You are hereby notified that any dissemination, duplication, or distribution of this transmission by someone other than the intended addressee or its designated agent is strictly prohibited. If you receive this e-mail in error, please notify me immediately by replying to this e-mail. *** *** *** *** *** *** *** *** *** *** ------------------------------------------------------------------------- Sponsored by: Watchfire Watchfire named worldwide market share leader in web application security assessment by leading market research firm. Watchfire's AppScan is the industry's first and leading web application security testing suite, and the only solution to provide comprehensive remediation tasks at every level of the application. See for yourself. Download a Free Trial of AppScan 6.0 today! https://www.watchfire.com/securearea/appscansix.aspx?id=701300000007t9c --------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Comparison report on web app security scanners, solutions_PHP |
|---|---|
| Next by Date: | Re: MYSQL and PHP, Σπυρίδων Νίνος |
| Previous by Thread: | Re: http/spnego connections, Adam Tuliper |
| Next by Thread: | Re: Non SSL Bank Login Forms, Andrew van der Stock |
| Indexes: | [Date] [Thread] [Top] [All Lists] |