1、为什么说应用程序处理用户访问的机制是所有机制中最薄弱的机制？
典型的应用程序使用三重机制（身份验证、会话管理和访问控制）来处理访问。这些组件之间高度相互依赖，其中任何一个组件存在缺陷都会降低整个访问控制并访问他机制的效率。例如，攻击者可以利用身份验证机制中的漏洞以任何用户身份登录，并因此获得授权访问权限。如果能够预测令牌，攻击者就可以假冒成任何已登录用户们的数据。如果访问控制不完善，则任何用户都可以直接使用应该受到保护的功能。
2、会话与会话令牌有何不同？
会话是服务器上保存的一组数据结构，用于追踪用户与应用程序交互的状态。会话令牌是应用程序为会话分配的一个特殊字符串，用户需要在连接提出请求的过程中提交该字符串，以重新确认自己的身份。
3、为何不可能始终使用基于白名单的方法进行输入确认？
许多时候，应用程序可能会被迫接受与已知为“良性”输入的列表或模式不匹配的待处理数据。例如，许多用户的姓名包含可用在各种公鸡中的字符。如果应用程序希望允许用户以真实姓名注册，就需要接受可能的恶意输入，并确保安全处理这些输入。
4、攻击者正在攻击一个执行管理功能的应用程序，并且不具有使用这项功能的任何有效证书。为何他仍然应当密切关注这项功能呢？
攻击者可以利用任何访问控制核心机制中的缺陷未授权访问管理功能。此外，攻击者以低权限用户身份提交的数据最终将向管理员用户显示，因此，攻击者可以提交一些恶意数据，用于在管理用户查看这些数据时攻破他们的会话，从而对管理用户实施攻击。
5、旨在阻止跨站点脚本攻击的输入确认机制按以下顺序处理一个输入：
(1)删除任何出现的<script>表达式；（2）将输入截短为50个字符；（3）删除输入中的引号；（4）对输入进行URL解码；（5）如果任何输入项被删除，返回步骤（1）。
是否能够避开上述确认机制，让以下数据通过确认？
“><script>alert(“foo”)</script>
是。如果没有第4步，此机制将是可靠的，能够过滤其旨在阻止的特定项目。但是，由于输入在执行过滤步骤后被解码，攻击者只需要对有效载荷中的选定字符进行URL编码，就可以避开这种过滤：
">
如果首先执行第4步，或根本不执行该步骤，攻击者将不可能避开上述过滤。