Web安全防护体系

1.Web安全核心问题

安全的核心问题是：用户可以提交任意输入，但从安全角度而言，用户所有输入均不可信。

1）用户侧可直接修改浏览器与服务器间传送的数据结构及内容。其中包括请求参数、Cookie内容和http消息头等方面。可轻易避开客户端执行的任何安全检测脚本，如各类型验证。

2）用户侧可在任意环节及功能上多次重复提交，并且服务器均会对重复提交的内容按照同一种逻辑进行处理，这样给攻击者实现爆破攻击的机会。

3）用户侧可利用浏览器、相关插件、攻击组件等多重方式对服务器进行探测，并且服务器没有有效手段控制用户侧所采用的工具类型。

4）部分业务逻辑依靠用户输入的参数进行业务开展，如显示用户名、用户自有信息等，从而增加了用户与系统的交互点。

2.实际问题的客观引发因素

1）不健全的安全开发体系。

2）开发周期的缩短及功能频繁变更。

3）开发人员的不稳定性。

4）运维人员的安全意识不足。

3.建立基本的安全框架

攻击者会利用各种具有服务器交互的业务功能进行各类攻击尝试，这也是Web漏洞存在的基本特点。因此在安全框架设计上，需重点关注Web应用与用户交互的方式及对应的业务流程。而且，要设计合理的用户交互规范，并对任何不应被信任的数据进行统一的过滤。

3.1 处理用户交互权限

在这个过程中，要具备完整的用户访问行为处理与过滤功能。通常情况下，可根据用户的交互行为进行分类，同时结合用户的身份权限进行综合处理，如常见的匿名用户、正常通过验证的用户和管理用户权限。许多情况下，不同用户只允许访问不同的数据，例如各类用户隐私数据、订单信息等内容。

目前，主流的Web应用使用三层相互关联的安全机制来处理用户访问。

（1）用户身份验证方式

身份验证机制是Web应用识别用户身份的基本机制，如用户登录功能、利用OAuth授权功能等。在这个过程中，Web应用会重点验证用户的真实身份。如果不采用这类机制，应用程序应将所有用户作为匿名用户对待。目前，大多数Web应用程序采用标准的身份验证模型，即要求用户提交用户名和密码，再由应用程序对其进行核实，确认其合法性。

（2）用户会话管理

当用户通过了Web应用的身份验证方式后，用户可访问当前Web应用并使用对应的功能。在这个过程中，Web应用会收到不同用户发出的访问请求。这期间Web应用需识别并处理每一名用户提交的各种请求，并根据用户的身份权限实施有效的访问控制，实现管理用户的会话的功能。

为了实现用户会话管理功能(跟踪用户并保持用户信息的技术)，Web应用在用户身份验证通过后会为每一个用户建立一个独立的Session，并向用户生成一个具有标识功能的令牌。Session本身是一组保存在服务器上的数据结构，用于追踪用户与Web应用的交互状态。这个过程中，Web应用会利用Cookie与Session机制来实现上述功能。

（3）用户访问行为控制

Web应用需要对每个用户访问的访问请求做出响应。当前两个安全机制运作正常时，Web应用在接收到用户请求后会根据当前用户的身份状态及权限以及业务流程要求来决定响应或拒绝当前的请求。在此基础上，应用程序需要决定是否授权用户执行其所请求的操作或访问相关数据。

3.2处理用户输入参数

在用户输入参数的处理方面，有以下几个方式可供选择：

（1）利用黑名单过滤用户非法输入参数

Web应用会使用一个黑名单来对用户输入的参数进行过滤。黑名单中包含一组在攻击中使用过的已知的字符串或特征。Web应用需阻止任何与黑名单匹配的数据进入，并对不符合黑名单的用户输入参数进行处理。

（2）利用白名单校验用户参数是否为正常输入参数

白名单是一种非常好的用户参数规范校验机制，相对于黑名单来说其过滤效果更加严格。因此适用于各类对参数格式及内容有着明确要求的业务场景。Web应用会将接收到的用户参数与白名单定义的规范进行匹配，并在匹配成功后执行后续业务流程。

（3）使用安全的数据方式

以不安全的方式处理用户提交的数据，容易造成Web应用错误地将用户输入参数作为代码执行，是许多Web应用程序漏洞形成的根本原因。在这种状况下，通常不需要确认输入本身的合法性，只要确保处理过程绝对安全，即可避免出现各类漏洞。例如，在数据库访问过程中使用参数化查询方式，即可避免绝大部分SQL注入攻击。

（4）用户行为参数检查

在一些业务流程漏洞中，攻击者提交的输入参数与普通的非恶意用户提交的输入参数完全相同，这就会导致上述三种防护手段均会失效。这类行为是因为攻击者提交参数时的目的不同。例如，攻击者可能会修改Web页面隐藏表单字段提交的参数，如订单编号，企图利用修改订单编号来实现访问行为越权。

因此，要在后台对用户的输入参数根据业务要求进行二次校验，方可避免这类问题的出现。

3.3确认用户应用边界

仅利用JS脚本来检查用户输入内容完全无法保证到达服务器的数据一定符合要求。服务器端应用程序第一次收到用户数据的地方是一个重要的信任边界，应用程序需要在此采取措施防御恶意输入。

边界确认是一种更加有效的模型。此时，服务器端应用程序的每一个单独组件或功能应将用户输入参数当作潜在的恶意来源。除客户端与服务器之间的外部边界外，Web应用程序在上述每一个信任边界上执行数据合法性确认。

3.4处理流程规范化

在确认检查过程中，当需要在几个步骤中处理用户提交的输入时，就会出现一个输入处理机制经常遇到的问题，即如何确认用户数的参数完全合法。如果不谨慎处理该过程，攻击者就能寻找到有效的绕过方式，使得恶意数据成功避开Web应用的防护机制。例如，Web应用试图通过删除用户输入参数中的某些非法字符或表达式来过滤用户输入参数时，就会出现这种问题。

以防御某些跨站点脚本攻击的方法为例，应用程序可能会从任何用户提交的数据中删除表达式：

---

<script>

---

但攻击者可应用以下输入避开过滤器：

---

<scr<script>ipt>

数据规范化会造成另外一个问题。当用户浏览器发起HTTP请求时，浏览器会将请求中的用户参数进行各种形式的编码。HTTP协议之所以使用URL编码等方案，是为了能够通过HTTP协议传送不常见的字符与二进制数据。在这个过程中，Web应用需提前将这类编码数据进行规范的转换。如果在对用户参数过滤之后再执行编码转换，攻击者就可以通过使用编码方式避开现有的防护机制。

安全开发流程的核心思想是：在遵循系统功能要求的基础上，需在系统内部链接、外部传参点等各个环节中，实现标准化的防护方式及业务流程。重点在于系统交互功能的设计上。这样可在开发阶段降低各类安全风险，一方面可保证系统的稳定运行，另一方面也可减少安全防护的资金投入。