[WEB SECURITY] SSL does not = a secure website

Lyal Collins lyal.collins at key2it.com.au
Tue Mar 28 16:18:10 EST 2006


I agree entirely - SSL alone is not the aswer.  Nor is storage encrytion, or
7 character passwords etc...
In the quoted example, the site lacked a sound and secure end to end process
for the entire transaction lifecycle, instead only addressing the payment
capture process.  
 
I've seen several sites where payment pages could be accessed via SSL, or by
changing to "http://" in place of "https:// could be accessed as normal
http.
 
In about 1995, Ausnet, a small Australian ISP, went out of business a few
months after either dial-in access was misused to access a internal server,
or a backup process was redirected to subverted - details are a bit hazy
now.  Someone was prosecuted for the incident - I don't recall the sentence
either.
 
Lyal
 

-----Original Message-----
From: Ryan Barnett [mailto:rcbarnett at gmail.com] 
Sent: Wednesday, 29 March 2006 1:02 AM
To: Lyal Collins
Cc: Web Security; webappsec at securityfocus.com
Subject: Re: [WEB SECURITY] SSL does not = a secure website


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:  <mailto:RCBarnett at email.com> 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/20060329/63f7ed7c/attachment.html>


More information about the websecurity mailing list