[WEB SECURITY] SSL does not = a secure website

Ryan Barnett rcbarnett at gmail.com
Tue Mar 28 09:02:04 EST 2006


Lyal,
My comments about SSL not equating to a "secure site" was not directed at
the PCI standard but rather those uninformed individuals who think that
implementing SSL and posting a banner on their site has magically solved
their web security problems.

Here is a perfect, personal example of what I mean.  This is a small excerpt
from my book -


*We're Secure Because We Use SSL: Missing the Point*

Back in February 2004, I decided make an online purchase of some herbal
packs that can be heated in the microwave and used to threat sore
muscles.  When
I visited the manufactures website, I was dutifully greeting with a message
"We are a secure website!  We use 128-bit SSL Encryption."  This was
reassuring.  During my checkout process, I decided to verify some general
SSL info about the connection.  I double-clicked on the "lock" in the
lower-right hand corner of my web browser and verified that the domain name
associated with the SSL certificate matched the URL domain that I was
visiting, that it was signed by a reputable Certificate Authority such
as VeriSign
and, finally, that the certificate was still valid.  Everything seemed in
order so I proceeded with the checkout process and entered my credit card
data.  I hit the submit button and was then presented with a message that
made my stomach tighten up.  The message is displayed below, however I have
edited some of the information to obscure the both the company and my credit
card data.

The following email message was sent.

To:comanyname at aol.com

From: RCBarnett at email.com

Subject:ONLINE HERBPACK!!!

name: Ryan Barnett

address: 1234 Someplace Ct.

city: Someplace

state: State

zip: 12345

phone#:

Type of card: American Express

name on card: Ryan Barnett

card number: 123456789012345

expiration date: 11/05

number of basics:

Number of eyepillows:

Number of neckrings: 1

number of belted: 1

number of jumbo packs:

number of foot warmers: 1

number of knee wraps:

number of wrist wraps:

number of keyboard packs:

number of shoulder wrap-s:

number of cool downz:

number of hats-black:         number of hats-gray:

number of hats-navy:         number of hats-red:

number of hats-rtcamo:         number of hats-orange:

do you want it shipped to a friend:

name:

their address:

their city:

their state:

their zip:





cgiemail 1.6

I could not believe it.  They had sent out my credit card data in clear-text
to an AOL email account.  How could this be?  They were obviously
technically savvy enough to understand the need to use SSL encryption when
clients submitted their data to their website.  How could they not provide
the same due diligence on the back-end of the process?

I was hoping that I was somehow mistaken.  I saw a banner message at the end
of the screen that indicated that the application used to process this order
was called "cgiemail 1.6".  I therefore hoped on Google and tried to track
down the details of this application.  I found a hit in Google that linked
to the cgiemail webmaster guide.  I quickly reviewed the contents and found
what I was looking for in the "What security issues are there?" section:



Interception of network data sent from browser to server or vice versa via
network eavesdropping. Eavesdroppers can operate from any point on the
pathway between browser and server.


*Risk: With cgiemail as with any form-to-mail program, eavesdroppers can
also operate on any point on the pathway between the web server and the end
reader of the mail. Since there is no encryption built into cgiemail, it is
not recommended for confidential information such as credit card numbers.*

Shoot, just as I suspected.  I then spent the rest of the day contacting my
credit card company about possible information disclosure and to place a
watch on my account.  I also contacted the company by sending an email to
the same AOL address outlining the security issues that they needed to deal
with.  To summarize this story – Use of SSL does not a "secure site" make.



--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache


On 3/28/06, Lyal Collins <lyal.collins at key2it.com.au> wrote:
>
>  While this doesn't answer the question about incident data it may be
> useful...
>
> Requirement 3 goes on to specify encrypted databases, minimise the volume
> of card data held among other things.
> These 2 requirements mostly affect the theft of the physical storage media
> since it's pretty difficult, imho to prevent a worstation user from
> masquerading as an application call to the database/repository.
> Multi-layer DMZ, with the DB in its own tightly limited access network
> environment, and separation from app servers etc are also necessary.
> And these sorts of requirement exists elsewhere in PCI - Section 1.3.5,
> and section 2.2.1 for example
>
> Requirement 4 addresses issues other than attack-based sniffing - e.g.
> proxy servers that cache GET/POST request data, IDS's that log all packets
> for post-incident analysis etc, and simple routing errors.
>
> If servers and apps were strongly locked down, then attackers would focus
> on the next weakest barrier in the security environment - and network
> sniffing, and traffic redirection via ARP or DNS poisoning would probably be
> higher on the list of threats
>
>  So as I think about this question, it seems that PCI should be considered
> in its entirety, not just single sections, when it comes to addressing
> risks.
>
> Just a few random thoughts
>  Lyal
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20060328/9ed88552/attachment.html>


More information about the websecurity mailing list