第二章、核心防御机制（一）
在 上一章 中我们讲到web应用程序的核心问题在于用户可以提交任何输入，那么相对应的防御机制也大都是针对用户的请求进行处理防御
下面是防御机制的核心因素：
- 处理用户访问应用程序的数据和功能，防止用户获得未授权访问。
- 处理用户访问程序的输入，防止错误输入造成不良行为
- 处理攻击者，确保应用程序在成为攻击目标时能正常运转。并采取攻击措施挫败攻击者。
- 管理应用程序本身，帮助管理员监控其行为，配置其功能。
2.1、处理用户访问
用户分为三种：匿名、身份验证通过、管理员。
web应用程序使用三种相互关联的安全机制处理用户访问：
- 身份验证
- 会话管理
- 访问控制
所谓一环套一环，那么一环破了就能各个击破，这三种机制有一种存在缺陷就意味着整个web应用程序会被攻击者访问控制。
身份验证：
web应用程序处理用户访问的最基本机制。最为普遍的验证模式是提交用户名与密码登录访问。此外还有注册，密码修改等功能。攻击者一般通过确认用户名推测密码或者绕过登录进行攻击。
会话管理：
web应用程序收到验证成功登录的用户请求，也会收到匿名请求，为了实施对不同用户的访问控制，web应用程序需要为每一位用户建立一个会话，并且附带一个标识回话的令牌(token)。
会话是保存在服务器上的一组数据结构，记录追踪与用户的交互状态。
令牌是唯一映射会话的字符串，服务器随机生成一个令牌后将令牌发给用户的同时自己也保存一份。当用户收到令牌后，浏览器发送的HTTP请求便会附加上令牌，服务器将收到的令牌与本地保存的令牌对比。校验通过则响应请求返回数据。如果一段时间没有请求，会话将终止。
令牌可以通过隐藏表单字段、URL查询字符串的方式传输。每个令牌只使用一次
会话管理机制的安全取决于令牌，如果令牌被攻击者攻破或者攻击者可以推测出令牌的生成过程，那么就可以伪装其他用户干坏事。
如果想更深了解会话，令牌，cookie，请访问https://www.cnblogs.com/moyand/p/9047978.html
访问控制：
访问控制是web应用程序针对用户的身份而决定响应/拒绝用户的请求。一般这种机制需要精心设计的逻辑。探查访问控制漏洞也是很费事的。
2.2、处理用户输入
输入多样性
- 用户输入的字符串长度，字母，空格，符号，数字等等
- 用户可能需要展示一些web攻击字段（或许在写一篇攻击教程），不能看似恶意就拒绝输入
- 用户输入请求中包含特殊的数据项（例如cookie和隐藏表单字段），普通用户无法通过浏览器修改
输入处理方法
- 拒绝已知不良输入（最低效）:建立一个输入黑名单（输入的编码方式繁多，输入漏洞在不断更新）
- 接收已知正常输入：建立一个输入白名单（非万能，存在特殊输入）
- 净化：对输入中的恶意字符删除或者编码“转义”
边界确认
边界指的是web应用程序执行数据前第一次处理数据的地方
显然不可能通过一种程序过滤所有的数据输入漏洞，例如防止跨站脚本攻击需要将 > 转化为 HTML编码> ，而防止注入攻击则需要组织包含 & 与 ; 字符的输入。
所以一般设置不同的组件进行恶意数据的筛选处理：
- 首先web应用程序收到登录信息，表单处理程序对每项检查确保符合输入要求，并且不包含任何已知的攻击签名（签名是用于消息的认证，保证该条消息不被伪造。详细了解：https://blog.csdn.net/qq_16645099/article/details/82872751）
- SQL校验，执行查询前对攻击数据库的所有字符进行转义
- 登陆成功后，web应用程序需要将用户的部分数据送到SOAP服务，为防止SOAP注入，需要对XML元字符适当编码
- 为防止跨站点脚本攻击,web应用程序对返回页面中植入的用户数据进行HTML编码
多步确认与规范化
递归执行净化操作，例如下例
// 如果过滤删去<script>,那么剩下的仍然会组合成为<script>
<scr<script>ipt>;
数据规范化：需要对输入数据进行统一字符集编码。
