OWASP Top 10漏洞解析(3)- A3:Injection 注入攻击
作者:gentle_zhou
原文链接:https://bbs.huaweicloud.com/blogs/407990
Web应用程序安全一直是一个重要的话题,它不但关系到网络用户的隐私,财产,而且关系着用户对程序的新人。随着Web应用程序功能持续增加,复杂性不断提高,这些程序也面临着越来越多的安全威胁和挑战。
为了帮助这些应用程序的开发团队和安全人员了解和防范这些威胁,提高安全意识,编写更安全的代码,OWASP(Open Web Application Security Project,开放式Web应用程序安全项目)发布了一份标准指南,称为OWASP Top 10。
这是一份关于Web应用程序安全风险的标准指南,它基于全球范围内的安全专家和数据提供者的共识,列出了当前最严重、最关键的10种Web应用程序安全风险,并提供了相应的防范措施和建议。OWASP Top10 每隔几年会更新一次(目前已经发布了六个版本,分别是2004年、2007年、2010年、2013年、2017年和2021年),最新的版本是在2021年发布的OWASP Top10:2021。
已解析的OWASP漏洞
- OWASP Top 10漏洞解析(1)- A1:Broken Access Control 访问控制失效:https://bbs.huaweicloud.com/blogs/400993
- OWASP Top 10漏洞解析(2)- A2:Cryptographic Failures 加密机制失效:https://bbs.huaweicloud.com/blogs/405125
“注入攻击”缺陷详情
今天,就来为大家讲解其中的第三条缺陷:Injection 注入攻击,它从2017年版本下滑到2021年版本的第三位。
注入攻击是一种网络安全威胁,它利用了应用程序对用户输入的数据没有进行充分的验证,从而导致恶意数据被当作代码来执行产生的漏洞;其目的通常是获取程序内敏感信息、执行非法操作、破坏系统功能或完整性等。注入攻击可以影响各种类型的应用程序,包括Web应用、数据库应用、命令行应用等。
注入攻击的本质是程序内违反了数据与代码分离的原则,即用户输入的数据被拼接到原本要执行的代码中,从而改变了代码的语义或结构。
注入攻击发生的两个关键条件是:
- 用户可以控制输入数据
- 代码拼接了用户输入的数据,并带入程序中去执行
94%的应用程序会被某种类型的注入攻击所测试,一共最高发生27.4万次,其中成功概率最高达19%,平均达3%。这里值得注意的是,一些经典有名的CWE缺陷中,就包括该缺陷,比如CWE-89:Improper Neutralization of Special Elements used in an SQL Command SQL注入攻击,CWE-77 Improper Neutralization of Special Elements used in a Command 命令注入攻击,CWE-79 Improper Neutralization of Input During Web Page Generation 跨网站脚本攻击。
常见的注入攻击缺陷类型
一个应用程序在如下场景下容易被该缺陷攻击:
- 应用程式未验证、过滤或清理用户提供的数据
- 在interpreter解释器中未直接使用上下文感知转义的动态查询或非参数化调用
- Hostile data恶意数据在对象关系映射(ORM)搜索参数中使用,用来提取额外的敏感记录
- Hostile data恶意数据被直接使用或被连接。SQL或命令包含了动态查询、命令或存储过程中的结构和恶意数据。
一些常见的注入攻击包括SQL, NoSQL, OS 命令,对象关系映射(ORM),LDAP,以及表达式语言(EL)或对象图像导航库(OGNL)注入。这个概念在所有的解释器都是相同的。如果应用程序存在注入攻击的弱点,源码检查是最好的方式,强烈建议对所有输入的参数、标头、URL、cookies、JSON、SOAP 以及 XML 的资料进行自动化测试。组织可以将静态源码测试(SAST),动态应用检测(DAST)工具,交互式应用安全测试(IAST),融入到CI/CD流水线中,以达到在上线部署前能识别注入攻击缺陷的目的。
如何防止该缺陷的发生
如何防止该缺陷的发生,也很简单,我们只需要将数据和命令以及查询分割开来:
- 首选项就是使用安全的API,避免完全使用解释器(interpreter),提供一个参数化的界面或则将API融合到对象关系映射(ORM)工具中去。注意:即使已经参数化了,在储存的程序中仍然有可能引入SQL注入攻击,如果用户是通过PL/SQL 或 T-SQL 来连接查询和数据,或则通过使用EXECUTE IMMEDIATE 或 exec() 来执行恶意数据。
- 使用正面的服务端输入验证。这其实不是一个完整的防御,因为许多应用程序需要特殊的字符,比如文本区域或则移动应用程序的API。
- 对于任何有残差的动态查询,使用该解释器的特定转义语法来转义特殊字符。注意:SQL结构(比如表名、列名等)不能转义,因此用户提供的结构名是危险的,这可以说是报告编写软件中常见的问题。
- 在查询中使用LIMIT 以及 其他SQL控制,用来防止遭遇SQL注入攻击时,记录被大量泄露。
举个栗子
场景1
一个应用程序中,使用了下方这样易受攻击的SQL调用构造,并且在其中使用了不受信任的数据:String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";
场景2
类似地,应用程序对其中使用的框架的盲目信任,可能会导致查询容易受到攻击;比如,HQL Hibernate 查询语言:Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
在上面两种情况下,攻击者可以通过修改浏览器中的“id”参数值来发送: ‘UNION SLEEP(10);’. 比如说这样:http://example.com/app/accountView?id=' UNION SELECT SLEEP(10)
这将改变这两个查询原本的含义,将会返回帐户表中的所有记录。更危险的攻击可能会修改或删除数据,甚至调用存储过程。
参考链接
- 点赞
- 收藏
- 关注作者
评论(0)