Web Application核心防御机制是什么

今天就跟大家聊聊有关Web Application核心防御机制是什么，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

为防止恶意输入，应用程序实施了大量的安全机制，而这些安全机制在概念上都具有相似性。

这些安全机制由以下几个方面组成：

1、处理用户访问web应用程序的数据与功能（防止未授权访问）

2、处理用户对web应用程序功能输入的数据（防止构造恶意数据）

3、应对攻击（处理预料外的报错、自动阻止明显的攻击、自动向管理员发送警报、维护程序的访问日志）

4、管理与维护应用程序

处理访问

通常一个应用程序的用户有不同类型如，普通用户、登录验证用户、管理员。对不同用户web应用程序给予不同的权限，他们只能访问不同的数据与功能。

web应用程序是通过三层互相关联的安全机制来处理用户的访问：

1、身份验证（Authentication）

2、会话管理（Session Management）

3、访问控制（Access Control）

这三个机制处理用户对应用程序的访问，同时它也是三个受攻击面（attack surface）；而且这三者相互依赖缺一不可，无论哪个地方出了问题都会造成未授权访问（木桶原理）。

身份验证

身份验证是处理用户访问的第一道机制，除非网站只有一种用户，否则必须使用身份验证。

如今web应用程序大都使用传统身份验证模型，即用户名密码。

在银行等安全性较高的应用程序中会使用其他证书、双因素认证等来强化这个模型；在安全性要求更高的应用程序中可能需要客户端证书、智能卡或询问-应答机制等其他身份验证模型。

身份验证机制往往还需要一系列其他支持功能，如注册、忘记密码、修改密码等。

身份验证机制存在一些普遍的漏洞，如遍历用户名、弱口令、逻辑缺陷避开登录、社工库查询等等。

会话管理

通过验证之后，就是管理用户的会话了。为了实施访问控制，应用程序需要识别不同用户提交的各种请求；为此，应用程序需要为每个用户建立一个会话，并向用户发送一个表示会话的令牌即session token。会话本身是保存在服务器上的一组数据结构，用于追踪用户和应用程序的交互状态。

会话令牌一般在cookie中传递，有时也会出现在隐藏表单字段或者url查询字符串上，会话令牌会在停止请求后一段时间内失效。

有些应用程序不使用会话令牌来识别会话，而是通过反复提交用户证书识别会话（http内置身份验证机制就是这样，通过反复提交通过base64加密的账号密码来识别会话）。在一些情况下会话信息不保存在服务器上，而是保存在客户端，为了防止用户修改，一般会对其进行加密。

会话管理的受攻击面就是会话令牌本身，推测出会话令牌的生成规则或者截获到其他用户的会话令牌便可以以他人身份访问未经授权的功能与数据。

访问控制

如果前面的身份验证与会话管理运行正常，应用程序便可以通过每个请求中的会话令牌确认每个用户的身份与交互状态，于是便可决定是否同意用户的请求。

因为典型访问控制的要求比较复杂，每个角色有不同的权限，每个用户只允许访问应用程序中的一部分数据与功能，因此这个机制中一般存在大量漏洞，可以造成未授权访问。

处理输入

所有的用户输入都不可信，大部分对web应用程序的攻击都与攻击者专门构造的输入有关，所以安全的处理用户的输入是保障应用程序安全的关键。

输入的多样性

web应用程序可能对一些特殊的输入执行非常严格的检查，例如长度限制、字符限制等；有时候则可能需要接受用户提交的任意输入；而隐藏表单字段和cookie等是在服务器上生成传回客户端，再由用户的请求传回服务器，在这个过程中攻击者却可以查看并修改它们。

输入处理方法

不同的情况使用不同的处理方法，或者搭配使用。

1、黑名单

黑名单包含一组在攻击中会使用的字符串或模式，所有与黑名单匹配的数据都会阻止。

黑名单是输入确认效果最差的方法。原因有二：

1）用户的输入可以通过各种编码或者其他的表现形式进行绕过，比如遗漏一些有相同作用的字符。例如alert('xss')被阻止,还可以使用prompt('xss')、例如web应用防火墙常受到空字节（null）攻击，这是因为在托管与非托管情况下处理字符串的方式不同。

2）术飞速的发展，使之产生一些新型的漏洞利用方法。

2、白名单

白名单包含一组良性的字符串、模式或一组标准。所有不与白名单匹配的数据都会被阻止。

白名单是输入确认效果最好的方法，因为指定白名单时只会留下安全的字符串，攻击者无法构造输入。

但是白名单具有局限性。在许多情况下web应用程序必须接受一些不符合安全标准的字符，例如应用程序需要用户以真实姓名注册，但是姓名中却包含一些连字符、撇号等可能对数据库造成攻击的字符。所以白名单具有局限性，并非解决不安全输入的万能方法。

3、净化

这种方式解决了白名单无法处理的部分，它接受一些无法保证安全的数据输入，但是会对其进行净化，例如删除、转义、编码等

净化可以作为一种通用的方法，但是需要注意的是如果一个输入项中需要容纳几种可能的恶意数据，就很能对其进行有效的进化。这时需要使用边界确认。

4、安全数据处理

以不安全的方式处理用户提交的数据，是许多web应用程序漏洞形成的根本原因。

安全的数据处理方式，不需要纠结于对用户输入数据的确认，转而确保处理过程的绝对安全。例如防止sql注入的参数化查询。

但是这项方法不适用于web应用程序需要执行的每一项任务，如果适用，它就是处理恶意输入的通用处理方法了。

