Web安全
数据加密
MD5(信息摘要算法)
MD5将任意长度的“字节串”变换成一个128bit的大整数，并且它是一个不可逆的字符串变换算法，换句话说就是，即使你看到源程序和算法描述，也无法将一个MD5的值变换回原始的字符串，从数学原理上说，是因为原始的字符串有无穷多个，这有点象不存在反函数的数学函数。
C#实现MD5加密
MD5采用的是对输入的任意长度的消息进行运算，产生一个128位的消息摘要。
你如果是使用MD5加密的话，非常好！虽然MD5的源代码满天飞，使用任何人都可以了解MD5的详尽算法描述，但是绝对没有任何人“可以将一个经由MD5算法加密过的字符串还原回原始的字符串”，这是真实的。
虽然说中国人“王小云教授”破解过所谓的MD5，那她的破解也是采用碰撞原理破解，如果你采用SHA和MD5的结合，她也不可能使用它的碰撞原理将其破解，换句话说，碰撞破解并不代表她能还原原始的字符串..
RSA
RSA算法是第一个能同时用于加密和数字签名的算法，也易于理解和操作。RSA是被研究得最广泛的公钥算法，从提出到现在的三十多年里，经历了各种攻击的考验，逐渐为人们接受，普遍认为是目前最优秀的公钥方案之一。
DES
DES算法为密码体制中的对称密码体制，又被成为美国数据加密标准，是1972年美国IBM公司研制的对称密码体制加密算法。 明文按64位进行分组， 密钥长64位，密钥事实上是56位参与DES运算（第8、16、24、32、40、48、56、64位是校验位， 使得每个密钥都有奇数个1）分组后的明文组和56位的密钥按位替代或交换的方法形成密文组的加密方法。
其入口参数有三个：key、data、mode。key为加密解密使用的密钥，data为加密
解密的数据，mode为其工作模式。当模式为加密模式时，明文按照64位进行分组，形成明文组，key用于对数据加密，当模式为解密模式时，key用于对数据解密。实际运用中，密钥只用到了64位中的56位，这样才具有高的安全性。
三种加密算法的比较：
由于进行的都是大数计算，使得RSA最快的情况也比DES慢上倍，无论是软件还是硬件实现。速度一直是RSA的缺陷。一般来说只用于少量数据加密。
DES算法具有极高安全性，到目前为止，除了用穷举搜索法对DES算法进行攻击外，还没有发现更有效的办法。而56位长的密钥的穷举空间为256，这意味着如果一台计算机的速度是每一秒种检测一百万个密钥，则它搜索完全部密钥就需要将近2285年的时间，可见，这是难以实现的，当然，随着科学技术的发展，当出现超高速计算机后，我们可考虑把DES密钥的长度再增长一些，以此来达到更高的保密程度。
数据库安全通信
Sql 注入。
注入式攻击漏洞产生的原因是通过字符串连接动态地构造查询，解决的办法是完全避免字符串查询，而是参数化或者使用存储过程。
1．使用安全的密码策略
我们把密码策略摆在所有安全配置的第一步，请注意，很多数据库账号的密码过于简单，这跟系统密码过于简单是一个道理。对于sa更应该注意，同时不要让sa账号的密码写于应用程序或者脚本中。健壮的密码是安全的第一步，建议密码含有多种数字字母组合并9位以上。SQL Server安装的时候，如果是使用混合模式，那么就需要输入sa的密码，除非您确认必须使用空密码，这比以前的版本有所改进。同时养成定期修改密码的好习惯，数据库管理员应该定期查看是否有不符合密码要求的账号。
2．使用安全的账号策略
由于SQL Server不能更改sa用户名称，也不能删除这个超级用户，所以，我们必须对这个账号进行最强的保护，当然，包括使用一个非常强壮的密码，最好不要在数据库应用中使用sa账号，只有当没有其他方法登录到 SQL Server 实例（例如，当其他系统管理员不可用或忘记了密码）时才使用 sa。建议数据库管理员新建立个拥有与sa一样权限的超级用户来管理数据库。安全的账号策略还包括不要让管理员权限的账号泛滥。
SQL Server的认证模式有Windows身份认证和混合身份认证两种。如果数据库管理员不希望操作系统管理员来通过操作系统登录来接触数据库的话，可以在账号管理中把系统账号“BUILTIN\Administrators”删除。不过这样做的结果是一旦sa账号忘记密码的话，就没有办法来恢复了。很多主机使用数据库应用只是用来做查询、修改等简单功能的，请根据实际需要分配账号，并赋予仅仅能够满足应用要求和需要的权限。比如，只要查询功能的，那么就使用一个简单的public账号能够select就可以了。
3．加强数据库日志的记录
审核数据库登录事件的“失败和成功”，在实例属性中选择“安全性”，将其中的审核级别选定为全部，这样在数据库系统和操作系统日志里面，就详细记录了所有账号的登录事件。请定期查看SQL Server日志检查是否有可疑的登录事件发生，或者使用DOS命令。
4．管理扩展存储过程
对存储过程进行大手术，并且对账号调用扩展存储过程的权限要慎重。其实在多数应用中根本用不到多少系统的存储过程，而SQL Server的这么多系统存储过程只是用来适应广大用户需求的，所以请删除不必要的存储过程，因为有些系统的存储过程能很容易地被人利用起来提升权限或进行破坏。如果您不需要扩展存储过程Xp_cmdshell请把它去掉。使用这个SQL语句：
use master
sp_dropextendedproc 'Xp_cmdshell'
Xp_cmdshell是进入操作系统的最佳捷径，是数据库留给操作系统的一个大后门。如果您需要这个存储过程，请用这个语句也可以恢复过来。
sp_addextendedproc 'xp_cmdshell', 'xpSQL70.dll'
如果您不需要请丢弃OLE自动存储过程（会造成管理器中的某些特征不能使用）。
这些过程如下： Sp_OACreate Sp_OADestroy Sp_OAGetErrorInfo Sp_OAGetProperty
Sp_OAMethod Sp_OASetProperty Sp_OAStop
去掉不需要的注册表访问的存储过程，注册表存储过程甚至能够读出操作系统管理员的密码来，命令如下：
Xp_regaddmultistring Xp_regdeletekey Xp_regdeletevalue
Xp_regenumvalues Xp_regread Xp_regremovemultistring
Xp_regwrite
还有一些其他的扩展存储过程，也最好检查检查。在处理存储过程的时候，请确认一下，避免造成对数据库或应用程序的伤害。
6．不要让人随便探测到您的TCP/IP端口
默认情况下，SQL Server使用1433端口监听，很多人都说SQL Server配置的时候要把这个端口改变，这样别人就不会轻易地知道使用的什么端口了。可惜，通过微软未公开的1434端口的UDP探测可以很容易知道SQL Server使用的什么TCP/IP端口。不过微软还是考虑到了这个问题，毕竟公开而且开放的端口会引起不必要的麻烦。在实例属性中选择TCP/IP协议的属性。选择隐藏 SQL Server实例。如果隐藏了SQL Server实例，则将禁止对试图枚举网络上现有的 SQL Server实例的客户端所发出的广播作出响应。这样，别人就不能用1434来探测您的TCP/IP端口了（除非用Port Scan）。
7．修改TCP/IP使用的端口
请在上一步配置的基础上，更改原默认的1433端口。在实例属性中选择网络配置中的TCP/IP协议的属性，将TCP/IP使用的默认端口变为其他端口。
8．拒绝来自1434端口的探测
由于1434端口探测没有限制，能够被别人探测到一些数据库信息，而且还可能遭到DoS攻击让数据库服务器的CPU负荷增大，所以对Windows 2000操作系统来说，在IPSec过滤拒绝掉1434端口的UDP通信，可以尽可能地隐藏您的SQL Server。
数据验证
为什么要验证？
黑客的惯用手法是混淆code 与参数， 让参数变成可执行的code。
XSS （MDI项目中存在！）
XSS又叫CSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。
例子：
http://192.168.1.153:256/XSS.aspx
防范措施：过滤。
Microsoft anti-xss 库。
引擎： Security run-time Engine,(SRE)
需要加入httpmodule
缺点：不能保护任何通过 Response.Write 方式或者是使用<%= 标记 添加到页面中的输出。
身份验证
在Asp.Net WebForm的中要做到身份认证微软为我们提供了三种方式，其中最常用的就是我们的Form认证，需要配置相应的信息。例如下面的配置信息：
<authentication mode="Forms">
<forms loginUrl="Login.aspx" defaultUrl="Default.aspx" protection="All" />
</authentication>
<authorization>
<deny users="?"/>
<allow users="*"/>
</authorization>
自定义ActionFilter
有时候这样的认证或许您还不能够满足，或者说您觉得不够灵活，那么也没有关系，Asp.Net MVC是允许您自定义ActionFilter的。例如我现在自定义身份认证：
public class RequiresAuthenticationAttribute:ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (!filterContext.HttpContext.User.Identity.IsAuthenticated)
{
string returnUrl = filterContext.HttpContext.Request.Url.AbsolutePath;
string redirectUrl = string.Format("?ReturnUrl={0}", returnUrl);
string loginUrl = FormsAuthentication.LoginUrl + redirectUrl;
filterContext.HttpContext.Response.Redirect(loginUrl, true);
}
}
}
如果需要进行用户管理，我再定义角色相关的Filter：
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Security;
namespace MvcApplication1.MyClass
{
public class RequiresRoleAttribute:ActionFilterAttribute
{
public string Role { get; set; }
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (!string.IsNullOrEmpty(Role))
{
if (!filterContext.HttpContext.User.Identity.IsAuthenticated)
{
string returnUrl = filterContext.HttpContext.Request.Url.AbsolutePath;
string redirectUrl = string.Format("?ReturnUrl={0}", returnUrl);
string loginUrl = FormsAuthentication.LoginUrl + redirectUrl;
filterContext.HttpContext.Response.Redirect(loginUrl, true);
}
else
{
bool isAuthenticated = filterContext.HttpContext.User.IsInRole(Role);
if (!isAuthenticated)
{
throw new UnauthorizedAccessException("You have no right to view the page!");
}
}
}
else
{
throw new InvalidOperationException("No Role Specified!");
}
}
}
}
会话安全
会话劫持原理
我们可以把会话劫持攻击分为两种类型：1）中间人攻击(Man In The Middle，简称MITM)，2）注射式攻击（Injection）；并且还可以把会话劫持攻击分为两种形式：1）被动劫持，2）主动劫持；被动劫持实际上就是在后台监视双方会话的数据流，丛中获得敏感数据；而主动劫持则是将会话当中的某一台主机"踢"下线，然后由攻击者取代并接管会话。
http会话劫持
Web应用程序是通过2种方式来判断和跟踪不同用户的：Cookie或者Session（也叫做会话型Cookie）。其中Cookie是存储在本地计算机上的，过期时间很长，所以针对Cookie的攻击手段一般是盗取用户Cookie然后伪造Cookie冒充该用户；而Session由于其存在于服务端，随着会话的注销而失效（很快过期），往往难于利用。所以一般来说Session认证较之Cookie认证安全。
会话型cookie也是可以通过程序获得的，换句话说我们进行TCP会话劫持的时候如果针对http会话劫持的话可以截获所有http内容包括Session信息。
|
|
WCF中通过使用自定义绑定来指定服务使用安全会话 (WCF)
<configuration>
<system.serviceModel>
<client>
<!-- this endpoint has an https: address -->
<endpoint name=""
address="https://localhost/servicemodelsamples/service.svc"
binding="customBinding"
bindingConfiguration="reliableSessionOverHttps"
contract="Microsoft.ServiceModel.Samples.ICalculator" />
</client>
<bindings>
<customBinding>
<binding name="reliableSessionOverHttps">
<reliableSession />
<httpsTransport />
</binding>
</customBinding>
</bindings>
</system.serviceModel>
</configuration>
安全日志
log4net是一个功能著名的开源日志记录组件。利用log4net可以方便地将日志信息记录到文件、控制台、Windows事件日志和数据库（包括MS SQL Server, Access, Oracle9i,Oracle8i,DB2,SQLite）中。并且我们还可以记载控制要记载的日志级别，可以记载的日志类别包括：FATAL（致命错误）、ERROR（一般错误）、WARN（警告）、INFO（一般信息）、DEBUG（调试信息）。
代码安全
http://192.168.1.153:256/Log4NetDemo.aspx
保护IIS
1. 专门为IIS应用和数据设置一个NTFS磁盘驱动器。如果可能的话，不允许IUSER（或者无论什么匿名用户）存取任何其它的磁盘驱动器。如果应用遇到任何由于匿名用户没有权限存取位于其它磁盘驱动器上的程序而造成的问题，那么，使用Sysinternals的FileMon来寻找哪一个档案该用户不能存取，然后把该程序移至IIS磁盘驱动器上。如果这样不可行的话，则允许IUSER仅可存取该档案。
- 设置磁盘驱动器上的NTFS权限：
Developers = Full
IUSER = Read and execute only
System and admin = Full
- 使用一个软件防火墙确保没有终端用户（只有研发人员）可以存取IIS机器上除了port 80之外的其它埠。
- 使用微软的工具来保护机器：IIS Lockdown和UrlScan。
- 启动使用IIS的日志文件(logging)功能。除了IIS纪录外，如果可能的话，同时也使用防火墙日志文件功能。
- 把记录的日志(log)从预设地点移开，并确保已经进行备份。为日志档案夹建立一个备份，这样在另一个位置总是有一个可以使用的备份档。
- 启动机器上的Windows监督功能(auditing)，因为在试图反向追查攻击者的行为的时候总会发现资料不足。利用监督日志，你可借着执行脚本来检查任何可疑的行为，然后发送报告给管理员。这听起来好像有一点极端，但是如果贵公司非常重视安全的话，这种作法可说十分值得鼓励。建立监督功能来报告所有的失败账号登录事件。另外，就跟先前的IIS日志一样，请将默认值位置 （c:\winnt\system32\config\secevent.log）改变为另一个不同的位置，并且确保你有一个备份而且有一个复制的拷贝文件。
- 经常多阅读一些安全文章（各种来源的）。最好是尽可能多了解IIS，并进行全面的安全作法，而不仅仅是按照其它人（比如我）告诉你的经验来实现。
- 加入IIS漏洞邮件清单(mailing list)，并要确实加以阅读以掌握最新状态。这种列表有来自因特网安全系统的X-Force Alerts and Advisories。
- 最后，确保你经常执行Windows Update，并重复检验修补程序真的已经有安装妥当。
暴力破解
应对措施
一种思路是：定位客户端，限制客户端的请求频率。一般来说，通过两个途径可确定某个客户端，IP地址和Cookie。但是，这种方式一般来说也是被攻破的，比如使用AccessDriver这样的工具就可以更换IP地址，同时，再清空cookie就可以做到。
其次，使用验证码。这是一种非常有效的措施，但是一定程度上降低了用户体验。
有一种思路：
protected void ButtonLogin_Click(object sender, EventArgs e)
{
string loginName = "luminji";
if (AddAndGetLoginCount(loginName) > 5)
{
//block
}
else
{
if (CheckLogin(loginName) == true)
{
ClearLoginCount(loginName);
}
}
}
//只适用于单机，如果是集群，需要分布式缓存
int AddAndGetLoginCount(string userNanme)
{
if (Cache[userNanme] == null)
{
Cache.Insert("luminji", 1, null,
System.Web.Caching.Cache.NoAbsoluteExpiration, TimeSpan.FromSeconds(10));
return 1;
}
else
{
int count = (int)Cache[userNanme] + 1;
Cache[userNanme] = count;
return count;
}
}
void ClearLoginCount(string userName)
{
if (Cache[userName] != null)
{
Cache.Remove(userName);
}
}
private bool CheckLogin(string loginName)
{
throw new NotImplementedException();
}
