Update Databases from Webserver

FreeBSD Mail Lists freebsd at untoldfaith.com
Mon Sep 6 21:55:42 PDT 2004

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.

Thanks again,


-----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

More information about the freebsd-questions mailing list