5、逻辑检查

在一些漏洞中攻击者与正常用户的输入完全相同，仅仅是动机不同，在这种情况下，以上机制几乎完全无效。例如攻击这通过修改隐藏表单字段提交的账号，企图访问其他用户账号。此时再多的输入确认也无法区别攻击者与正常用户的数据。为防止未授权访问，应用程序必须确认所提交账号属于之前提交该账号的用户。

边界确认

鉴于核心安全问题的本质（所有用户输入皆不可信），可以将因特网（不可信）与服务器应用程序（可信）之间作为边界，然后在边界净化所有来自因特网的输入，将净化后的数据交给服务器应用程序。以上，是一种简单的边界确认，在分析实际的漏洞时发现执行这种简单的输入确认是不够的。

基于应用程序执行功能的广泛性及其采用技术的多样性，一个典型的应用程序需要防御大量的各种各样的输入攻击，每种攻击可能采用一种截然不同的专门设计的数据，因此很难在外部边界建立一个简单的机制防御所有的攻击。

许多应用程序功能都设计组合一系列不同的处理过程，用户的一个输入，可能在许多组件中执行许多操作，其中前一个操作的输出结果被用于后一个操作。数据经过转换后与原始输入完全不同。而经验丰富的攻击者却能利用这种不同，在关键步骤生成恶意数据，攻击接受数据的组件。因此很难在外部边界建立一个简单的机制防御所有的攻击。

边界确认是一种更加有效的模型。这里的边界不在局限于因特网与web应用程序之间的边界，web应用程序的每个组件或功能单元都有边界。如此，每个组件都可以防御它收到的特殊类型的专门设计的输入。当数据通过不同的组件，即可对前面生成的数据执行确认检查，而且由于不同的处理阶段执行不同的确认检查，它们之间不可能发生冲突。

例如下图：

多步确认与规范化

在确认检查过程中，当需要在几个步骤中处理用户的输入时，就会出现一个输入机制经常遇到的问题。当应用程序试图通过删除或者编码某些字符达到净化用户输入时，就会出现这种问题。如果不谨慎处理这个问题，攻击者就能构造专门的输入，使恶意数据成功避开确认机制。例如双写绕过、利用步骤执行顺序绕过。

数据规范化会造成另一个问题。为了通过http传送一些不常见的字符和二进制数据，通常会通过编码对其进行规范化，但是如何在实施过滤之后才进行解码，攻击者就可以通过编码避开确认机制。

除了供web应用程序使用的标准编码方案外，其他情况下，如果应用程序的组件将数据从一个字符集转换为另一个字符集，这也会导致规范化问题。例如Ÿ和Â则被转换为Y和A，攻击者经常使用这种方法传送受阻止的字符和关键字。

有时候很难避免多步确认和规范化造成的问题，也不存在解决和这类问题的唯一方案。如何可能一般避免净化不良输入，而是完全拒绝这种输入。

应对攻击

以上我们已经尽可能的阻止了攻击者的入侵，但是没有一个绝对安全的系统，若发生安全事件web应用程序应当如何应对攻击呢，处理措施一般为以下几条：

1、处理预料外的报错

2、自动阻止明显的攻击

3、自动向管理员发送警报

4、维护程序的访问日志

处理错误

应用程序的一个关键机制就是如何处理意料之外的错误。一般在生产环境下，应用程序不应该向用户返回任何系统生成的信息或者其他调试信息。这些信息对于攻击者而言是为下一步的进攻提供了很好的参考信息。而且意料之外的错误往往指明了程序的防御机制中的一些缺陷。错误处理机制通常与日志机制整合在一起。

应对攻击

很多攻击都会发送大量的常见恶意字符，遇到这类情况应用程序应采取自动反应措施阻止攻击者的探查。例如终止会话、要求重新登录、禁止ip等等

维护日志

日志会对入侵情况进行记录，入侵过后仍能还原入侵过程。

重要的应用程序日志应记录所有请求。一般情况下应至少包括一下几项：

1、所有与身份验证相关的事件，如成功或失败的登录、密码修改

2、关键操作，如转账等

3、被访问控制阻止的请求

4、包含已知攻击字符串

日志会记录每个事件的时间、ip、用户账户。日志需要严格保护，避免未授权的读取。写入，修改等等

日志同样也会成为一个攻击面，例如可以未授权访问的日志会为攻击者提供会话令牌、请求参数等等敏感信息。

向管理员发出警报

核心问题就是误报和漏报，将警报机制与确认机制和其他控制方法结合起来可以得到一些改善。

一般而言监控到的反常事件包括以下几种：

1、应用反常，如接收到一个ip的大量的请求

2、交易反常，如一个银行账户所转入转出的资金数量出现异常

3、包含已知攻击字符串

4、请求中普通用户无法查看的数据被修改

管理应用程序

管理程序可以帮助管理员管理用户账户与角色、应用监控与审计功能、执行诊断任务并配置应用程序的各种功能。

管理机制是应用程序主要受攻击面之一，管理机制往往都拥有很高的权限。获得了管理机制控制权，就是获得了应用程序的控制权。而且管理机制中往往会存在一些比较明显的漏洞和敏感的功能。获得管理员的权限的漏洞一般出现在处理用户访问机制上，如未授权访问、弱口令等，如果管理后台可以处理普通用户发送的请求，可以尝试xss漏洞盲打后台。

看完上述内容，你们对Web Application核心防御机制是什么有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注行业资讯频道，感谢大家的支持。