黑客攻防技术宝典Web实战篇第2版

2.1 处理用户访问

1、大多数Web应用程序采用三层相互关联的安全机制处理用户访问：

①身份验证

②会话管理

③访问控制

2.1.1 身份验证

1、身份验证机制是应用程序处理用户访问的最基本机制，用于确定其真实身份。

2、传统验证要求用户提交用户名和密码，后来按需求还要验证证书、口令等信息。

2.1.2 会话管理

1、当用户访问时，服务器端会建立一个令牌作为此用户访问识别码，通常将令牌存在HTTP Cookie。

2、攻击者运用生成令牌时的漏洞推测其他用户令牌实现攻击。

3、少数应用程序不发布令牌，二十通过多个请求重复确认用户身份。

2.1.3 访问控制

1、应用程序可支持多种不同用户角色，每种角色有特定权限。

2.2 处理用户输入

2.2.1 输入的多样性

1、应用程序必须接受更广泛的输入来应对输入的多样性。

2、除了用户通过浏览器界面输入的数据外，典型应用程序还会收到大量数据，在服务器端生成，并被传送给客户端，一遍客户端能够在随后的请求中将其返回给服务器。这些数据包括Cookie和隐藏表单字段。

2.2.2 输入处理方法

1、拒绝已知的不良输入：一般使用一个黑名单。但攻击者对输入转码或者转换其他形式躲避黑名单。

2、接受已知的正常输入：白名单，仅包含良性输入的数据，阻止其他数据。

3、净化：可能会接受潜在威胁数据，之后进行净化，防止不利影响。

4、安全数据处理：经常以不安全的方式处理用户提交的数据，确保处理过程绝对安全。

5、语法检查：有时攻击者输入和正常用户输入类似，但动机不同，所以需要确认所提交的账号属于之前提交该账号的用户

2.2.3 边界确认

1、边界确认是一种有效的安全处理模型。服务器端应用程序为每个单独组间或功能单元的输入当作恶意来源处理，除客户端与服务器之间外部边界外，应用程序在每一个信任边界上执行数据确认。

2、用户登录流程

①应用程序收到以后登录信息，表单确认输入合法、且不包含已知攻击签名。

②应用程序执行一个SQL查询，为防止SQL注入攻击，查询前需对用户输入潜在威胁字符转义。

③若成功登录，应用程序将用户资料某些数据传给SOAP服务，为防止SOAP注入攻击，需对用户资料中的任何XML字符编码。（SOAP是基于XML的简易协议，可使应用程序在HTTP之上进行信息交换。或者更简单地说：SOAP是用于访问网络服务的协议。）

④应用程序在浏览器显示账户信息，为防止跨站点脚本攻击，应用程序对植入返回页面的任何用户提交的数据执行HTML编码。

2.2.4 多步确认与规范化

1、一般攻击者或通过多种方式躲避查询，若<script>会被删除则可以用<scr<script>ipt>来躲避。

2、数据规范化就是指将数据转换或解码成一个常见的字符集的过程，但如果时时输入过滤之后才执行规范化，那么攻击者就可以通过使用编码躲避确认机制。

2.3 处理攻击者

2.3.1 处理错误

1、开发人员处理错误尽量不要讲一些重要错误信息展现出，易被攻击者利用，一般要通过try-catch块来处理错误。

2、有效的错误处理措施通常与应用程序的日志机制整合在一起，后者尽可能记录与无法预料的错误有关的调试信息。

2.3.2 维护审计日志

1、审计日志在调查对应用程序的入侵尝试时会发挥巨大作用，帮助开发人员了解实际情况。

2.3.3 向管理员发出警报

1、警报系统既要报告每次的真实攻击又不会生成过多的警报，造成它们被管理员忽视。

2、警报监控的反常事件：

①应用反常

②交易反常

③包含已知攻击字符串的请求

④请求中普通用户无法查看的数据被修改

2.3.4 应对攻击

1、除向管理员发出警报外，许多安全性至关重要的应用程序还含有内置机制，防御潜在恶意用户。

2.4 管理应用程序

1、任何有用的应用程序都需要管理与维护，可帮助管理员管理用户账户与角色，应用监控与审计功能，执行诊断任务并配置应用程序的各种功能。

2.5 小结

1、几乎所有Web应用程序都以某种形式采用相同的核心安全机制，在这些机制中，处理用户访问和用户输入的机制是最重要的机制。当针对应用程序发动攻击时，它们成为主要攻击对象。

2.6 问题

1、为什么说应用程序处理用户访问的机制是所有机制中最薄弱的机制？

答：典型的应用程序使用三重机制（身份验证、会话管理和访问控制）来处理访问。这些组件之间高度相互依赖，其中任何一个组件存在缺陷都会降低整个访问控制机制的效率。例如，攻击者可以利用身份验证机制中的漏洞以任何用户身份登录，并因此获得未授权访问权限。如果能够预测令牌，攻击者就可以假冒成任何已登录用户并访问他们的数据。如果访问控制不完善，则任何用户都可以直接使用应该受到保护的功能。

2、会话与会话令牌有何不同？

答：会话是服务器上保存的一组数据结构，用于追踪用户与应用程序交互的状态。会话令牌是应用程序为会话分配的一个特殊字符串，用户需要在连接提出请求的过程中提交该字符串，以重新确认自己的身份。

3、为何不可能始终使用基于白名单的方法进行输入确认？

答：许多时候，应用程序可能会被迫接受与已知为“良性”输入的列表或模式不匹配的待处理数据。例如，许多用户的姓名包含可用在各种攻击中的字符。如果应用程序希望允许用户以真实姓名注册，就需要接受可能的恶意输入，并确保安全处理这些输入。

4、攻击者正在攻击一个执行管理功能的应用程序，并且不具有使用这项功能的任何有效证书。为何他仍然应当密切关注这项功能呢？

答：攻击者可以利用任何访问控制核心机制中的缺陷未授权访问管理功能。此外，攻击者以低权限用户身份提交的数据最终将向管理用户显示，因此，攻击者可以提交一些恶意数据，用于在管理用户查看这些数据时攻破他们的会话，从而对管理用户实施攻击。

5、旨在阻止跨站点脚本攻击的输入确认机制按以下顺序处理一个输入：

(1)删除任何出现的<script>表达式；

(2)将输入截短为50个字符；

(3)删除输入中的引号；

(4)对输入进行URL解码；

(5)如果任何输入项被删除，返回步骤(1)。

是否能够避开上述确认机制，让以下数据通过确认？

“><script>alert(“foo”)</script>

答：是。如果没有第4步，此机制将是可靠的，能够过滤其旨在阻止的特定项目。但是，由于输入在执行过滤步骤后被解码，攻击者只需要对有效载荷中的选定字符进行URL编码，就可以避开这种过滤：

如果首先执行第4步，或根本不执行该步骤，攻击者将不可能避开上述过滤。