让我们回顾一下OWASP的前10名，提醒我们如何更好地保护我们的应用程序、业务和客户免受非法和破坏性的网络攻击，这些攻击可以通过在正确的地方执行正确的程序来防止。什么是OWASP？来源openwebapplicationsecurity项目是一个非盈利组织，旨在帮助提高人们对Web应用程序安全性的认识，并就如何在应用程序、基础设施和内部流程中安装预防措施提供指导。他们有几个项目，包括一个用于安全培训的不安全JavaScript应用程序，但我们今天感兴趣的是OWASP前10名。定期更新的OWASP前10名列出了当今影响web应用程序的主要安全威胁。每一点都描述了一个威胁，并概述了您希望尽可能减轻威胁的各种事情。在Auth0，我们会采取措施来缓解下面列出的大多数问题，因此，当您将身份验证需求委托给我们时，很多问题已经为您解决了。让我们浏览一下这个列表，看看这些威胁以及我们可以做些什么来确保我们自己的应用程序是安全的，并检查Auth0平台的功能，这些功能有助于减轻或完全消除您关注的这些威胁。#1： 注入经典SQL注入是一种众所周知的攻击，已经存在很长时间了，尤其是在涉及遗留代码时。OWASP继续将SQL注入视为一种常见的攻击，这种攻击不仅很容易被利用，而且很容易被发现是应用程序中的一个弱点，而且如果被攻击者成功利用，也会产生毁灭性的影响。在大多数情况下，此类攻击之所以成功，是因为：应用程序依赖于尚未在SQL查询中直接清理的用户输入查询本身没有参数化在验证和处理用户输入时，假设所有用户输入都可能是恶意的，这是一个很好的口头禅。参数化SQL查询也有助于保护您的数据存储，使其不受格式错误查询的影响，这些查询以不希望的、破坏性的方式操作数据。作为SQL查询参数化的一个示例，设想一个将新用户插入数据库的查询：sql=数据库准备"插入到用户（name，email）值（'\{name}'，'\{email}'）"sql.执行在上面的代码片段中，name和email的值被插入到SQL字符串中，而不会对输入值执行任何清理。如果这些输入值来自表单字段，则攻击者可能会提供恶意值，使SQL字符串格式错误并执行攻击。使用参数化值的同一查询可能如下所示：sql=数据库准备"插入用户（姓名、电子邮件）值（？, ?)"sql.执行'一些用户'，'一些用户@email.com'在这种情况下，在将值包含在SQL语句中之前，可以由数据库库对这些值进行转义和清理。这样，SQL语句的格式就不会出现损坏或暴露数据的错误。最近，NoSQL注入已经成为使用Mongo等NoSQL数据库的一个因素。虽然它不使用SQL，但是当用户输入没有经过验证和清理时，它仍然可能容易受到攻击，因为查询本身可以被操纵。验证用户输入并拒绝不符合预期格式的值是一个好策略。SQL和NoSQL注入攻击只是一大类注入攻击的一个子集，这类攻击还包括命令、表达式语言和LDAP。#2： 中断的身份验证在Auth0中，我们最关心的是破坏身份验证，OWASP承认它很容易被利用，具有极大的潜在危害。。。断开的身份验证涉及到使用应用程序或服务对用户进行身份验证的许多事情，包括：使用已知密码列表的自动暴力攻击弱密码或已知密码的权限在强哈希上存储纯文本或弱哈希密码多因素身份验证（MFA）的使用注销时或一段时间不活动后会话的无效性不正确在应用程序中实现MFA将有助于防止"凭证填充"和其他暴力攻击，因为攻击者无法及时、自动地完成MFA步骤。关于密码，使用公共密码列表验证弱密码或已知密码，并使用强哈希算法（如Bcrypt或PBKDF2）散列用户密码。不要使用像MD5这样的弱散列，也不要将密码存储为纯文本。当用户输入不正确的用户名或密码时，有目的地使用含糊的登录失败消息也是一个很好的做法。否则，攻击者可能能够识别有效的帐户，他们可以使用这些帐户来煽动攻击。使用Auth0 Universal Login时，大多数关于暴力攻击的问题，包括跨站点脚本攻击（XXS）和强密码哈希都可以为您处理。此外，我们可以非常容易地打开并将MFA集成到您的应用程序中，以获得额外的安全级别。#3： 敏感数据暴露OWASP Top 10中的这一项涉及防止在成功进行攻击时暴露敏感数据，这反过来又有助于防止其他攻击。它涉及到安全地处理敏感数据，加密静态数据，并勤勉地保存所需的尽可能多的数据，只要需要就保存多久。欧盟通用数据保护条例（GDPR）今天存在的原因之一是对敏感个人数据的不当处理。为防止敏感数据被窃取，您可以采取以下措施：确保使用有效的SSL证书通过HTTPS加密和传输web流量，并尽可能升级不安全的连接（HSTS）。让我们加密发行免费的SSL证书，这样可以很容易地确保您的web流量是安全的对包含敏感信息的任何浏览器cookie进行加密和签名删除不再需要的任何敏感数据使用强哈希算法（如Bcrypt或PBKDF2）散列密码加密静态敏感数据请注意，如果SQL注入攻击成功，使用自动数据库加密技术仍可能使您暴露在外，因为必须在数据库级别读取和解密数据。作为核心应用程序逻辑的一部分执行加密和解密步骤将有助于防止这种情况发生。#4： XML外部实体（XXE）XXE攻击旨在暴露配置不良的XML解析器中的漏洞。此类攻击可用于暴露敏感数据（如读取系统密码文件）或对资源调用拒绝服务攻击（DoS）。防止这种类型的攻击主要归结于开发人员培训和正确配置的XML解析器。除非解析器有特定的要求，否则应该将它们配置为不验证和处理文档类型声明（DTD），或者忽略DTD中外部实体的解析和处理。如果可能的话，使用另一种更简单的数据格式，比如JSON，它不受XXE的影响。#5： 访问控制中断如果您的应用程序能够基于特权或权限区分用户，那么它可能会面临破坏性的访问控制漏洞，攻击者可以将其权限提升到不应该拥有的权限。例如：当用户未登录或无权查看"仅限成员"页时，无法阻止访问该页不验证用户可以更改的URL参数（例如，将一个用户ID换成另一个）信任cookie值没有被更改，该值可用于确定用户的角色。同样，确保你的cookies都是加密和签名的，这会让你相信它们的值没有被更改注意验证用户权限是关键。在计算用户可以执行的操作时，不要信任任何可能被用户修改的输入。#6： 安全配置错误OWASP已将前10名列表中的这一项标识为易于利用、易于发现且极为常见的内容。它涉及的主题包括：主机系统上的过期安全修补程序应用程序框架安全功能未打开或配置不正确默认帐户、密码和安全密钥保持启用和不变主机系统上启用了未使用或默认的端口和服务详细错误页或目录列表已打开重要的是要确保运行应用程序的主机系统已使用最新的安全修补程序进行更新，并且应用程序框架已启用所有适当的安全功能。这方面的另一个严重问题是，确保第三方平台（如Auth0）的任何密钥都不会与其余代码一起提交和上载到源代码管理提供程序，尤其是在应用程序是开放源代码的情况下。攻击者可以使用自动化工具对其进行扫描。最好将这些密钥安全地与源代码分开存储。#7： 跨站点脚本（XXS）XXS是其中一个存在了很长时间的术语，大多数软件开发人员都听说过，但它仍然是一个非常常见且易于利用的攻击向量。这类攻击主要涉及注入未经确认的输入，导致用户无意中与恶意站点或文件进行交互，但也有几种不同的攻击方式：反射XXS：发现一个网站没有正确清理通过URL输入的内容。攻击者会制作一个指向网站的链接（包含攻击），并将其分发（通常是通过电子邮件），希望不知情的收件人会单击该链接。如果他们这样做了，攻击就被执行了，可能会被击落