Web 应用程序中的核心防御机制

我们将 Web 应用程序中的核心防御分为三个区域：处理用户访问、处理用户输入和处理攻击者。这些解释如下。

1. 处理用户访问：
第一个任务是根据用户（管理员用户、匿名用户、普通用户）处理访问。大多数 Web 应用程序使用三个相互关联的安全机制（我将其命名为 ASA）来处理访问：身份验证、会话管理和访问控制如下所述。

验证 –
检查用户或匿名用户有效性的用户名和密码机制是基本的一种。现在，还实施了更高级的机制，例如两步验证。所以，黑客总是在检查这些机制是否存在缺陷。暴力破解是最常见的一种。必须对这些输入应用限制和输入验证，以保护应用程序的基本功能。
会话管理——
之后，用户通过了第一步认证，它可能需要管理和提供访问管理，这主要是通过令牌机制来完成的。漏洞的主要领域来自令牌生成方式的缺陷，使攻击者能够猜测颁发给其他用户的令牌，以及令牌处理方式的缺陷，使攻击者能够捕获其他用户的令牌。因此，程序员可以实现令牌有效性时间检查和不易被攻击者猜到的难加密令牌。
访问控制 –
应用程序根据收到的凭据决定访问级别，并且由于这些机制的复杂性，这些机制通常是有缺陷的。开发人员经常使 ?对用户将如何与应用程序交互的假设感到敬畏，并经常通过忽略某些应用程序功能的访问控制检查来进行疏忽。所以，提供适当的机制。

2. 处理用户输入：
大多数缺陷是在应用程序的输入处理中发现的。任何不需要的输入甚至可能导致 SQL 注入导致数据泄露或存储的 XSS 导致令牌松动，并且可能会发生更多攻击并损害您的应用程序。因此，使这些机制变得强大变得非常必要。用户输入可以是用户名、评论、搜索、表单，有时也使用 cookie。

处理用户输入的方法 –
我们无法在输入时猜测用户的想法或方法。因此，我们应该使用方法 will “RKB” 方法，即“拒绝已知错误”。

拒绝已知的坏——
这个方法包含一个黑名单，根据哪些字符被阻止。一般来说，这被认为是验证用户输入的最不有效的方法，主要有两个原因。首先，可以使用各种输入来利用 Web 应用程序中的漏洞，其次，利用技术不断变化。
可以通过以下方式绕过黑名单过滤器：
```
1. If SELECT is blocked, try SeLeCt
2. If or 1=1-- is blocked, try or 2=2--
3. If alert(‘xss’) is blocked, try prompt(‘xss’) 
```
通过在表达式之间使用非标准字符来破坏应用程序执行的标记化，可以绕过旨在阻止特定关键字的过滤器。

例如：
```
SELECT/*foo*/username, password/*foo*/FROM/*foo*/users 
```
NULL 字节绕过示例。
例如：
```
%00alert(1)
```
接受已知良好 (AKG) –
这种方法与“RKB”方法相反，在这种方法中我们不能拒绝错误的输入。相反，我们可以创建一个白名单。因此，应用程序只能接受列出的输入，应用程序拒绝所有其他输入。这种方法比拒绝不良已知方案更安全。
消毒 –
在这种方法中，必须对接收到的数据进行消毒。恶意字符可能会从数据中删除，只留下安全字符，或者在执行进一步处理之前对其进行适当编码或“转义”。例如，通常的跨站点脚本攻击防御是在将危险字符嵌入到应用程序页面之前对其进行 HTML 编码。但如果攻击者了解清理机制，则可能会绕过它。
安全数据处理 –
大多数 Web 应用程序漏洞的出现是因为用户提供的数据是以不安全的方式处理的。通常可以忽略漏洞，而不是通过验证输入本身，而是通过确保对其执行的处理是安全的。在某些情况下，可以使用安全的编程方法来避免常见问题。例如，可以通过正确使用参数化查询进行数据库访问来防止 SQL 注入攻击。
语义检查——
但是，对于某些漏洞，攻击者提供的输入类似于普通非恶意用户可能提交的输入。使它变得恶意的是它提交的不同情况。例如，攻击者可能试图通过更改在隐藏表单字段中传输的帐号来访问其他用户的银行帐户。再多的语法验证也无法区分用户的数据和攻击者的数据。为了避免未经授权的访问，应用程序需要验证提交的帐号是否属于提交它的用户。
多步验证 –
这些天我们都在使用许多安全服务，例如 gmail 等，它为我们提供了两步验证，也可以说是多步验证。但所有这些验证都是为了用户身份而不是数据验证。

3. 处理攻击者：
我们在处理错误时必须考虑以下几点：处理错误、维护审计日志、警告管理员和应对攻击解释如下。

处理错误——
短期内，攻击者首先尝试收集有关应用程序的信息。因此，应用程序中的所有错误机制不得提供任何描述性，即不得泄露有关数据库、系统架构或路径详细信息等的任何信息。
维持审计——
审计日志在调查此类事件时很重要，有效的审计日志应该使应用程序的所有者能够准确了解发生了什么、利用了哪些漏洞、攻击者是否获得了对数据的不必要访问或执行了任何未经授权的操作，以及，到目前为止尽可能提供入侵者身份的证据。
与身份验证功能、密钥事务、包含表明明显恶意意图的已知攻击字符串的任何请求相关的所有事件。
警报管理 –
可能有一些机制可以提醒应用程序的管理员，应用程序中的任何异常活动，例如来自特定 IP 的高 ping 请求。
对攻击做出反应——
许多对安全至关重要的应用程序都包含内置机制，可以对被识别为潜在恶意的用户进行防御性反应。因为大多数应用程序都是不同的，攻击者必须执行不同的测试才能找到漏洞，我们会将其中许多请求识别为潜在的恶意请求并阻止它们。出于这个原因，一些 Web 应用程序会采取自动反应措施来挫败以这种方式工作的攻击者。例如，他们可能会越来越慢地响应攻击者的请求或终止攻击者的会话，要求他在继续攻击之前登录或执行其他步骤。