Update Databases from Webserver

Mon Sep 6 23:00:42 PDT 2004

Troy,

Maybe the 'commercial question' that should be asked is..
"Why do you need this highly troublesome data within your system?"
NOTE : I am not expecting you to answer that here in public forum,
but maybe you as (potential) sysadmin should be asking it of
your CEO, CIO, legal pipple, etc etc.

You want to be sure that you have very good paper covering
_your_ nether regions! ;-o

my 0.02c worth

mjt

On Tue, 2004-09-07 at 14:55, 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.
> 
> Thanks again,
> 
> Troy
> 
> -----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
> > 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
> 
> ****************************************************************
> This Email has been scanned for Viruses by MailMarshal.
> ****************************************************************
-- 
Murray Taylor
Special Projects Engineer
---------------------------------
Bytecraft Systems & Entertainment
P: +61 3 8710 2555
F: +61 3 8710 2599
D: +61 3 9238 4275
M: +61 417 319 256
E: murraytaylor at bytecraftsystems.com
or visit us on the web
http://www.bytecraftsystems.com
http://www.bytecraftentertainment.com

---------------------------------------------------------------
The information transmitted in this e-mail is for the exclusive
use of the intended addressee and may contain confidential
and/or privileged material. Any review, re-transmission,
dissemination or other use of it, or the taking of any action
in reliance upon this information by persons and/or entities
other than the intended recipient is prohibited. If you
received this in error, please inform the sender and/or
addressee immediately and delete the material. 

E-mails may not be secure, may contain computer viruses and
may be corrupted in transmission. Please carefully check this
e-mail (and any attachment) accordingly. No warranties are
given and no liability is accepted for any loss or damage
caused by such matters.
---------------------------------------------------------------

****************************************************************
This Email has been scanned for Viruses by MailMarshal.
****************************************************************