When users browse to a Web site that begins with HTTPS, they
expect that connection to be secure via Secure Sockets Layer (SSL), a protocol
for transmitting secure documents via the Internet. The majority of Web sites
use this protocol to obtain sensitive data (e.g., shopping cart data and credit
card numbers from customers).

An HTTPS Web site may make most users feel relatively
secure, but this alone doesn’t guarantee secure transactions. To properly
protect your organization’s users—as well as corporate data that unsecure
transactions could leave open to exposure—make sure your users understand how
to properly evaluate a Web site’s security.

Making the SSL connection

When it comes to online forms, secure servers (from an HTTPS
site) do not actually serve most of them. This means that the form data may not
be going where users think.

If you view the source HTML code of a Web page that you’re
entering credit card data into, you should see something like the following:

<form method="POST" action="/order.cgi">

or

<form method="POST" action="https://www.shop.com/cgi-bin/order.cgi">

If the form POSTs to an IP address, users should browse to
another site. A Web site should send sensitive information only to a registered
site.

Here are the four most common forms that users will
encounter:

  • Form
    page http://www.shop.com/form.html with a form tag of <form
    action=”/cgi-bin/login.cgi” method=”get”>: This is
    not secure at all, and it doesn’t encrypt any of the information.
  • Form
    page https://www.shop.com/form.html with a form tag of <form
    action=”http://www.shop.com/cgi-bin/login.cgi
    method=”get”>: This information isn’t secure either. When the
    form sends the data, it initiates a new—not secure—HTTP session.
  • Form
    page http://www.shop.com/form.html with a form tag of <form
    action=https://www.shop.com/cgi-bin/login.cgi method=”get”>: This
    securely transmits information to the form Web site.
  • Form
    page https://domain.com/form.html with a form tag of <form
    action=/cgi-bin/login.cgi method=”get”>: This also securely
    transmits information to the form Web site.

Making sure data remains secure

By securely transmitting data and using SSL to collect
sensitive information, a Web site implies that it will keep that information
secure. But what really happens behind the Web site?

For example, most small companies don’t host their own Web sites;
instead, they use a Web hosting service. But Web hosting services typically
turn that Web form data into an e-mail, a process that more than likely doesn’t
encrypt the data. This means that anyone with access to the e-mail can easily
access customers’ sensitive information.

Advise users to keep this in mind when surfing the Web, and
make sure your organization’s Web site makes an effort to reassure its customers
about data security.

Final thoughts

A properly implemented SSL Web site raises customers’
expectation that you’ll handle their information securely. Establishing an SSL Web
site and then transmitting sensitive information collected at that site using a
nonsecure method is a poor business practice, and it doesn’t meet the standard
of due diligence.

Employ SSL as the first step to securely collect, transmit, and store sensitive information. Ensure
that your company’s users know how to evaluate a Web site, and make sure to
publicize your own efforts to customers so they know they’re dealing with a
secure Web site at all points.

Miss a column?

Check out the Security Solutions Archive,
and catch up on the most recent editions of Mike Mullins’ column.

Worried about security issues? Who isn’t? Automatically
sign up for our free Security Solutions newsletter, delivered each Friday,
and get hands-on advice for locking down your systems.

Mike Mullins has served as an assistant
network administrator and a network security administrator for the U.S. Secret
Service and the Defense Information Systems Agency. He is currently the
director of operations for the Southern Theater Network Operations and Security
Center.