Update Databases from Webserver

Mon Sep 6 23:17:16 PDT 2004

On Mon, Sep 06, 2004 at 10:55:42PM -0600 or thereabouts, FreeBSD Mail Lists wrote:
> Richard,
> Thanks for your reply.  I thought there was something terribly wrong 
> with that logic.  So I thought I would ask in this mail list since 
> people have been great here in the past about everything else I 
> wanted to know.
> Are there any security lists in relation to ecommerce that you 
> would recommend?  So I can stop annoying everyone else here.  
> I just don't want to make anymore mistakes than I have to 
> starting down this road.

Stop talking like that. You are not annoying anyone in here.
You asked the question, you got the replies. Richard wrote nice
email. But it would be much better and less painful for you, if
you could run your credit card transactions using services of
your Bank, or maybe by some kind of well know and trustworthy
billing system. Why should you have dreamless nights? Credit card
info is very *very* sensitive information. So ask yourself, do
you really need to have all the stress or can you leave it to
your bank/billing partner (although for small fee)? And mainly,
are you well known to your customers, even to those which are
new? Because if I am about to give someone my credit card info
I will not trust to e-commerce application provider, but to well
known bank or such.

	Cheers,

	Martin Hudec

> 
> -----Original message-----
> From: "Richard Lynch" ceo at l-i-e.com
> Date: Mon,  6 Sep 2004 17:22:54 -0600
> To: "FreeBSD Mail Lists" freebsd at untoldfaith.com
> Subject: Re: Update Databases from Webserver
> 
> > FreeBSD Mail Lists wrote:
> > > I would like to see how other people are updating backend databases
> > > (postgresql on FreeBSD, internal network) from a webserver (apache,php on
> > > FreeBSD, dmz network) through a firewall.  Pretty much what I am trying to
> > > learn is how to take private information (credit card numbers, etc.) and
> > > write it to a backend database without leaving any huge holes for hacking.
> > >  Should this be done or am I barking up the wrong tree, should there be an
> > > intermediary step?  I have been trying to find information books/web that
> > > gives a real nuts and bolts way of trying to do this stuff and am not
> > > having a lot of luck.  Any pointers books or sites would be appreciated.
> > 
> > The most common answer is "Don't do that"
> > 
> > 99.99999% of e-commerce sites have absolutely no business storing credit
> > card numbers on any hardware they own.
> > 
> > They should simply run the transaction through their Merchant Account
> > (bank)  computer using a secure connection, and the software provided by
> > their Merchant Account (bank).
> > 
> > If you need a recurring charge, you can run your charge through the
> > Merchant Account as a "recurring charge" (whoda thunk it?) and the
> > Merchant Account software will give you back a unique transaction # to
> > refer to if you ever need to cancel THAT particular recurring charge.  You
> > would store only that transaction number, and *NOT* the customer's credit
> > card charge.
> > 
> > In the unlikely event that you really *ARE* in the 0.000001% of servers
> > that needs to store credit card info...  Well, it's kinda scare that
> > you're asking here, rather than a security mailing list, but here is *ONE*
> > solution that may be worth considering.
> > 
> > I am posting to the list so that others can tell us just how inadequate
> > this is.
> > 
> > You should also be aware that by no means am I an "expert" -- I am simply
> > describing what has been described to me as the "right way" (tm) to do
> > this.
> > 
> > My information may be out of date.  (It's been awhile.)
> > 
> > I chose to let the Merchant Account (bank) worry about keeping credit card
> > numbers safe, rather than do all of the following.
> > 
> > You probably should too.
> > 
> > Depending on the current interpretation of existing laws, you, the web
> > developer, may or may not be held responsible for *ANY* damages that
> > result from your work -- no matter how faultless you may be in reality. 
> > We're talking legalities here, not reality.
> > 
> > Did I mention that you really shouldn't be doing this at all?  Good.
> > 
> > 
> > 
> > First, your servers *MUST* be in a physically secure location, with access
> > limited to *ONLY* people you really really really trust.
> > 
> > No software in the world will do you any damn good if a not-so-honest
> > person can waltz in and play around with the hardware!
> > 
> > If you *CANNOT* guarantee that the hardware in question can *ONLY* be
> > accessed by trusted individuals, than you should stop reading right here
> > and now.
> > 
> > This rules out shared servers, co-location (IMHO), and almost all
> > corporate servers, which need too many people of limited trust value to be
> > able to access them to keep them up.
> > 
> > Next, you need a SECOND server which will be used to hold credit card
> > info, and that second computer will *NOT* be connected to the Internet
> > (directly)
> > 
> > You put an extra NIC in your web-server, and run a cross-over cable to the
> > SECOND server, the extra one, which will hold the credit card numbers.
> > 
> > You limit ethernet access to that second computer which will hold credit
> > cards so that *ONLY* the one computer connected to it via the cross-over
> > cable will be allowed to connect.
> > 
> > The "extra" NIC in the web-server and the SECOND server are both on a
> > separate sub-net from everything else in your system.  IE, the only
> > interface cards in your entire organization that utilize the IP address
> > space in question are those two (2) NICs.
> > 
> > You then make 100% sure that you simply cannot get to that SECOND box from
> > anywhere else in the organization.
> > 
> > What is quite well-documented is that you use SSL (and ONLY SSL) to allow
> > the customer to get their credit card info to your web-server.
> > 
> > You then write some routines to get the credit card numbers from your
> > web-server through your second NIC to the second server.
> > 
> > These routines get the fine-tooth code-review treatment, by multiple people.
> > 
> > They should be mind-numbingly simple, clearly documented, and do the
> > absolute minimum possible to conduct your business.
> > 
> > You test these routines every way you can think of to see how they can be
> > broken.
> > 
> > You hire an outside security audit team to test your server and routines
> > to see how they can be broken.
> > 
> > You use something like tripwire to raise nine kinds of hell if anything
> > changes on the portion of the web-server that talks to the SECOND machine,
> > and, of course, if anything (other than data) changes on the SECOND
> > machine.
> > 
> > Under *NO* circumstances should the routines *EVER* store the credit card
> > numbers in any file, database, shared memory, or anything less transitory
> > than the variables of a single script, operating under SSL, on the
> > web-server.
> > 
> > So, in effect, you get the cc# onto the SECOND box which is not truly
> > accessible from the Internet, and you shove it IMMEDIATELY into that
> > SECOND box, and you make damn sure it NEVER "leaks" out of that SECOND box
> > and the air-tight routines on the web-server that are allowed to access
> > that SECOND box.
> > 
> > All of this also presumes that your web-server is *ALSO* as secure as you
> > can make it, that data, and *ONLY* data, is changed on the web-server, not
> > programs.
> > 
> > You don't have an army of developers writing scripts (PHP, Perl, CGI,
> > whatever) on this web-server -- If you need all that, get THREE boxes.
> > 
> > 1. Regular web-server.
> > 2. E-commerce web-server, with link to "OTHER" box
> > 3. OTHER box with CC#s in it.
> > 
> > 
> > Box #1 is where your HTML/PHP/Perl/CGI programmers have "access"
> > 
> > Box #2 is rigged to scream if anybody so much as changes a <B> tag on it,
> > but has the "Checkout" page on it, where CC#s are taken in, and is
> > accessible to the Internet.
> > 
> > Box #3 has the CC#s on it, and is not accessible to the Internet, only to
> > Box #2.
> > 
> > 
> > I'll say it again:  It's incredibly UNLIKELY that you really should be
> > doing this at all.  It's also very very very likely that this answer is A)
> > wrong,B) incomplete, C) out-dated, and D) all of the above.
> > 
> > -- 
> > Like Music?
> > http://l-i-e.com/artists.htm
> > 

-- 
Martin Hudec            | corwin at aeternal.net
                        | corwin at web.markiza.sk
http://www.aeternal.net | cell +421 907 303 393

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20040907/48fb4e7e/attachment.bin