2024年4月20日发(作者：)
第17章 的安全性
17.1
威胁来自何方
17.2
安全性上下文
17.3
使用
Forms
身份验证
17.4
成员资格与角色管理
API
17.5
安全性相关的控件
许多开发者都认识到，安全性并不是一项能够事后添加到现有应用程序的功能。换而言之，
不能等到开发阶段的后期才引入它。安全性是应用程序的固有特性，应作为设计阶段的首
要任务来规划。
因其本性使然，
Web
应用程序很容易遭受各种类型的攻击，根据应用程序本身的特性，其
毁坏力和影响程度是不同的。最安全的
Web
应用程序是那些能够实际抵御攻击的应用程序，
而不是设计上完美无缺的应用程序。安全性是一个相当复杂的问题，不同应用程序的解决
方案各不相同。但应记住，安全性的实现需要同时在应用程序级和系统级采取合理的措施。
提供了内建的应用程序级保护基础架构，能够防止对
Web
页面的未授权访问，
这样便简化了安全应用程序的编写。但应意识到，这种安全性只是安全性的一个方面。真
正安全的
Web
站点能够很好地防御服务器攻击，而这种攻击很可能会逾越应用程序最坚实
的逻辑防线。
本章将讨论
安全环境，其中包括它与服务器端
Internet
信息服务
(IIS)
身份验证机
制的关系，以及抵御
Web
攻击的最佳编码实践。
【
805
】
17.1 威胁来自何方
安全性的概念意味着攻击者的存在，而我们要竭力抵御。表
17.1
对最常见的几种
Web
攻击
做了总结。
表17.1 常见的Web攻击
攻 击
跨站点脚本攻击
(Cross-site scripting，XSS)
说 明
恶意的用户输入随页面回发
攻 击
拒绝服务
(Denial of Service，DoS)
窃听(Eavesdropping)
隐藏字段篡改
(Hidden-field tampering)
单键攻击(One-click attack)
会话劫持(Session hijacking)
SQL注入(SQL injection)
说 明
第17章 的安全性
续表
攻击者向网络中发送大量虚假请求，致使系统负担过重，造成网路阻塞
由于未加密的网络数据包在网络中是透明的，因而攻击者可以通过窃听
工具读取它们
攻击者会篡改填充有敏感数据的未被检查的(受信任的)隐藏字段
通过脚本发送恶意的HTTP投递指令
攻击者猜中或窃取有效的会话ID，进而连接到另一个用户的会话
代码在不知情的情况下将攻击者插入的恶意输入连接成危险的SQL命令
从根本上讲，不论将用户向浏览器的标记中插入何种数据，都有可能遭受代码注入攻击
(
即，
SQL
注入和
XSS
的各种变体
)
。此外，敏感数据不应被传输
(
更不要说以明文的形式传输了
)
，
而必须安全地保存在服务器上。
如果有办法编写既防注入又防篡改的应用程序，那么它可能只需要具备以下
3
点：
z
代码实践
采取数据验证、类型与缓冲长度检查，以及防篡改措施。
z
数据访问策略
通过角色来限制弱权限的帐户访问服务器的资源，并使用存储过
程，或者至少使用带参数的命令。
z
有效的存储与管理
不将敏感数据发送到客户端，使用经过散列处理来检测数据是
否被篡改，对用户进行身份验证，保护标识
(
身份
)
信息，并采用严格的密码策略。
可以看出，为了确保应用程序的安全，需要开发者、架构师和管理员齐心协力，除此以外，
别无他法。
【
806
】
17.2 安全性上下文
从应用程序的角度来看，安全性主要是对用户进行身份验证，以及授予其对系统资源的操
作权限。
结合了
IIS
、
.NET Framework
和操作系统的底层安全服务，提供了身份
验证和授权机制。
应用程序整体的安全性上下文由以下
3
个级别构成。
z
IIS
级将有效的安全令牌
(security token)
与请求的发送者关联
(
该安全令牌取决于当
前
IIS
身份验证机制
)
。
z
工作进程级会确定处理该请求的
工作进程中线程的标识。如果
启用了模拟
(impersonation)
，那么它会更改与该线程关联的安全令牌。根据当前使
用的进程模型，该进程模型的标识会由配置文件或
IIS
元库中的设置确定。
z
管道级会获取当前应用程序特定用户的凭据。这项工作完成的方式取决于
应用程序最常选择的是
Forms(
窗配置文件中有关身份验证和授权的设置。
体
)
身份验证。
679
发布者：admin，转转请注明出处：http://www.yc00.com/news/1713550551a2271302.html
评论列表（0条）