Date: Mon, 06 Sep 2004 22:55:42 -0600 From: "FreeBSD Mail Lists" <freebsd@untoldfaith.com> To: Questions <freebsd-questions@freebsd.org> Cc: ceo@l-i-e.com Subject: Re: Update Databases from Webserver Message-ID: <6ef4c2b8eb37d954d7b887c5e1f45810@untoldfaith.com>
next in thread | raw e-mail | index | archive | help
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. Thanks again, Troy -----Original message----- From: "Richard Lynch" ceo@l-i-e.com Date: Mon, 6 Sep 2004 17:22:54 -0600 To: "FreeBSD Mail Lists" freebsd@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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6ef4c2b8eb37d954d7b887c5e1f45810>