Asp.net Web应用程序安全（二）：用户验证和授权

验证用户

用户验证中的主要威胁：

1.       帐户劫持

2.       中间人攻击(man-in-the-middle):截取web通信，使攻击者（中间人）能够读取、修改两个系统间传送的数据

3.       Phishling（钓鱼）：一种中间人攻击类型

4.       未授权访问，在没有内容拥有者同意的情况下获得访问受限制内容和数据的权限

5.       信息泄漏

6.         特权扩大

7.       嗅探（sniffing）

安全的登录表单：安全的登录应该能保护用户的证书，如用户名、密码

1.       使用ssl或者传输密码的哈希，这样即使被截获，也没有什么损失。。

2.       验证输入，防止sql注入和跨站点攻击

3.       失败时要使用一般化的提示，防止基于返回错误消息的攻击。因此不应该提示用户用户名错误，密码错误之类的信息。

4.       不要在登录表单中的隐藏字段中传递敏感信息

5.       用Post方式发送数据，因为IE缓存、历史记录、代理服务器都会记录URL，这样都会造成威胁，Post不会产生缓存。调用“前进”“后退”按钮实际上就是在使用IE的内存缓存，历史记录使用的是IE的硬盘缓存。

安全的Forms验证

1、    web.config文件是脆弱的，不要在其中明文存储证书，最少要存储密码的哈希，而不应该存储明文。哈希的强度其实就是密码明文的强度，如果明文密码很容易猜到，哈希后也没有什么用处，因此尽可能的使用带有salt的哈希。

2、    表单验证是由aspnet实现的，如果请求的资源没有经过aspnet解析，forms验证就不会起作用，因此如果保护的资源默认是不经过aspnet的就要自己做映射。

3、    配置forms验证：

Name：验证cookie的名字，不能冲突，要唯一，不要用默认的“.ASPXAUTH”。

Protection:应该一直用ALL，保证安全和完整性。

Timeout：，默认30分，slidingExpiration设置为“true”时，从上次请求开始算起，自动更新验证超时时间，不要设置cookie为persistent，持久的cookie没有超时限制。

Path：不要用默认的“/”,并且区分大小写。通过限制路径可以减少跨站点攻击风险。

Requiressl：默认为false，为了安全应该设置为true，这样才能保证cookie的传输是安全的，是防止cookie劫持的唯一方式。

Credentials的passwordFormat不要用Clear

认识Passport验证的风险

Passport提供方便的同时，增加了风险。少用第三方的passport服务，自己开发Passport服务要特别重视安全性，passport的安全性取决于使用passport服务的所有站点中最弱的一个。

阻塞暴力攻击，

暴力攻击是很难有效防止的，所以网上没有什么是安全的，敏感信息不要不要上网传输。防止暴力攻击的方式就是减缓暴力攻击成功的时间，这样会躲过没有耐心的黑客。阻塞暴力攻击的几种方式：

1.     限制ip，中国ip很少是固定的，在加上代理服务器，很难有效，但为重要的用户限制一个IP地址或者IP段，使其只能通过几个ip访问，仍是一个好的方式。

2.     帐户锁定，用户几次登录失败后，锁定帐户一段时间，但也是问题很多，如：造成DoS攻击，为黑客提供真实的用户名（因为不能锁定不存在的用户），通过攻击禁用某个帐户等，还有很多可以绕过锁定的方式，如：对同一个密码尝试不同的用户名。折中的方式是，锁定时间减少为几分钟，这样对用户影响较小，也减缓了攻击。

3.     针对失败的登录，采用不可预测的行为，这些行为，人可以看懂，但程序不懂，如，使用不同的错误消息，让用户进入另一个页面再输入密码。这基于某些攻击工具通过某些字段来确定攻击是否成功。

4.     把受攻击多的用户，放到一个受限组，给用户发送邮件，提示可能受到攻击，让用户重新设置密码。

5.     使用CAPTCHA（全自动公开人机分离图灵测试），Captcha是能区分人和计算机的程序，如登录时加个验证码等类似的方式，但验证码图片要做的不容易被程序识别。

授权用户

验证只是确定了用户是合法的，并没有确定用户可以访问那些内容，授权做了这些工作，授权在验证后发生。授权要在程序设计时就考虑，主要有下面几个方面

基于角色的授权要结合基于资源的授权

总在web文件夹上设置受限制的NTFS权限。

授权节的编写方式：总是以“总是允许或者拒绝所有用户”的元素来结束配置，这样做有两个原因:

1.     运行时，授权模块自顶向下的处理所有的授权设置，直到找到一个匹配为止，然后，它根据找到的第一项访问规则是 <allow> 还是 <deny>来允许或拒绝对 URL 资源的访问。

2.     Asp.net先读取当前路径的web.config文件，然后父文件夹下的web.config，直到machine.config，以一种累积的方式处理授权。如果在当前路径下不匹配会转到父目录，直到machine.config。

这样就要求在配置<authorization>节时，要总是以“总是允许或者拒绝所有用户”的元素来结束配置，否则会很容易产生疏漏，读取到父级的配置，甚至machine.config的默认配置<allow users="*"/>。

代码访问安全性

这部分很复杂，简单的说：

代码安全是基于栈的，在调用时，clr会遍历所有用到的程序集，并检查调用者是否符合程序集要求的权限，如果栈中的任何一个不符合就抛出异常。

有两种方式增加代码的安全，一，通过声明的方式（特性）向CLR请求权限；二，通过代码要求调用者有特定的权限。详细的参见System.Security名称空间中的类，主要是从CodeAccessPermission派生的几个类。

基于角色的安全

基于角色的安全性模型支持与代码访问安全性模型中的权限对象类似的权限对象，就是PrincipalPermission，虽然它不是从CodeAccessPermission派生的。也可以以命令方式和声明方式进行的安全检查。

如：

[PrincipalPermissionAttribute(SecurityAction.Demand, Name = "Joan", Role = "Teller")]//通过声明的方式

 

String id = "Joan";
String role = "Teller";
PrincipalPermission principalPerm = new PrincipalPermission(id, role);//通过代码，命令方式

在2.0下为了支持Membership又增加了RolePrincipal（原来只有WindowsPrincipal,GenericPrincipal）。

.net2.0下的角色安全应该首先选用MemberShip，不能满足需要时可以自定义从IPrincipal等派生，实现自己的角色安全。