说在前面
博客里所有Web安全系列的文章均为博主对黑客攻防技术宝典:Web实战篇(The Web Application Hacker’s Handbook)所做的读书笔记。
Web应用程序防御机制
Web应用程序采用的防御机制由以下几个核心因素构成：
- 处理用户访问应用程序的数据和功能，防止用户获得未授权访问。
- 处理用户对应用程序功能的输入，防止错误输入造成不良行为
- 防范攻击者，确保应用程序在成为直接攻击目标时能够正常运转，并采取适当的防御和攻击挫败攻击者。
- 管理应用程序本身，帮助管理员监控其行为，配置其功能
处理用户访问
大多数Web应用程序使用三层相互关联的安全机制处理用户访问：
- 身份验证
- 会话管理
- 访问机制
身份验证
- 如果不采取身份验证，应用程序会把所有用户作为匿名用户处理，这是最低一级的信任。
- 绝大多数的应用程序都采取传统的身份验证模型，即要求用户提交用户名和密码。
会话管理
- 成功登录应用程序后，用户会访问各种页面和功能，从浏览器提出一系列http请求。与此同时，应用程序还会收到各类用户(包括通过验证的用户和匿名用户)发出的无数请求
- 为实施有效的访问控制，应用程序需要识别并处理每一名用户提交的各种请求
- 为满足以上要求，几乎所有Web应用程序都会为每个用户创立一个会话，并向用户发布一个标识会话的令牌。
- 会话本身是一组保存在服务器上的数据结构，用于追踪用户与应用程序的交互状态
- 令牌是一个唯一的字符串，应用程序将其映射到会话中。
- 当用户收到一个令牌时，浏览器会在随后的Http请求中将它返回给服务器，帮助应用程序将请求与该用户联系起来。
- 如果一段时间内用户没有发出请求，会话将自动终止。
令牌攻击
- 会话管理机制的有效性基本取决于其令牌的安全性，绝大多数针对它的攻击都企图攻破其他用户的令牌，如果令牌被攻破，攻击者就可以伪装成被攻破的用户，像已经通过验证的用户一样使用应用程序。
- 令牌生成过程中存在的缺陷是主要的漏洞来源，使攻击者能够推测出发布给其他用户的令牌。
- 少数应用程序不会向用户发布会话令牌，而是通过其他方法在多个请求中反复确认用户的身份，如果使用HTTP的内置身份验证机制，那么浏览器会自动在每个请求中反复提交用户证书，帮助应用程序直接通过这些请求识别用户。
- 在其他情况下，应用程序会将状态信息保存在客户端而非服务器上，通常还需要对这些信息进行加密。
访问控制
- 如果身份验证和会话管理运作正常，应用程序即可从收到的每一个请求确认用户身份，在此基础上，应用程序需要决定是否授权用户执行其所请求的操作或访问相关的数据
- 应用程序可支持无数不同的用户的角色，每种角色都拥有特定的权限，每名用户只允许访问应用程序中的部分数据。
处理用户输入
- 一个基本的安全问题：所有用户输入都不可信
- 大量针对Web应用程序的不同攻击都与提交错误输入有关。
- 确认输入(input validation)是防御这些攻击的必要手段
输入处理方法
拒绝已知的不良输入
这种方法一般使用一个黑名单，其中包含一组在攻击中使用 的已知的字面量字符串或模式。确认机制组织任何与黑名单匹配的数据，并接受其他数据。
接受已知的正常输入
这种方法使用一个白名单，其中包含仅与良性输入匹配的一组字面量字符串、模式或一组标准。确认机制接受任何与白名单匹配的数据，并阻止其他数据
净化
这种方法认可有时需要接受无法保证其安全的数据，应用程序并不拒绝这种输入，相反，它以各种方式对其进行净化，防止它造成任何不利的影响。数据中可能存在的恶意字符被彻底删除，只留下已知的安全的字符，或者进一步处理前对它们进行适当的编码或”转义”。
安全数据的处理
有时不需要确认输入本身，只需确保处理过程的绝对安全，即可避免这些漏洞。有些时候，可使用安全的编程方法避免常见的问题。
语法检查
在一些漏洞中，攻击者提交的输入与普通的非恶意用户提交的输入完全相同，之所以称为恶意输入，是因为攻击者提交的动机不同，例如，攻击者可能会修改通过隐藏表单字段提交的账号，企图访问其他用户的银行账号，这时，再多的语法确认也无法区别用户与攻击者的数据。为防止未授权访问，应用程序必须确认所提交的账号属于之前提交该账户的用户。
边界确认
- 服务器端应用程序第一次收到用户数据的地方是一个重要的信任边界，应用程序需要在此采取措施防御恶意输入
- 鉴于核心问题的本质，可以基于互联网与服务器端应用程序之间的边界来考虑输入确认问题。
处理攻击者
为处理攻击者而采取的措施一般由以下任务组成：
- 处理错误
- 维护审计日志
- 向管理员发出警报
- 应对攻击
处理错误
- 大多数Web开发语言通过try-catch块和受查异常提供良好的错误处理支持。
- 可以配置大多数应用程序服务器，使其以自定义方式处理无法处理的应用程序错误。
- 过于详细的错误信息会成为攻击者从应用程序窃取数据的重要渠道。
- 有效的错误处理措施通常与应用程序的日志机制整合在一起，后者尽可能地记录与无法预料的错误有关的调试信息。
维护审计日志
日志
计算机系统日志：在现代社会里，为了维护自身系统资源的运行状况，计算机系统一般都会有相应的日志记录系统有关日常事件或者误操作警报的日期及时间戳信息。(此释义取自百度百科)
审计日志(audit log)
在任何注重安全的应用程序中，日志应记录所有重要事件，一般这些事件应至少包括以下几项：
- 所有与身份验证功能有关的事件，如成功或失败登录、密码修改
- 关键交易，如信用卡支付与转账
- 被访问控制机制阻止的访问企图
- 任何包含已知攻击字符串，公然表明恶意意图的请求。
有效的审计日志功能一般会记录每个事件的发生时间、发出请求的IP地址和用户账户(如果通过验证)。这些日志必须受到严格的保护，避免未授权的读取或写入访问。
向管理员发出警报
许多时候我们希望对攻击者的攻击行为立即采取行动，实时响应攻击企图。，可以将实际影响降到最低。警报机制必须保证既能准确报告每次的真实攻击，又不会生成过多警报，造成它们被管理员忽略。警报监控的反常事件一般包括以下几种：
- 应用反常，如收到由单独一个IP地址或用户发出的大量请求，表明应用程序正在受到自定义攻击。
- 交易反常，如单独一个银行账户所转入或转出的资金数量出现异常。
- 包含已知攻击字符串的请求。
- 请求中普通用户无法查看的数据被修改。
