Re: collecting sensitive data

I'm the wet blanket of despair... It's very good that you're asking. It's kinda bad that you're trying. There are many ways to mess this stuff up and doing it for a real live social-security/bank-account site the first time out of the gate is what I would call a really bad idea. Here is a partial list of concerns and ideas-

All requests with sensitive information (including sign-in) must be under HTTPS configured and set up on a guaranteed host; cookies must never contain customer information.
- Cookies should be secure and httponly.
Taint all input. Escape all output.
Encrypt/salt passwords so they can't be discovered, reversed, or found in a lookup table.
Encrypt the stored financial and personal data. Keep the keys in a separate location; i.e., not the database.
Limit all access to all resources to the smallest possible permissions/connectivity needed to run.
Run everything as an untrusted user so you can't make dangerous mistakes.
Bone up on PCI compliance. Follow it.
Read OWASP. Take it all seriously.
Raise the bid on your contract, or eat the cost, to hire someone who has done all this several times to audit the project when you're close to a production release.

Good luck and stay scared. It makes more secure apps.

Update: changed PCI link to the one grep provided; it's better. Update:update: removed a redundant/awkward sentence.

Update: added OWASP and HttpOnly notes.

Comment on Re: collecting sensitive data Select or Download Code

Replies are listed 'Best First'.
Re^2: collecting sensitive data by ig (Vicar) on Jul 17, 2009 at 06:32 UTC
Are there frameworks/platforms that might make the attempt less "bad"? I agree with the advice to engage someone experienced but I suggest you do it from the start rather than when you are close to production. I have seen several projects / development companies commit suicide by leaving security problems to be discovered near the end of development, shortly after I engaged to bring the applications into our production environment at which time we required rigorous security reviews.	[reply]
Re^2: collecting sensitive data by casimo (Sexton) on Jul 17, 2009 at 00:23 UTC
Thanks for the replies. I have convinced the client to not store any of the sensitive data online...however, they do need to collect this information from the site somehow. Any thoughts on how to simplify things? Perhaps encrypting the sensitive data and emailing it to the client? (maybe breaking the data into two emails?) I know PCI issues will still exist (for the client), but I want to make sure that my link in the chain is secure.	[reply]
Re^3: collecting sensitive data by Your Mother (Archbishop) on Jul 17, 2009 at 02:41 UTC
Email can be made secure but I believe it is probably more difficult than doing it in a limited access DB with a site under SSL/HTTPS. Plus it initiates a situation where an end user can accidentally broadcast sensitive data with a careless forward/CC or an Outlook virus or whatever. I'd say steer completely away from email and encourage your customer(s) to think the same. Consider any bank or serious online store you've ever visited. There is not one that would send any of this stuff that way. I don't mean to be discouraging either. I think it's possible to do this right. Just be very careful and please seek a project review as grep and I suggested before you flip anything live. You could theoretically do something like a hacker prize too. Offer $250-500(?) to anyone who can get a dummy account -- and explain how s/he did it -- out of a test deployment of your code.	[reply]
Re^3: collecting sensitive data by Your Mother (Archbishop) on Jul 17, 2009 at 07:21 UTC
I endorse the amendment ig gives below: an earlier review is a better idea. As for frameworks: none I know but I'll bet there are some options. I've worked within an established codebase taking cards and SSNs (and it was chillingly insecure). I never had to do one from scratch and even after a decade of CGI/web-apps I'd still be nervous, extremely cautious, and thorough.	[reply]