我们节省时间就从 “核心防御机制” 开始说起：
web应用程序采用的 防御机制 由一下几个核心因素组成：
* 处理 用户访问应用程序的数据和功能，防止用户获得未授权访问
*处理 用户对应用程序功能的输入 防止错误输入造成不良行为。
*防范攻击者，确保程序受攻击时也能正常运转，并采取适当的防御和攻击回应攻击者
*管理应用程序本身，帮助管理员监控其行为，配置其功能
2.1处理用户访问：
1、任何程序都必须满足 处理用户访问他的数据和功能。
2、用户分三类：匿名用户、正常通过验证的用户、管理员。
3、web应用程序使用三层相互关联的 安全机制 处理用户访问：
*身份验证 *会话管理 *访问控制
2.11 身份验证
1、验证用户是指确定用户真实身份。 若不采用应用程序会把所有用户当做匿名用户
2、身份验证机制存在大量缺陷： 攻击者确定某人的用户名，进而推测出他们的密码 、 利用逻辑缺陷避开登录功能
2.12 会话管理（以我的理解叫相当与session）
处理用户访问（处理登录等功能）的下一项逻辑任务是通过验证用户的会话。
成功登录之后，用户会访问各种页面于功能。从浏览器提出一系列HTTP请求。与此同时，应用程序还会时候偶到各类用户发出的请求。为了实施有效地访问控制，应用程序要识别每一名用户提交的各种请求。
为了满足这些要求，几乎所有web应用都会为每位用户建立一个会话（一组保存在服务器上的数据结构），并向用户发布一个识别会话的令牌（session ID）。会话用于追踪用户与应用程序的交互状态。session把id号存在cookie中如果用户在一段时间内没有发送请求cookie销毁session Id 找不到，会话自动销毁。
针对会话的攻击： 会话机制有效性基本取决于令牌的安全性。 攻击者攻破其他用户令牌，然后伪装成被攻破的用户，此时就可以伪装成通过验证的用户做一些列操作。 漏洞的来源：令牌生成过程中存在的缺陷，这个缺陷能让攻击者推测出发给其他用户的令牌；根据这个缺陷截获其他用户的令牌。详细攻击请看：https://blog.csdn.net/blood_pupil/article/details/89202326
2.1.3 访问控制
处理用户访问的最后一个逻辑步骤是做出正确决策（决定允许或拒绝每一个请求）。若之前的机制正常运行，应用程序就可收到一个个请求来最终确定用户身份。在这个基础之上，应用程序需要决定是否授权用户执行请求的操作或访问数据。
访问控制机制要根据不同领域的特点，针对不同身份的登陆者给予权限。
典型的访问控制很复杂，因此这种机制存在大量安全漏洞，是的攻击者能对应用程序的数据和功能进行未授权访问。探查这些漏洞：对每一项功能重复进行相同检查，很费力（第八章讲访问控制测试）
2.2处理用户输入
攻击者会针对输入和提交进行不同的攻击，所以用户输入都不可信。因此，能够安全输入是对应用程序安全防御的一个关键要求。
2.2.1输入的多样性
在许多情况下，应用程序会对特殊的输入实行非常严格的检查，例如：登录功能提交的用户名智能包含字母且最大长度8个字符。
在其他情况下，应用程序必须接受广泛的输入。例如：提交给个人信页面的 地址字段 可合法包含字母，数字，空格，连字符，撇号等其他字符。但仍可以对这个字段实施有效限制（限制长度，不得包含任何HTML标记）。
有些时候需要接受任意输入：比如有些写关于安全的博客，看似危险但是不能拒绝该输入
2.2.2输入处理方法
1、"拒绝已知的不良输入"：设置黑名单（其中包括在空集中使用的一直的字符串或者模式）拒绝黑名单匹配数据，接受其他数据。
这种方法是确认用户输入效率最低的方式。两方面原因：1、攻击者可以通过一系列输入对典型Web应用程序中存在的漏洞加以利用，这种输入可通过各种方式进行编码或者表现为不同的形式。2、黑名单无法防止更多新型的攻击模式。 解决方案
*****：比如 如果SELECT被阻止，尝试SeLeCt ; 如果or 1 = 1 --被阻止，且尝试 or 2=2--；
*********在其他情况下，通过表达式之间使用非标准字符应用程序执行的令牌，可以避开旨在阻止特定关键字的过滤。例如：SELECT/*foo*/username,password/*foo*/FROM/*foo*/users <img%09οnerrοr=alert(1) src=a>
*********最后，各种基于黑名单的过滤，特别是那些有web应用程序防火墙执行的过滤，都容易收到空字节攻击。由于托管和非托情况下处理字符串的方式各不相同，在阻止表达式之前任意位置插入"空格",过滤器停止处理。（18张介绍各种攻击Web应用程序防火墙的其他技巧）
2、"接受已知的正常输入"：使用白名单（接受与白名单匹配的数据，拒绝其他数据）
这种方法是处理潜在恶意输入最有效的方式。然而在有些时候，应用程序必须接受并不满足任何已知"正常"标准的数据，并进行处理例如：有些人的姓名中包含撇号和连字符的情况，这些数据可用于对数据库发动攻击。所以白名单不是万能的方法。
3、净化：需要接受无法保证其安全的数据，然后对其中可能存在的恶意字符删除留下安全字符，或者在进一步处理之前进行适当的编码“转义”
基于数据净化的方法一般是非常有效地，许多情况下可作为处理恶意输入问题的通用解决办法。然而，如果需要在一个输入项中容纳集中可能的恶意数据，这是就很难进行进化，这时最好采用边界确认方法。
4、安全数据处理：不需要确认输入本身，只需确保处理过程绝对安全，即可避免漏洞。有时可使用安全的编程方法避免常见的问题。例如：在数据库访问过程中正确使用参数化查询就可以避免SQL注入攻击。
这种方法不适于Web程序要执行的每个任务。
5、语法检查
2.23 边界确认（我认为就是一次输入就是一道坎）
边界确认，是一种更加有效地模型。这个模型之中会把每个 web应用程序或者逻辑单元的输入，当做来自潜在恶意来源的输入对待。出了下述客户端和服务器之间的信任边界外，还要在每个可以输入数据的web应用程序或者逻辑单元执行数据确认。因为在不同的处理阶段执行不同的确认检查，他们之间不可能发生冲突。
用户提交的数据不可信是造成Web应用程序核心安全问题的主要原因。即使经过输入确认检查，提高了性能和用户体验，但不能为到达服务器的数据的安全有任何的保证。
服务器应用程序第一次收到用户数据的地方是一个重要的信任边界（服务器端就收的第一个程序，这是个边界，经过这个程序之后的数据，也就是经过这个信任边界之后的数据都是可信任的），应用程序需要在此采取措施防御恶意输入。
具体操作是，在因特网（"不良"且不可信）传递出来的数据经过"净化"后转为“洁净”的数据交给服务器端应用程序（“正常”且可信任）。这个过程之后的数据就是可信的数据。