1、验证验证机制在一个应用程序的用户访问处理中是一个最基本的部分。验证就是确定该用户的有效性。大多数的web应用程序都采用常规的验证模型，即用户提交一个用户名和密码，应用程序检查它的有效性。在安全性很重要的应用程序中，如在线银行，这个基本的验证模型常增加额外的证书和多级登录过程。在安全性要求更高的时候，其它的一些验证模型可以被用，如客户端证书，智能卡或挑战/应答（challenge-response）tokens。challenge-responsetokens的过程：用户要求登录时，系统产生一个随机数字串发送给用户。用户将这个串输入到token设备中，token设备将这个串与用户的秘密口令按特定的算法进行运算并产生一个回应串发送给系统，系统用同样的算法做验算即可验证用户身份。除了核心的登录过程外，验证机制也常采用其它的一些辅助功能，如自注册（self-registration，比如注册后通过邮件中的链接激活帐户），帐户恢复以及密码更改功能。尽管验证机制表面上简单，但是验证机制在设计和实现方面却存在着广泛的缺陷。一般的问题可能使一个攻击者能够识别其他用户的用户名，猜测他们的密码或者通过利用验证的逻辑缺陷绕过这个登录函数。当你攻击一个web应用程序时，你应该花大量的注意力在该web应用程序所包含的各种验证相关的功能方面。验证方面的缺陷将使你能够未经授权地访问敏感数据和功能
2、会话管理处理用户访问的下一个工作是管理授权用户的会话。在成功登录到应用程序后，用户将从遛襟粝颉他们的浏览发送一系列的HTTP请求来访问一些页面和功能。旎髂坑若同时，该应用程序将接收无数来自不同用户的其它的请求，有授权的用户，也有匿名的用户。为了实施有效的访问控制，应用程序需要一个方法来识别和处理这一系列来自每个不同用户的请求。实际上大多数的web应用程序都通过为每个用户创建一个会话和发送给用户一个令牌(token)来识别会话。会话本身是位于服务上的一套数据结构，它被用来跟踪与应用程序交互的用户的状态。在《Linux就该这么学》中也有提到关于会话管理的另外一些套路。令牌是一个具有唯一性的字符串，应用程序将它映射到会话。当一个用户已经收到一个令牌时，浏览器在随后的每次HTTP请求中会自动将这个令牌提交给服务器，以使得应用程序能够将该请求与用户相关联起来。尽管许多应用程序使用隐藏的表单域或URL查询字符串来实现这一目的，但是HTTPcookies是传送会话令牌的标准方法。如果一个用户在指定的时间内没有产生一个请求，那么会话将被认为结束。对于之后的访问，web应用程序会要求你重新登录。就攻击而言，会话管理机制高度地依赖于它的令牌的安全性。针对会话管理机制的多数攻击都是试图损害发送给别的用户的令牌。有可能的话，一个攻击者可以伪装成受害的授权用户来使用web应用程序。这一漏洞主要来自于两方面，其一是令牌生成的方法的缺陷，使得攻击者能够猜测到发送给别的用户的令牌，其二是令牌的后续处理的方法的缺陷，使得攻击者能够捕获别的用户的令牌。有少部分的应用程序通过另外的识别方式省掉了会话令牌的需要，比如，如果一个HTTP的内建的授权机制被使用的话，那么浏览器对于每次的请求都自动重新提交用户的证书，使得应用程序能够直接从证书识别用户。也存在其它别的方法，应用程序存储状态信息在客户端而非服务器上，这些状态信息通常采用加密的形式以防止被篡改。
3、访问控制处理用户访问的最后一步是正确决定对于每个独立的请求是允许还是拒绝。如果前面的机制都工作正常，那么应用程序就知道每个被接受到的请求所来自的用户的id。它据此决定用户对所请求要执行的动作或要访问的数据是否得到了授权。访问控制机制通常需要根据对应用程序的不同部分或不同类型的功能的考虑,实现一些小而好的逻辑。一个应用程序可能支持许多不同的用户角色，每个都牵涉到特定权限的不同组合。个别的用户可能会被允许访问该应用程序所容纳的整个数据的一个子集。特定的函数能够实现事务限制和其它的检查，所有这些都需要基于用户的id来得到正确的实施。由于访问控制本身的复杂性，这使得它成为使得一个攻击者能够获得未授权访问数据和功能这一安全漏洞的常见根源。开发者经常对用户会如何与应用程序交互作出有缺陷的假设，以及经常由于省略了对某些应用程序功能的访问控制检查而造成疏忽。由于对于每项功能都需要重复相同的检查，所以探查这些漏洞通常是十分费力的。然而由于访问控制缺陷的普遍性，当你攻击一个web应用程序时这种努力是值得的。