三、安全由谁来负责
很多时候安全问题不仅仅只是程序员的责任，而是在系统设计的时候就开始考虑的问题，而且系统的安全也是由很多的人来负责的，如：
程序设计者要保证程序结构是安全的
网络管理员要保证网络和服务器是安全的
程序员要保证代码不会引入脆弱性
数据库管理员确保数据库服务器没有脆弱性
用户也不要受欺骗
当然，还有其他的很多任务要做好，才能实现安全。
我们都是开发人员，下面就来看看我们开发人员不能解决的问题：
网络
ASP.NET程序运行要依附于网络，如果网络连接中断，我们没有办法。
Web服务器和数据库服务器
如果服务器本身不安全，那么我们的代码写的再好也徒劳。
客户端
我们终究能控制客户端，而且很多的恶意用户甚至可以绕过我们的客户端的javascript验证，要记住用户都是恶意的.
我们可以解决的问题：
把安全放在第一位
构建并维护具有一定安全等级的系统，是重要而又困难的事情。以前，安全问题往往被认为是外部的问题，在程序种不考虑。
客户和管理者永远也不会同意为了某个功能而花费金钱，除非他么能够看到明显的好处。作为程序员，我们有责任教育公司其他的人，使得他们明白安全的重要性，不能像以前那么只是把安全的问题轻描淡写，而是要作为核心的功能引入系统。安全功能永远是系统核心功能。
实现稳固的安全功能
为了达到系统安全的目的，作为ASP.NET开发人员，我们要在程序种增加功能。安全的系统都是经过严格的测试和审查的。我们后面的问题会详细的讲述ASP.NET的安全架构。
避免增加新的脆弱性
在向程序种增代码时，可能引入新的脆弱性。对于新增加的代码，要严格的审查，确保不会造成安全漏洞。
我们很多时候都是先把功能实现，然后再来考虑安全的问题，做一些维护。这样做很危险，所以我们在项目开始时候就考虑安全的问题。
还有就是要记得删除我们程序中的明显的漏洞。我们可能在开发调试的时候用了测试代码，如：
| 以下为引用的内容： public bool ValidateUser(string userName) { //testCode if(userName="app") return true; //.... } |
我们可以在代码中加//testCode(见上)，然后项目完成后查找所有的"testCode"，将其删除。
还有就是我们也教育用户，是他们对安全问题有一定的了解;我们对于用户的输入都要验证，还是那句话：所有用户都是恶意的。
四、给出一些建议
没有百分百的安全
计算机安全领域中有个说法，"唯一安全的系统是锁在安全柜中而没有通电的系统"。我们必须承认，系统不可能决定安全，如果攻击者有足够的能力和耐心，他们终会找到侵入系统的方法。
既然不可能绝对的安全，我们怎么办?我们可以尽可能的给未经授权的访问系统加大难度。这样就好比增加了护栏的高度，攻击者想要获取访问权限，就得付出更多的努力。而且很多的攻击者都是有投机的心理的-只找容易攻击的对象。
藏起来不能保证安全
我们常常将一些私人的文件藏在Web站点的秘密目录中，然后只告诉我们信任的人。可是，隐藏不能保证真正的安全。例子很多，如，公司在Web页面上使用隐藏的连接提供对"私人"目录的访问。这些连接可能是用一种透明图形隐藏在某个角落，对于Web页面的人不可见，但是对于网络搜索引擎来说，那么隐藏的链接和别的链接毫无分别。
所以，隐藏不一定安全。而且现在的常常用加密算法，之所以用是因为算法经过了严格的审查和破解测试，在一定时间内算法是安全的，假如有个算法，破解需要几十年甚至更长时间，在现有阶段，我们使用也可说是安全的。
应用程序的安全性由它最薄弱的环节决定
大家都知道水桶的模板原理：水桶装水的多少，由最短的那块模板决定的。安全问题也一样的。因为恶意的用户想进入系统，会尝试很多的方式很途径，一旦程序的最薄弱的环节被找到，整个系统可想而知。
建议在系统开发和完成的时候，构建出系统的结构图，然后标注从客户机一直到终端的数据库服务器所有环节，然后分析之间的连接情况，思考可能出问题的地方，改进。
安全问题贯穿项目开发
从项目的设计直到后期的部署，安全都要考虑。不要到最后才添加安全措施。
过分安全将会不利于项目的开发
有些时候，过度的强调安全不是好事情。如果系统安全很苛刻，如系统要求用户的密码必须是12位字符，而且还要有2个非数字字符，还要有大写，小写字母。用户很可能就记不住密码，甚至他们把密码直接写在纸上贴在电脑上，那么什么安全都没有了。所以安全的方案要折衷，和用户多商量。
安全不仅仅只是技术的问题
前面也讲过，在安全方面我们开发人员可以做的事情，很多的时候，用户是安全薄弱的环节，所以还要加强用户安全教育。
.分页: [1] [2]
TAG: ASP.NET 安全