freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

OWASP Top 10 2017 10项最严重的 Web 应用程序安全风险(一)
2019-02-18 14:50:06
所属地 湖南省

一、前言

不安全的软件正在破坏着我们的金融、医疗、国防、能源和其他重要的基础设施。随着我们的软件变得愈加重要、复杂且相互关联,实现应用程序安全的难度也呈指数级增长。而现代软件开发过程的飞速发展,使得快速、准确地识别软件安全风险变得愈发的重要。我们再也不能忽视像《OWASP Top 10》中所列出的相对简单的安全问题。

在本版本中,我们以可测的方式简明地编写问题和建议,使得《OWASP Top 10》能更适用于企业组织的应用安全计划。我们鼓励大型和高效的组织在需要使用真正标准时能使用《OWASP 应用程序安全验证标准(ASVS)》,但对于大多数组织而言,《OWASP Top 10》是开启应用安全旅程的重要开端。我们已经为《OWASP Top 10》的不同用户编写了一系列建议后续步骤,包括适用于CIO和CISO的“开发人员下一步做什么?”、“安全测试人员下一步做什么?”、“企业组织下一步做什么?”,以及适用于应用程序管理人员或应用程序生命周期负责人的“应用程序管理者下一步做什么?” 。

二、应用程序安全风险

什么是应用程序安全风险?

攻击者可以通过应用程序中许多不同的路径方法去危害您的业务或者企业组织。每种路径方法都代表了一种风险,这些风险可能会,也可能不会严重到值得您去关注。


image.png有时,这些路径方法很容易被发现并利用,但有的则非常困难。同样,所造成的危害有可能无关紧要,也可能导致破产。为了确定您企业的风险,可以结合其产生的技术影响和对企业的业务影响,去评估威胁来源、攻击向量和安全漏洞的可能性。总之,这些因素决定了全部的风险

我有什么风险?

《OWASP Top 10》的重点在于为广大企业组织确定一组最严重的风险。对于其中的每一项风险,我们将使用基于OWASP风险等级排序方法的简单评级方案,提供关于可能性和技术影响方面的普遍信息。

image.png

在这个版本中,我们升级了风险评价系统,以协助我们对可能性和影响进行排名。

Top 10中的风险名称可能将与常见缺陷列表(CWE) 保持一致,采用相同的命名约定,减少混淆。

OWASP Top 10 ——应用安全风险– 2017

A1:2017-注入

将不受信任的数据作为命令或查询的一部分发送到解析器时,会产生诸如SQL注入、NoSQL注入、OS注入和LDAP注入的注入缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执行非预期命令或访问数据。

image.png

应用程序脆弱吗?

当您的应用在如下时点时,是脆弱的并易受到攻击:

• 用户提供的数据没有经过应用程序的验证、过滤或净化。

• 动态查询语句或非参数化的调用,在没有上下文感知转义的情况下,被用于解释器。

• 在ORM搜索参数中使用了恶意数据,这样搜索就获得包含敏感或未授权的数据。

• 恶意数据直接被使用或连接,诸如SQL语句或命令在动态查询语句、命令或存储过程中包含结构和恶意数据。

