Re: Credit card confirmation?
- From: Erwin Moller <since_humans_read_this_I_am_spammed_too_much@xxxxxxxxxxxxxxxx>
- Date: Fri, 15 Dec 2006 11:41:12 +0100
Al wrote:
Your comment " I would say that every sane person should use Postgres"
aroused my curiosity. Would you take a minute and give us a short
explanation as to why you think this. mySQL would appear the be the
most widely used for php.
Thanks, Al.......
Hi Al,
I was just teasing a bit.
MySQL was a very simple database before it incorporated the INNODB engine.
It didn't support foreign keys, no transactions, etc.
But these day are over since it started offering innodb as enginetype.
I had a lot of trouble with mySQL, like:
- It didn't complain when a table was created with foreign keys. BUT it just
didn't do anything with them. You could just violate the FK constraint and
mysql didn't complain. (This is over since INNODB).
That annoyed me because it pretends to understand FK's, but actually it
didn't.
- When I start a transaction, it autocommits, even when I explicitely say it
shouldn't, whenever I change the databasestructure (like changing some
column in a table, or adding a table).
Since Postgres was out there for many year, and was totally robust and
filled with real database utilities, I never understood the popularity of
mySQL. Postgres beated mySQL on all features, except speed, which isn't a
surprise since mySQL didn't bother to check constaints and such anyway. ;-)
Reason for mySQL's popularity mainly lie in the fact it ran under Windows
too, so many people unfamiliar with *nix started using it.
But I admit mySQL came a long way the last few years.
So don't take me too seriously, I was merely teasing. Just keep using mySQL
if you like it. :-)
Regards,
Erwin Moller
Erwin Moller wrote:
UKuser wrote:
Hi Folks,
I'm programming a small online shop where users can buy one of 2
products, and then feed their info into an online merchant.
My users will:
page 1 Signup/General details
page 2 Credit card information
page 3 Confirmation of order (pre merchant link)
page 4 Confirmation of order (post merchant link)
My thought is - how acceptable is it to pass the info between step 2&3
by using hidden fields? I'm thinking if the site was stored on a proxy
server this could make it insecure (unless encrypted by SSL?)? I read
that MySQL is not good for storing CC info, and I'm using a DB to store
my sessions. I could store the info in sessions, but people seem to
advise against it. It will obviously be SSL and the session ID etc will
be stored in a cookie with no URL acceptance.
So what is the best way of doing this? I've tried to secure my
sessions/cookies to the max, but not sure which way is the best way of
passing the info between pages (as I've tried to avoid having to do
this).
Thanks
A
Well, that is a broad question.
A few things to keep in mind:
- If you do not use SSL (https), anybody in the middle can eavesdrop on
the plaintext information the client sends to your server.
So if security is a concern to you, start with encrypting the information
transmitted between client and server (https).
- MySQL insecure?
Who claims this and why? Why is MySQL worse to store CC info than say, MS
SQLSERVER?
I would say that every sane person should use Postgres, but leave that
for now. ;-)
In general: Whenever you are storing sensitive information in a database,
be sure you know WHO can access it. Also ask yourself if your ISP is any
good. Also care about backup policy.
- Session not secure?
Two things to keep in mind:
1) How did your ISP set up sessionstorage on the machine?
In many situations sessions are stored as flat (serialized) file in a
common directory, accesible to any user on the same system.
So this should be a concern to you share the same machine with other
sites (shared hosting environment).
A break of security could work as follows:
PHP stores the session when your script ends.
this will result in a file stored (for example) like
/tmp/phpsess/phpsessid12gh4gh32ghf42
where the mess after phpsessid is the actual sessionid.
PHP uses that to open this file next time it receives a request from some
client with that phpsessid.
What is important is the fact that the owner of this file is the user
(EUID) that runs as PHP. Under apache/nix this is often 'apache' or
'www-data' or something.
The problem lies in the fact that the php scripts of another user on the
system also runs as that user ('apache' or 'www-data'), and can thus read
the files.
2) If you are not running https, any middleman can see the cookie and the
value (or the URL if the PHPSESSID is stored in the URL).
From there it is easy to steal that session, simply by using the same id.
You can secure this a little more by storing the remote IP-address in the
session and compare it to the one used when the session started. If they
don't match, exit.
(This approach will also frustrate some people at AOL who change
IP-addresses all the time.)
Best way to go:
1) Talk with your ISP if you are on a shared hosting environment HOW they
setted things up. Be sure you speak with a technical person, not the
sales department. ;-)
In case you don't trust their sessionstorage, consider using
databasebased sessionstorage. (you need session.safe_handler = 'user'
instead of file, and then write your own routines. Will take a little
time but is not very difficult.)
2) Use https.
Hope this helps a bit to sharpen your thoughts on the subject.
Good luck,
Erwin Moller
.
- References:
- Credit card confirmation?
- From: UKuser
- Re: Credit card confirmation?
- From: Erwin Moller
- Re: Credit card confirmation?
- From: Al
- Credit card confirmation?
- Prev by Date: Re: reading http request raw data as stream
- Next by Date: Re: Credit card confirmation?
- Previous by thread: Re: Credit card confirmation?
- Next by thread: learning classes not sure how to do this correctly
- Index(es):
Relevant Pages
|
