Page 1 of 2

Securing a web site

Posted: Fri Nov 01, 2002 12:16 pm
by Crashin
Howdy all! I'm getting ready to bid on building an application for a company that needs high security built into the design. I've built plenty of sites using the standard PHP session controls, but I've never built anything that requires high security. So, being rather in the dark on this topic, I thought I'd turn to the most knowledgeable group of coders I know for advice.

Bottom line: what do you suggest for building a secure site using PHP/MySQL? Is there something I should look into using in addition to PHP/MySQL? It needs to be secure to the level of protecting banking information.

You know I'm grateful for your input! 8)

https

Posted: Fri Nov 01, 2002 2:33 pm
by phpScott
Secure servers would be the best choice. That way all the encryption is done on the server side and only those who have the right key can decrytp the information.
Do a search for https or secure servers and you will get just tons of information.

phpScott

Posted: Fri Nov 01, 2002 2:44 pm
by Crashin
Thanks for the tip, Scott! And, um, out of curiousity, what do you mean by your signature quote (back of your head)? :oops: J/K. :o

back of my head

Posted: Fri Nov 01, 2002 3:42 pm
by phpScott
since this is a public forum I will keep it clean 8) :D
What I was really meaning is that is all she gets to see when I am working from home is the back of my head as I sit for far to long in front of the computer.

Posted: Fri Nov 01, 2002 3:50 pm
by Crashin
Oh, uh, yeah...that's what I thought you meant! :D

My wife can't even see me...I'm crammed down in our basement when I work. :x

A basemnet?

Posted: Fri Nov 01, 2002 7:21 pm
by phpScott
you mean that you get your own space 8O :? 8)
WOW, I have to share my computer, in my small one bedroom flat.
With the t.v. going just over my right shoulder.
Are you also trying to say that your wife never gets to see the back of your head?

phpScott

Posted: Fri Nov 01, 2002 10:59 pm
by rlogin
Are you talking about an application which needs to access banking information already available?
Or even the DB needs to be designed?

'cuz, Secure application involves
1) DB level security
2) Scripting level security

As phpscott mentioned all transactions have to be in https.
Also, digital signatures may be used for authentication if the user base is predefined.
Does the DB need to store any sensitive information?
Rgds,

Posted: Sat Nov 02, 2002 9:42 am
by BDKR
It needs to be secure to the level of protecting banking information.
If I can take this somewhere close to literally, try another database. If the data is as important as the above comments seems to indicate, then you want a db with better referential integrity and transaction support.

Now before I go any further, perhaps I should slap myself in the face. If you do you MySQL, make sure you check the InnoDB table types. Why? Better referential integrity and transaction support.

Now if this something other than a web application, then the transactions don't have to know a thing about HTTPS.

Keep in mind, security isn't JUST the application, it's the entire system. Firewalls, intrusion detection, the whole nine yards. Make your app as secure as possible, but make sure they know that there are other dangers still.

Cheers,
BDKR

Posted: Sat Nov 02, 2002 10:02 am
by Crashin
Thank you for the tips! It's not going to be for a bank, but it will include sensitive bank information in a graphical format (i.e. scanned checks). I will be looking at security from all standpoints (i.e. server, DB, application, firewalls, etc.), but at this point I'm trying to isolate one thing at a time.

BDKR, do you have any other suggestions for the DB, from a security standpoint? I've not read up on that side of DB's...just speed tests and the like. I'd hate to lose MySQL in this scenario...it's almost like an old friend. But, security is most important in this situation.

rlogin, yes, the DB will need to be designed. The banking information exists in paper format only, and is not tied to account information per se. (See above.) I've got a good design in mind for this...I will need to look into https, though. Thanks for the comments!

Scott...well, she see's the back of my head on special occassions. :P But, inbetween I am lucky enough to have a basement to develop in, although I used to have an office in our old house, which I miss. That was really nice...

Thanks again, all!

Posted: Sat Nov 02, 2002 11:10 am
by BDKR
BDKR, do you have any other suggestions for the DB, from a security standpoint? I've not read up on that side of DB's...just speed tests and the like. I'd hate to lose MySQL in this scenario...it's almost like an old friend. But, security is most important in this situation
How about this. If you are going to be using dedicated boxen for the db's, use a port other than the standard. You can set the port to use in the my.conf file. Keep this port (and the standard) closed to the outside world at the firewall or server.

As a matter of fact, shutdown all services that are not going to be used. Any open port is just another oppurtunity for a miscreant.

If the php app and database are going to be running on the same box, disable outside connections to the db and have the app connect using the mysql socket. It's normally at /tmp/mysql.sock. This would be faster anyways.

One more thing that could help, but this is a question of money. Have the servers and dbs speak to one another on their own dedicated network. Mulitple advantages here. Less network congestion and it takes a hacker longer to figure out what's going on if he does break through your firewall.


Cheers,
BDKR

Posted: Sat Nov 02, 2002 11:18 am
by Crashin
Cool...thanks for the suggestions! Of course, I would like for the app and DB to interact on an internal network. I'll need to get a feel for how much money they want to put into this system. I have a feeling the best I'll get out of them is both the app and the db's on the same box, but as long as I let them know about the different levels of security my hands are clean.

Posted: Sat Nov 02, 2002 11:55 am
by BDKR
but as long as I let them know about the different levels of security my hands are clean.
I hear you brother!

Posted: Sat Nov 02, 2002 12:08 pm
by BDKR
Hey Crashin,

I just thought of another thing. As this app grows, what if they start using more than one machine to process information? What if they go to a load balanced setup? What does this do to your sessions information?

In PHP, the sessions are stored on disk in a tmp directory, but I would suggest you go to storing the sessions in the db. Here's why. If the load increases to a point where they consider using more that one server, then each time a client comes back, like say from page view to page view, they could end up at a different server, and the session information would not be found. The first fix is to make sure that each time that client returns, they are returned to the same server. But what if this fails? Well, if both servers, or how ever many servers you could end up with, speak to the same db, the session information remains constant across multiple page views and servers.

Cheers,
BDKR

Posted: Wed Nov 06, 2002 5:51 pm
by Crashin
Hey...thanks for all the ideas, BDKR. Just a follow-up. They're on the fence as to whether they'll even proceed with the project, but if they do they decided they will strip out the account numbers to minimize their liability. (As the account numbers aren't necessary for what they're doing.) So, I might be able to get by with just one server...but, that doesn't answer the high-load question you posed in the last post. I'll have to give that some thought. They would *likely* not move that much through their system, but better to tackle it up front in case they change their minds.

Ugh! :roll:

Posted: Thu Nov 07, 2002 6:36 am
by BDKR
Hardware is cheap these days. A good single processor server could be had or built to your spec for well under a $1000. If they are in the business of making money, ask them how much money they tend to lose when that one and only server crashes. Not trying to be hard, but it's something that must be considered. Failuers do and WILL occur. Last night, while looking at some data (sound like a mad geek eh?) everyone starts squawking that there is no more internet access. A port on one of the hubs failed. If something as little, simple, and seemingly bulletproof as that can give up the ghost, everything else can too.

They will appreciate the truth.

Cheers,
BDKR