代码编写中会遇到的安全性问题
一、常用的攻击手段
1．脚本注入
漏洞描述：
脚本注入攻击在通过浏览器使用用户输入框插入恶意标记或脚本代码时发生。
如：某个输入框允许用户向数据存储中插入内容，如果将一段js脚本插入其中，则当其他用户使用或浏览此数据存储中的内容时，则那段js代码会被激发执行。如果此代码执行后果可想而知。
解决方案：
当向数据存储插入数据之前，进行代码过滤，屏蔽其中的恶意字符。
2．跨站点脚本攻击
漏洞描述：跨站点脚本攻击非常类似于脚本插入攻击，当恶意脚本通过其他站点动态生成的web页面插入到web浏览器时发生。在这种攻击中，黑客的目标不是我们的站点，而是我们的用户。
如：当某个搜索页面通过get的形式传递搜索数据时（如：xxx.com?search=XXXXX），当在数据库没有查询到此内容，会在页面上将用户所搜索的信息显示出来（如：没有找到XXXX）,那么，如果黑客在search后边加上js代码(如：document.cookie)则后果可想而知。
解决方案：
对用get所传递的参数进行代码过滤，屏蔽其中的恶意字符。
3．Sql注入
漏洞描述：简单的说，sql注入就是将sql代码传递到应用程序的过程，但不是按照应用程序开发人员预定货期望的方式插入。由于应用程序设计很差，常常出现这种sql注入，它仅仅影响使用sql 字符串构建技术的应用程序。如：
解决方案：
对数据库操作前，屏蔽用户所提交的字符串中sql关键字。
4．Sql union攻击
漏洞描述：
攻击者也可以使用sql的union语句来获得更多的数据。尽管sql union攻击很难，但仍然是可能的。例如带有sql的union语句的注约束是：两个查询应该从匹配的查询中返回相同的列号，表达式或聚集函数、列的数据类型。
5．对脚本注入、跨站脚本攻击、sql注入、sql union攻击的总结：
上述的漏洞都是系统常见的漏洞，也是容易注意不到的漏洞，上述的漏洞修补起来非常简单，只需要两端字符串替换代码即可搞定，但要注意代码的使用位置，不要在没有必要的地方使用，否则会增加系统的额外负担。
上述漏洞的具体防范措施：
5.1验证内容
如果想避免我们在前面已介绍的几种类型的攻击，就必须记得在处理数据的输入前腰先验证它们。这种验证是一种很简单的验证，如检查所输入的内容是否为数值，是否为16或是大于16的值，或者确认用户仅可输入a~z,A~Z,0~9的有效字符和一些特殊的字符。
5.2筛选用户输入
当接收到来自非信任源的不恰当输入时，并不一定要拒绝该输入。在这种情况下，筛选输入是最好的办法。
5.3编码输入内容
在有些情况下是允许客户输入如<script>等这样的特殊字符的，但是这些字符时不允许执行的，那么就要对一些特殊字符重新编码。如 < 编码为<字符。（Server.HtmlEncode(string)）
5.4避免跨站点的脚本攻击
避免跨站点的脚本攻击的唯一方法就是在处理用户输入之前全面彻底地验证输入内容。
6．隐藏窗体字段
漏洞描述：开发人员有时会在页面上使用隐藏窗体用来保存一些数据。但是这些数据可以被任何人查看。只需要用户有一点点的html知识，就可以在本地保存html页面，修改页面中的值，在重新经页面提交给服务器。
解决方案：
始终使用session对象检查用户是否有一个有效的会话。
不再隐藏字段中保存任何敏感信息。如果不能避免这样做，应该在隐藏字段保存数据时，在加密的重提中保存会话密钥和时间戳。这样有助于验证来自浏览器的信息。
要想办法处理隐藏字段中的数据被删除时的情况
在客户端检查参数的长度和数据类型。
在服务器端重新进行验证。
7．Cookies
漏洞描述：
Cookies是在http请求和http相应操作期间被设置为http题头的一小块信息。Web开发人员也使用cookies在客户端存储数据。在cookies中保存的数据可能是会话密钥、浏览器行为、购物车等内容。黑客可以利用cookies中的信息，进行非法操作。
解决方案：
不在cookies中保存任何敏感信息。
如必须在cookies中保存敏感信息，则使用加密技术，对cookies内容进行加密，同时还要考虑到cookies内容被修改或删除的情况。
在cookies中保存敏感信息最佳的方式是使用窗体身份验证来创建加密的身份验证票据。
使用ssl来保护cookies不被窃取。但是ssl只能保护服务器与客户端之间的通信信息。无法保护存在客户端的信息。
8．url
漏洞描述：
许多开发人员是用url从一个页面向另一个页面传递信息。由于传递的信息是基于文本的，而且他在浏览器中是可见的，所以内容很容易被篡改。
解决方案：
不在url包含敏感信息。应该将所有敏感信息都保存在服务器中，或者使用加密的格式设置命该信息并在服务器上验证返回的结果。
编码url,也就是说，把所有参数都放在同一个同一个元素当中，在对此元素内的内容进行编解码。
9．视图状态
漏洞描述：
所有asp.net服务器空间都保存在一个叫做_viewstate的隐藏变量中。视图状态信息是以编码的字符串形式保存在隐藏的变量中。当从客户端向服务器端发送信息的过程中，信息有可能被黑客截获，造成数据的泄露。
解决方案：
使用ssl加密传输过程中的信息。
10．控制错误信息
漏洞描述：
处理异常的有效办法不是向用户展示任何有关异常的有用信息，而是将异常记录到时间日志中，并显示一个能够像忠实用户提供更多可用信息的普通错误信息。利用这种方式，可防止信息的泄露，也能避免遭到恶意错误信息的攻击。
解决方案：
使用单独的错误页面，显示错误信息，也就是说当程序发生错误时，转到已经定义好的错误页面上去。
11．禁用调试和跟踪
漏洞描述：
这两种功能在开发周期中很重要，但在产品环境中是没有意义的。如果开启调试和跟踪有可能暴露重要信息，如数据库的链接字符串。
解决方案：
在web.config和iis中关闭调试和跟踪。
上述说的是在程序编写过程中能够遇到的系统安全性方面的内容。
二、部分解决方案
- 1. 防暴力破解
1.1漏洞描述：用户登录阶段通过破解字典等反复登录，用来破解用户密码的方式。
1.2解决方案：
(1) 使用页面验证码，应用验证码是为了防止通过程序方式，自动去填写信息，然后自动发送给web服务器而欺骗服务器去其进行注册或登录。
(2) 限制ip和mac地址，有些图片验证码是可以通过破解程序读取的，所以当验证码失效后，则通过限定ip或mac地址错误登录的次数(当某个ip或mac地址的连续登录错误的次数超过n次后，则停用此用户)来限定。
2．登录/注册安全
2.1 漏洞描述：用户登录或者填写登录信息，向服务器端发送信息，有可能此信息被截获，导致用户的信息暴露。信息暴露分为(1)客户端信息暴露，如：客户端有病毒程序，自动记录用户所填写信息。(2)客户端向服务器端发送信息途中，信息被截获。(3)服务器端有病毒程序或被黑客控制等，客户信息在服务器端暴露。
2.2 解决方案：
2.1 客户端解决方案
(1)在页面上使用虚拟键盘，并且键盘数据生成顺序随即排列。这样用户输入信息只需要点击鼠标即可，这样可以防止客户端病毒程序记录键盘所按内容。
2.2传输过程中解决方案
(1)使用https协议进行数据的加密传输，这样可以保证在传输过程中的安全性。
(2)使用独立编写的客户端加密程序，在客户端将所发送的信息进行加密。
(3)使用外部设备，如加密key进行数据的加密。如：工行u盾。（原理：用户唯一身份信息经256位高强度加密后以电子证书的形式存入一个特殊的U盘内，该U盘只读且防拷贝，使用时，电脑发出身份认证信息，U盘接收后，将信息导入自身，进行解密运算后与证书内信息配对，配对成功后返回确认信息，整个解密、配对过程在U盘内部完成。）
3．上传漏洞
漏洞描述：黑客可以利用系统提供的上传功能，向服务器中上传恶意文件。用以控制服务器或者导致系统信息泄露。
解决方案：
- 限制扩展名。如只可以上传jpg,png,doc,rar等。
- 对上传文件的文件都标识进行验证。如：255216是jpg;7173是gif;6677是BMP,13780是PNG;7790是exe,8297是rar
- 对附加文件进行检测。有一种技术是“文件隐藏技术”，其实就是利用windows下的一条命令合并两个文件。
- 上传路径不能动态生成。此为iis6下的一个漏洞。当用户注册为一个名为 1.php的用户并上传一个改名为1.jpg的木马后，我们得到此访问路径为：http://xxx.xxxx.com/1.php/1.jpg 这样，这个1.jpg就会以php的后缀名运行。
三、高级内容
1． 秘密的存储位置
系统的一些敏感信息，如数据库的链接字符串等。如果存储的位置不当，则容易引起数据的泄露。如，存储在页面中，存储在后台编码中，存储在.config中，存储在受保护的.config中，存储在内存中，使用散列技术存储密码，使用data protection api 存储秘密。
2． 保护数据库的访问权限。
数据库是最容易受到攻击的地方，如果对数据的访问权限设置不当（权限过高），或者访问账户泄露，都可造成严重的后果。
解决方案：
1． 数据库账户。在给用户分配数据库权限是，尽量给最小的权限，这样能将分先降到最低。
2． 限制到数据库的链接。保护数据库最好的方法是不要将其放到公共区，这样可以保证数据库不能从外部进行访问。
3．将秘密存储在.net组建中。 用来保护数据库链接最好的方式是将期存储到.Net组件中或提供服务的com中。但是有些权限是可以访问dll文件的，当对dll文件反编译后，仍然是可以看到内容的。
3．Asp.net安全架构
Asp.net安全架构为几个关键的安全过程包括身份验证，授权，假冒和加密提供了必须功能
1．身份验证—谁到了那里？访问站点的用户身份是什么？
2．授权—您的许可级别是什么？访问站点的用户是否被授权他所请求的资源？
3．假冒—您准备假冒什么角色？用户可以利用他们的标识、或者asp.net 程序的标识或者一些其他的账户访问这些权限吗？
