安全指南 学习笔记（1）

感觉在网站安全方面很欠缺，所以想好好学习一下，所以跑到了MS的网站上去找资料～

http://www.microsoft.com/china/technet/security/guidance/secmod01.mspx

学习了留点文字～

第一篇 构建安全的分布式 Web 应用程序的基础及应遵循的一组重要安全原则

构建安全的分布式 Web 应用程序的基础：身份验证、授权和安全通信。

任何成功的应用程序安全策略都具有牢固的基础，即综合利用身份验证、授权和安全通信机制来保护机密数据的安全和完整性。

身份验证

身份验证可明确识别应用程序的客户端，客户端可能包括最终用户、服务、进程或计算机。在安全术语中，经过身份验证的客户端称为主体。

身份验证在分布式 Web 应用程序的所有层中进行。最终用户通常需要输入用户名和密码来由 Web 应用程序对其进行初始验证。接着，当中间层应用程序服务器（如果体系结构中包含此类服务器）和数据库服务器处理最终用户的请求时，它们将对用户执行身份验证以确认和处理该请求。

在许多应用程序中，下游服务器和组件不会对最终用户进行身份验证，而是对上游应用程序这个实体进行身份验证以了解信任关系，在确认可以信任上游应用程序已正确验证该用户并授权后，将转发该请求。

授权

授权过程用于控制经过身份验证的客户端可以访问哪些资源和操作。资源包括文件、数据库、表、行等等，以及注册表项和配置数据等系统级资源。

许多 Web 应用程序都授权客户端访问通过方法公开的操作，而不是直接访问底层资源，这主要是考虑到可伸缩性和易于管理性。这意味着，使用诸如 Windows ACL 等平台级安全机制来保护系统级资源仍是必要的。许多常见的应用程序级授权方案都使用角色来将用户分组，同一个组中的用户在应用程序中共享相同的权限。

安全通信

许多应用程序都在应用层之间传递机密数据，例如从数据库服务器到浏览器或反之。机密数据包括银行帐户详细信息、信用卡号码、工资单数据等等。此外，在网络上传递登录凭据时，应用程序还必须保护这些凭据的安全。

安全通信提供以下两项功能：

保密性。保密性是指确保数据处于私有和保密状态，并且不会被可能使用网络监控软件的窃听者查看到。通常借助加密来达到保密目的。

完整性。安全的通信通道还必须能确保数据受到保护，以防止数据在传输过程中遭到意外或蓄意（恶意）的修改。完整性通常是通过使用“消息身份验证代码”(Message Authentication Code, MAC) 实现的。

由于公司网络内部会出现许多意想不到的信息泄露和安全漏洞，因此，在防火墙内外应用安全通信技术非常重要。

下图 总结了各种技术及其提供的主要身份验证和授权方式。

　　　　　.NET Web 应用程序安全

构建分布式 Web 应用程序时应遵循的一组重要安全原则：

1、采用最少权限的原则。运行脚本或执行代码的进程应当尽可能用权限最少的帐户运行，从而在进程安全受到危害时限制可能造成的损坏。如果恶意用户设法将代码注入某个服务器进程，那么授予该进程的权限会在很大程度上决定该用户可执行的操作类型。应当将需要更高信任级别（和更高权限）的代码分配在单独的进程内以进行隔离。
ASP.NET 开发小组已意识到这一点，并特别设置为以拥有最少权限的 ASP.NET 帐户（使用 ASPNET 帐户）来运行。这一更改已在 .NET Framework 的最初版本中实现。但在测试版中，ASP.NET 在 SYSTEM 帐户下运行，这从本质上讲是一种较不安全的设置。

2、使用纵深防御。在应用程序中的每一层和每个子系统中设置检查点。检查点是网关守卫，它们确保只有经过身份验证和授权的用户才能访问下一个下游层。

3、不要信任用户输入。应用程序应该彻底验证所有用户输入，然后再根据用户输入执行操作。验证可能包括筛选特殊字符。针对用户意外地操作失误和某些人通过在系统中注入恶意命令蓄意进行攻击的情况，这种预防性措施对应用程序起到了保护作用。常见的例子包括 SQL 注入攻击、脚本注入和缓冲区溢出。

4、使用默认安全设置。开发人员往往仅仅为了使应用程序运行而使用安全性较低的设置。如果应用程序所需的功能使您不得不减小默认安全设置的安全级别或更改这些默认的安全设置，请在更改前测试更改所带来的后果并了解可能的隐患。

5、不要通过隐藏来保障安全。尝试使用让人迷惑的变量名来隐藏机密信息或将它们存储在不常用的文件位置，这些方法都不能提供安全保障。以上操作类似于“捉迷藏”，而最好的方法是使用平台功能或使用已被证实可行的技术来保护数据。

6、在关口进行检查。您不必总是将用户的安全上下文传递到后端来进行授权检查。这种做法在分布式系统中通常并不是最佳选择。在关口检查客户端指的是在第一个身份验证点（例如，Web 服务器上的 Web 应用程序内）授予用户权限，并确定允许用户访问的资源和操作（可能由下游服务提供）。
如果在关口设计可靠的身份验证和授权策略，就不必将原调用方的安全上下文一路委派到应用程序数据层。

7、假定外部系统是不安全的系统。如果外部系统不归您所有，不要假定有人为您保证安全。

8、减小表面区域。避免公开不需要公开的信息。如果公开这些信息，就有可能导致更多安全漏洞。同时，处理错误的方式一定要适当。向最终用户返回错误消息时，不要公开任何不需要公开的信息。

9、以安全的方式显示错误消息。如果应用程序失败，一定要保护好机密数据。同时，不要在错误消息中提供过于详细的数据，也就是不要提供任何有助于攻击者发现应用程序漏洞的详细信息。详细的错误信息应写入 Windows 事件日志。

10、不要忘记您的安全程度受最薄弱环节制约。考虑安全性时，应该将应用程序所有层的安全性都考虑在内。

11、禁止不使用的内容。您可以通过禁用应用程序不需要的模块和组件来去除一些潜在的漏洞。例如，如果应用程序不使用输出缓存，则应禁用 ASP.NET 输出缓存模块。这样，即使以后在该模块中发现安全漏洞，应用程序也不会受到威胁。

转载于:https://www.cnblogs.com/wanlang/archive/2006/07/07/444894.html