一些常见的注入,包括:SQL、OS命令、ORM、LDAP和表达式语言(EL)或OGNL注入。所有解释器的概念都是相同的。代码评审是最有效的检测应用程序的注入风险的办法之一,紧随其后的是对所有参数、字段、头、cookie、JSON和XML数据输入的彻底的DAST扫描。组织可以将SAST(https://www.owasp.org/index.php/Source_Code_Analysis_Tools)DAST(https://www.owasp.org/index.php/Source_Code_Analysis_Tools)工具添加到CI/CD过程中,以便于在生产部署之前对现有或新检查的代码进行注入问题的预警。

如何防止?

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

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

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

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

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

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

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

 

攻击案例场景

场景#1:应用程序在下面存在脆弱性的SQL语句的构造中使用不可信数据:

String query = "SELECT * FROM accounts WHERE

custID='" + request.getParameter("id") + "'“;

场景#2:同样的,框架应用的盲目信任,仍然可能导致查询语句的漏洞。(例如:Hibernate查询语言(HQL)):

Query HQLQuery = session.createQuery("FROM accounts

WHERE custID='" + request.getParameter("id") + "'");

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

http://example.com/app/accountView?id=' or '1'='1

这样查询语句的意义就变成了从accounts表中返回所有的记录。更危险的攻击可能导致数据被篡改甚至是存储过程被调用。

相关技能掌握

SQL注入

本实验以PHP和mysql为环境,展示了SQL的发生原理和利用过程,通过显错注入和盲注的对比,更直观展现注入的不同利用方法。

http://www.hetianlab.com/expc.do?ec=ECID172.19.104.182015060916565800001

image.png

A2:2017失效的身份

通常,通过错误使用应用程序的身份认证和会话管理功能,攻击者能够破译密码、密钥或会话令牌,或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。

image.png

应用程序脆弱吗?

确认用户的身份、身份验证和会话管理非常重要,这些措施可用于将恶意的未经身份验证的攻击者与授权用户进行分离。如果您的应用程序存在如下问题,那么可能存在身份验证的脆弱性:

• 允许凭证填充(https://www.owasp.org/index.php/Credential_stuffing),这使得攻击者获得有效用户名和密码的列表。

• 允许暴力破解或其他自动攻击。

• 允许默认的、弱的或众所周知的密码,例如“Password1”或“admin/admin”。

• 使用弱的或失效的验证凭证,忘记密码程序,例如“基于知识的答案”,这是不安全的。

• 使用明文、加密或弱散列密码(参见:A3:2017-敏感数据泄露)。

• 缺少或失效的多因素身份验证。

• 暴露URL中的会话ID(例如URL重写)。

• 在成功登录后不会更新会话ID。

• 不正确地使会话ID失效。当用户不活跃的时候,用户会话或认证令牌(特别是单点登录(SSO)令牌)没有正确注销或失效。

如何防止?

• 在可能的情况下,实现多因素身份验证,以防止自动、凭证填充、暴力破解和被盗凭据再利用攻击。

• 不要使用发送或部署默认的凭证,特别是管理员用户。

• 执行弱密码检查,例如测试新或变更的密码,以纠正“排名前10000个弱密码”(https://github.com/danielmiessler/SecLists/tree/master/Passwords) 列表。

• 将密码长度、复杂性和循环策略与NIST-800-63 B的指导方针的5.1.1章节-记住秘密(https://pages.nist.gov/800-63-3/sp800-63b.html),或其他现代的基于证据的密码策略相一致。

• 确认注册、凭据恢复和API路径,通过对所有输出结果使用相同的消息,用以抵御账户枚举攻击。

• 限制或逐渐延迟失败的登录尝试。记录所有失败信息并在凭据填充、暴力破解或其他攻击被检测时提醒管理员。

• 使用服务器端安全的内置会话管理器,在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中,可以安全地存储和当登出、闲置、绝对超时后使其失效。

攻击案例场景

场景#1凭证填充

(https://www.owasp.org/index.php/Credential_stuffing),使用已知密码(https://github.com/danielmiessler/SecLists)的列表,是常见的攻击。如果应用程序不限制身份验证尝试,则可以将应用程序用作密码oracle,以确定凭证是否有效。

场景#2:大多数身份验证攻击都是由于使用密码作为唯一的因素。依据最佳实践,最新的密码轮换和复杂性要求鼓励用户使用、重用以及重用弱密码。建议组织在NIST-800-63中停止这些实践,并使用多因素身份验证。

场景#3:应用会话超时设置不正确。用户使用公共计算机访问应用程序。用户直接关闭浏览器选项卡就离开,而不是选择“注销”。攻击者一小时后使用同一个浏览器浏览网页,而当前用户状态仍然是经过身份验证的。

相关技能掌握

暴力破解

实验简介:本实验以最简单的一种形式展示暴力破解的原理和利用方法。

(http://www.hetianlab.com/expc.do?ec=ECID172.19.104.182015060917041400001)

image.png未完待续........

 







# 合天智汇
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者