Owasp top 10 最新排名

最新的2021 top 10已经出来了，我们从A01开始进行一次详细解读，本系列会详细介绍各个漏洞的变化与内容，并会着重介绍新增的漏洞情况。

因素

概述

注射滑落到第三个位置。94%的申请对某种形式的注射进行了测试，最大发生率为19%，平均发生率为3%，共274k次。值得注意的共同弱点列举（CWE）包括CWE-79：跨站点脚本,CWE-89:SQL注入，和CWE-73：文件名或路径的外部控制.

说明

应用程序在以下情况下易受攻击：

• 用户提供的数据未被验证、筛选或清除应用程序。

• 没有上下文感知的动态查询或非参数化调用转义直接在解释器中使用。

• 恶意数据用于对象关系映射（ORM）搜索用于提取其他敏感记录的参数。

• 恶意数据被直接使用或连接。SQL或命令包含动态查询中的结构和恶意数据，命令或存储过程。

一些更常见的注入是SQL、NoSQL、OS命令、Object关系映射（ORM）、LDAP和表达式语言（EL）或对象图形导航库（OGNL）注入。概念是相同的在所有口译员中。源代码审查是检测应用程序是否容易被注入。自动化测试所有参数、头、URL、cookies、JSON、SOAP和XML大力鼓励数据输入。组织可以包括将静态（SAST）、动态（DAST）和交互式（IAST）应用程序安全测试工具放入CI/CD中生产前识别引入的注入缺陷的管道部署。

如何预防

防止注入需要将数据与命令和查询分开：

• 首选的选择是使用安全的API，这样可以避免使用完全解释器，提供参数化接口，或迁移到对象关系映射工具（ORMs）。
  注：即使是参数化的，存储过程仍然可以引入SQL注入，如果PL/SQL或T-SQL连接查询和数据或使用EXECUTE IMMEDIATE或exec（）执行恶意数据。

• 使用积极的服务器端输入验证。这是不是一个完整的防御，因为许多应用程序需要特殊的字符，例如用于移动应用程序的文本区域或api。

• 对于任何剩余的动态查询，请使用该解释器的特定转义语法。
  注：SQL结构，如表名、列名等无法转义，因此用户提供的结构名称是危险。这是报表编写软件中常见的问题。

• 在查询中使用LIMIT和其他SQL控件来防止大量在SQL注入的情况下披露记录。

攻击场景示例

场景1：应用程序在构造中使用不受信任的数据以下易受攻击的SQL调用：

String query=“SELECT \*FROM accounts WHERE custID='”+请求。getParameter（“id”）+“'”；

场景2：同样，应用程序对框架的盲目信任可能会导致仍然易受攻击的查询（例如Hibernate查询语言（HQL）：

Query HQLQuery=会话。createQuery（“FROM accounts WHERE custID='”+request.getParameter（“id”）+“'”）；

在这两种情况下，攻击者都会修改要发送的浏览器：“或”1“=”1。例如：

http://example.com/app/accountView？id='或'1'='1

这将更改两个查询的含义，以从中返回所有记录accounts表。更危险的攻击可能会修改或删除数据甚至调用存储过程。

注入漏洞（不仅仅是SQL注入）

现在的注入漏洞和之前有了很大的区别，我记的最开始的top 10中 首当其冲的是SQL 注入漏洞，但现在的注入漏洞省略了SQL，变的更加广泛，这也和代码安全做的越来越好有关系，总有一些安全的文章说SQL注入走向了死亡，但注入漏洞并不仅仅的指定为SQL注入了，现在更加全面了，只要是存在注入行为的漏洞都可以被包含进去了。如下图展示（自己临时总结有不充分的点，欢迎大佬指正完善。）

在接下的时间里我们来聊一下（这是敏感词）注入的通用内容：

真的是过分，我是聊注入，不是下猪

Bypass

注入作为常见的也是影响很大的漏洞类型之一，项目多多少少会添加一些过滤或者部署WAF来进行防御，这样可以有效的把攻击者的恶意内容阻挡在大门之外。而在渗透测试的过程中就要针对性的BYPASS。

针对关键字绕过

有一定安全意识的项目会编写一些规则或基于字符串匹配对于用户输入的命令进行过滤，这种内容有很多我们是可以找到源码的，毕竟开发最喜欢的就是借鉴（读书人的事怎么能叫抄呢）比如这样的特殊符号过滤。我们外全可以利用编码和寻找到的遗漏来进行绕过

if(informationForm.name.value==""){
		alert("请填写名称！");		
		informationForm.name.focus();
		return false;
	}else{
		reg=/[`[email protected]#$%^&*()_+<>?:"{},.\/;'[\]]/im;
		if(reg.test(informationForm.name.value)){
			alert("提示：您输入的信息含有非法字符！");
			informationForm.name.focus();
			return false;
		}
	}

这里还有可能是针对某些命令进行的过滤，那么我们就可以找同类型的命令进行绕过

比如目标对XSS中常用的alert进行了过滤那么我们完可以使用prompt confirm来进行。同理针对注入和命令执行时也可以用同样的方法比如cat 和more、less等。

我们可以总结一下对于关键字防御方法的绕过方法

• 同义命令替换绕过
• 注释绕过
• 编码绕过
• 关键字拼接绕过
• 特殊符号绕过
• 管道线过
• 特殊变量绕过
• 并行绕过
• 隐藏关键字绕过
• 通过第三方绕过
• 文件包含方式绕过
• 等

当然这肯定不是最全的，希望大家可以帮助我多补充

针对命令长度绕过

相对于关键字的封锁来说，对于命令长度的限制，我觉的难度会更高，也更加恶心人，因为你可以确认这个点存在问题但就是无法执行部分攻击语句。反观之关键字的封锁，我只要找到了入口点绕过成功就很容易了。

<?php
show_source(__FILE__);
error_reporting(0);
$cmd = $_GET['cmd'];
echo '<br>'.strlen($cmd)'<br>';
if(isset($cmd) && (strlen($cmd)<=10))
{
	@exec($cmd);
}
echo $_SERVER['SERVER_ADDR'];
?>

些代码限定了传入的数据只能10位，那我们在执行一些东西的时候就很难受了。这里我们可以进行的绕过方式就有文件写入绕过，文件调用绕过等，通过利用其他文件来进行执行，我们执行的只是执行一个文件，就相对来说可控了。

我们继续总结一下对于长度限制的绕过方法

• 引用外部文件绕过
• 引用内部文件绕过
• 超短链绕过
• 多参数绕过
• 等

关于这个我现在想到的内容就这几个，欢迎补充

总结

现在的注入漏洞从内容上来看变的更加广泛，影响也是从低到高的雨露均沾。但不可否认的是现在大量的0Day还是以注入漏洞为主，效果也最直观。所以大家还是要把这个漏洞重视起来，多加以利用。