Date: Mon, 6 Sep 2004 16:22:54 -0700 (PDT) From: "Richard Lynch" <ceo@l-i-e.com> To: "FreeBSD Mail Lists" <freebsd@untoldfaith.com> Cc: freebsd-questions@freebsd.org Subject: Re: Update Databases from Webserver Message-ID: <4391.67.167.52.21.1094512974.squirrel@www.l-i-e.com> In-Reply-To: <32b19d296fd997fbb8e7d362d85321ef@untoldfaith.com> References: <32b19d296fd997fbb8e7d362d85321ef@untoldfaith.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4391.67.167.52.21.1094512974.squirrel>