Update Databases from Webserver

Richard Lynch ceo at l-i-e.com
Mon Sep 6 16:22:51 PDT 2004

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

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

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

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

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

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

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?

More information about the freebsd-questions mailing list