comments included.
- james
Charles Forsythe wrote:
>
> [Just a little background on me: I'm a member of a large computer
> security consulting group. My personal expertise is helping clients
> secure their e-Commerce applications.]
>
> I thought I would offer up a couple of "data points" regarding
> securing data in web applications, since it seems to be a hot topic.
>
> * As one respondant mention, storage of personal data may be
> subject to local privacy laws. This is not a big deal in the US,
> where privacy is essentially a joke, but folks in the EC should
> pay particular heed to regulations.
> * Never store sensitive data (like credit cards) on your public web
> server. Even encrypted. This server is the most likely to be
> compromised. If your webserver has not been "locked down" by
> experts (like me :-), you are probably vulnerable to attack.
> This goes double for Windows NT and IIS, which are very difficult
> to secure.
yep ... assume your system is pervious until someone who
is in the know can verify the system is locked. we had
just such an individual on the team which was and is a
life saver.
> * Instead, locate a database behind a firewall. This is called a
> "3-tier" design. The first tier is the client, the second your
> web server and the third is your database machine. The firewall
> should prevent connections to the database machine except for
> database-related connections from the web server.
i completely agree with this and will add that this is
precisely the deployment environment used in the real-world
scenario i expanded on a bit back. the db by which the card
info is stored is not readily, dare i say ever, accessable
via the open internet. to do so would be a very bad thing
indeed.
> * Protect the JDBC connection parameters on your webserver. Put
> them in a properties file that can only be read by the web server
> process. Better yet, throw up an AWT dialog on startup and have
> an administrator enter them by hand. Do not hard-code JDBC
> connection parameters directly into your source code!
> * If your database security is set up properly (again, make sure
> this is done by people who know what they're doing!) then you
> don't necessarily have to encrypt anything. In order to get the
> private data, a cracker would have to breach your webserver and,
> from there, crack the database server. Hopefully, by the time
> they get that far, you will have noticed the intrusion.
on this one i'd differ a bit. if we collect the data at
one point in time i want to make sure, regardless as to
the db securities set up to protect the data, that no
one, well intentioned or not, can get access to the raw
card data and inturn, intentional or not, make that data
available to others to use or abuse. bad characters can
exist on both sides of a firewall. i chose to encode the
card data so as to provide one more level of protection
that in the event the data leaked they would still need
the code to make use of the data.
a good dba is worth their weight in gold ... x10.
>
> You are already more secure just for using Servlets. "Buffer overflow
> attacks" are constantly being discovered by hackers; they don't exist
> in Java!
>
> Encryption is most useful when you have data that risks public
> exposure, such as transmission over the Internet. Cryptography a very
> subtle field and subject to annoying export laws (don't get too
> excited by the recent announcements from the Clinton administration)
> and license fees. Leveraging the security that you probably already
> have (firewall, database security) is a much better plan.
>
> I hope this is informative and not too far off topic!
not in my mind. building real and enterprise-class extranet
aware business systems using servlets and associated api's
is completely on track ... possibly a bit top-shelf but i
believe we could use a bit more of that type of discussion
from time to time. raise the bar kind of stuff.
>
> -- Charles
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
