> -----Original Message----- > From: Ray Champagne [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 13, 2005 2:24 PM > To: CF-Talk > Subject: security suggestions? > > We have a potential customer that is a bank (a small local one). They > want to be able to have people fill out a loan application online, but > are worried about security, etc. Other than using a secure certificate > and SQL Server, are there any other considerations I should give to > security? Sorry this is such a broad question, but I really don't know > any other things I should be worrying about. > > Here's a list that I've thought out, but this is all really elemntary > stuff:
Just some comments (you may already know this but I find a lot of people saying these things are "security" related without knowing why): > Use cfqueryparam always Understand that this is only a "security" measure because of the type validation provided and the inability to create SQL injection attacks. Regardless of CFQUERYPARAM you should take care to construct your data access in a such as way as to be "removed" from your interface. Information entered in the interface should never be used to populate a data call without first going through a validation filter. While CFQUERYPARAM makes for a decent validation filter I greatly prefer the addition of a true, componentized filter as well. > Use POST vs GET The only real problem here is that a GET may be bookmarked or kept in browser history. Under SSL BOTH POSTs and GETs are passed via the secure transit. > Use SQL Server This doesn't really add any security... all databases are only as secure as their configuration. In general you should never allow a database to exist in a "downloadable" area (as when people place Access files within the web server root). You should also severely limit access to the data... a more "professional" DBMS like SQL Server makes this easier but still, you must actually do it. I recommend, if the system design allows, making the web database user who writes the data not be allowed to read it. You might allow that user access to certain procedures which could read some of the information... but having the user be a "one way" gate can increase security somewhat (if the username and password for that user is compromised no personal data can be obtained using it). > Use SSL Definitely. SSL has some overhead (it's not cheap to encrypt/decrypt) but for any small sites it's negligible. > Only allow retireval of data via the web site, not send any info in emails That depends. Secure email (using something PGP) may be more secure that allowing access from the site (what's more likely to be hacked?) You may also have two sites: one hosted and accessible only on an internal network. The public site could update the data but not read it, the internal site could do both. > ??? There some other technical ideas to consider: 1) If your application contains sensitive information you might want to host it within a pop-up window, closing the window when you're done. This eliminates the possibility that somebody could come along and "back button" to the personal information. It also adds the possibility that people with pop-up blockers will not see the form. And it pretty much requires JavaScript to do it right. Also note that features like this are to protect the user from themselves, not the company. It's not the companies' fault if the user is sloppy with their information... but it can be hard to tell who's been sloppy when a leak occurs. 2) You might want to encrypt the information on the database... but this is a little overkill-ish. However if you can't secure the database as much as you'd like it can be a good measure. In this case an application would be needed to get the information (like, say, an internal web application). 3) Do you actually need to store in the information at all? Could, for example, the web site collection the data, convert it to a secure (encrypted) email and send it directly the loan officer? You might store some, non-specific aggregate information on the database but the custom data would be sent directly to the only person that needed it and would not be available if the web site were compromised. More broadly there are some business issues to consider: 1) Ensure that the customer (via a Privacy Policy) knows how their information will be used and what recourse they have. Legally (at least in some states) the custom must has full disclosure about the information accepted, what's done with it and so forth. A system must also be put into place (and publicized in your privacy policy) how a customer may have their information removed from your system. For most of this check in the "Platform for Privacy Policy" (PPP - it's a W3C spec). IBM offers a free tool to generate compliant privacy statements and compact statements (used for cookies). 2) Determine who needs access to the data and put procedures in place to protect it. In other words if you (the web developer) don't specifically need access to the end customer data then you shouldn't have it (you may be allowed to see test or dev data of course). One of the easiest ways to set yourself for a lawsuit is having or giving more access than you need to get your job done. This is especially true with any HIPA-related information. For example if the loan application asks about health issues then the information may fall under HIPA. (We see this at the office all the time with life insurance and disability policies.) 3) In the same vein as the above discuss with your client and strongly encourage them to limit the information needed online to the barest minimum. Don't use the system for "marketing fishing" and ask for more information than you need. For one thing any use of the information other than that for which it was provided may be illegal. For another the more information you have the more information is at risk. Again this is also the reason that you must be explicit about who has access. Marketing will want the information (let's say) but may not use it properly - that leaves the company open for legal action. However if marketing has access then the customer (via the privacy policy) must be made aware that they'll have it and that they might use it. So you start by limiting it as much as possible and then opening it up (adding access, updating the customer disclosure, etc) slowly. Sorry for the lecture... I guess 10 years in the insurance industry has sucked all the fun right out of me. ;^) Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:220950 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
