自学网络安全(白帽黑客)必看!OWASP十大漏洞解析!

在学习网络安全之前,需要总体了解安全趋势和常见的Web漏洞,在这里我首推了解OWASP,因为它代表着业内Web安全漏洞的趋势;

目录

一、OWASP简介

OWASP Top 10: 2013版至2017版改变了哪些内容

二、OWASP Top 10

A1:注入漏洞

A2:失效的身份认证

A3:敏感数据泄露

A4:XML 外部实体漏洞(XXE)

A5:失效的访问控制

A6:安全配置错误漏洞

A7:跨站脚本漏洞(XSS)

A8:不安全的反序列化漏洞

A9:使用含有已知漏洞的组件

A10:不足的日志记录和监控

三、风险因素总结

一、OWASP简介

OWASP(开放式web应用程序安全项目)关注web应用程序的安全。OWASP这个项目最有名的,也许就是它的"十大安全隐患列表"。

这个列表不但总结了web应用程序最可能、最常见、最危险的十大安全隐患,还包括了如何消除这些隐患的建议。(另外,OWASP还有一些辅助项目和指南来帮助IT公司和开发团队来规范应用程序开发流程和测试流程,提高web产品的安全性。)

这个"十大"差不多每隔三年更新一次。

OWASP Top 10改变了哪些内容

在过去的几年中,应用程序的基础技术和结构发生了重大变化:

  • 使用node.js和Spring Boot构建的微服务正在取代传统的单任务应用,微服务本身具有自己的安全挑战,包括微服务间互信、容器 工具、保密管理等等。原来没人期望代码要实现基于互联网的房屋,而现在这些代码就在API或RESTful服务的后面,提供给移动 应用或单页应用(SPA)的大量使用。代码构建时的假设,如受信任的调用等等,再也不存在了。
  • 使用JavaScript框架(如:Angular和React)编写的单页应用程序,允许创建高度模块化的前端用户体验;原来交付服务器端处理 的功能现在变为由客户端处理,但也带来了安全挑战。
  • JavaScript成为网页上最基本的语言。Node.js运行在服务器端,采用现代网页框架的Bootstrap、Electron、Angular和React则运 行在客户端。

二、OWASP Top 10

A1:注入漏洞

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

知识点简介

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

案例场景

  • 场景#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表中返回所有的记录。更危险的攻击可能导致数据被篡改甚至是存储过程被调用。

如何防止?

  • 防止注入漏洞需要将数据与命令语句、查询语句分隔开来。
  • 最佳选择是使用安全的API,完全避免使用解释器,或提供参数化界面的接口,或迁移到ORM或实体框架。
  • 注意:当参数化时,存储过程仍然可以引入SQL注入,如果PL/SQL或T-SQL将查询和数据连接在一起,或者执行带有立即执行或exec()的恶意数据。
  • 使用正确的或“白名单”的具有恰当规范化的输入验证方法同样会有助于防止注入攻击,但这不是一个完整的防御,因为许多应用程序在输入中需要特殊字符,例如文本区域或移动应用程序的API。
  • 对于任何剩余的动态查询,可以使用该解释器的特定转义语法转义特殊字符。OWASP的Java Encoder和类似的库提供了这样的转义例程。
  • 注意:SQL结构,比如:表名、列名等无法转义,因此用户提供的结构名是非常危险的。这是编写软件中的一个常见问题。
  • 在查询中使用LIMIT和其他SQL控件,以防止在SQL注入时大量地泄露记录。

A2:失效的身份认证

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

知识点简介

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

  • 允许密码填充 (opens new window),这使得攻击者获得有效用户名和密码的列表。
  • 允许暴力破解或其他自动攻击。
  • 允许默认的、弱的或众所周知的密码,例如“Password1”或“admin/admin”。
  • 使用弱的或失效的验证凭证,忘记密码程序,例如“基于知识的答案”,这是不安全的。
  • 使用明文、加密或弱散列密码(参见:A3:2017-敏感数据泄露)。
  • 缺少或失效的多因素身份验证。
  • 暴露URL中的会话ID(例如URL重写)。
  • 在成功登录后不会更新会话ID。
  • 不正确地使会话ID失效。当用户不活跃的时候,用户会话或认证令牌(特别是单点登录(SSO)令牌)没有正确注销或失效。

案例场景

  • 场景#1:

凭证填充,使用已知密码的列表,是常见的攻击。如果应用程序不限制身份验证尝试,则可以将应用程序用作密码oracle,以确定凭证是否有效。

  • 场景#2:

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

  • 场景#3:

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

如何防止?

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

  • 不要使用发送或部署默认的凭证,特别是管理员用户。
  • 执行弱密码检查,例如测试新或变更的密码,以纠正“排名前10000个弱密码 (opens new window)” 列表。
  • 将密码长度、复杂性和循环策略与NIST-800-63 B的指导方针的记住秘密 (opens new window),或其他现代的基于证据的密码策略相一致。
  • 确认注册、凭据恢复和API路径,通过对所有输出结果使用相同的消息,用以抵御账户枚举攻击。
  • 限制或逐渐延迟失败的登录尝试。记录所有失败信息并在凭据填充、暴力破解或其他攻击被检测时提醒管理员。
  • 使用服务器端安全的内置会话管理器,在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中,可以安全地存储和当登出、闲置、绝对超时后使其失效。

  • 4
    点赞
  • 43
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值