OWASP TOP10（OWASP TOP10中文手册2020版）

0x01 注入

1.1 威胁代理
​ 考虑任何能够向系统发送不信任数据的人，包括外部用户，内部用户和管理员

1.2 攻击向量
​ 攻击者利用有针对性的解释器语法发送简单的、基于文本的攻击，几乎任何数据源都能成为注入载体，包括内部来源

1.3 安全漏洞
注入漏洞发生在应用程序将不可信的数据发送到解释器时，注入漏洞十分普遍，尤其是在遗留代码中，通常能在 SQL 查询语句、LDAP 查询语句、Xpath 查询语句、OS 命令、XML 解析器、SMTP 头、程序参数中找到，注入漏洞很容易通过审查代码发现，但是不容易在测试中发现，扫描器和模糊测试工具可以帮助攻击者找到这些漏洞

1.4 技术影响
注入能导致数据丢失或数据破坏、缺乏可审计性或是拒绝服务，注入漏洞有时甚至能导致完全主机接管

1.5 业务影响
考虑受影响的数据和运行解释器的平台的商业价值。所有的数据都有可能被偷窃，篡改和删除，会严重损坏企业的声誉。

1.6 漏洞检测
用户提供的数据没有经过应用程序的验证、过滤或净化。
动态查询语句或非参数化的调用，在没有上下文感知转义的情况下被用于解释器。
在ORM搜索参数中使用了恶意数据，这样搜索就获得包含敏感或未授权的数据。
恶意数据直接被使用或链接注入SQL语句或命令在动态查询语句，命令或者存储过程中包含结构和恶意数据。
一些常见的注入，包括：SQL、OS命令、ORM、LDAP和表达式（EL）或OGNL注入。所有的解释器的概念都是相同的。代码审计是最有效的检测应用程序的注入风险方法之一，然后就是对所有参数、字段、头、cookie、JSON和XML数据输入的彻底DAST扫描。组织可以将SAST和DAST工具添加到CI/CD过程中，以便于在生产部署之前对现有或检查的代码进行注入问题的预警。

1.7 漏洞防护
防止注入漏洞需要将数据与命令语句、查询语句分隔开

最佳选择是使用安全的API ，安全避免使用解释器，或提供参数化界面的接口，或迁移到ORM或实体框架。

注意：当参数化是，存储过程仍然可以引入SQL注入，如果PL/SQL或T-SQL将查询和数据连接在一起，或者执行带有立即执行的exec（）恶意数据。

使用正确的或“白名单”的方法，来恰当规范化输入验证的方法，可以有助于防止注入攻击。但是这不是一个完整的防御，因为许多应用程序在输入中需要特殊字符，例如文本区域或者移动应用程序的API。

对于任何剩余的动态查询，可以使用该解释器的特定转义语法转义特殊字符。OWASP的JAVA encoder和类似的库提供了这样的转义教程。

注意:SQL结构，比如：表名，列名等无法转义，因此用户提供的结构名是非常危险的。这是编写软件中的一个常见问题。

在查询中使用LIMIT和其他SQL控件，以防止在SQL注入是大量地泄露记录。

1.8 攻击案例
1.8.1 场景1
应用程序在SQL语句的构造中使用了不可信的数据。

同样的，框架应用的盲目信任，仍然可能导致查询语句的漏洞。（例如：Hibernate查询语言（HQL））

在这两个案例中，攻击者在浏览器中将“id”参数的值修改成：’
or’1’=’1

例如：
http://example.com/app/accountView?id=' or ‘1’=’1
这样查询语句的意义就变成了从accounts表中返回所有的记录。
更危险的攻击可能导致数据被篡改甚至是存储过程被调用。