与OWASP API前十名中的大多数漏洞不同，不恰当的资产管理并不特别围绕编码缺陷。相反，这个漏洞更像是一个人为或管理问题，它允许旧的API在应该被较新的、更安全的版本取代后很久还在原地。如果仍在开发中的API在被完全加固以抵御威胁之前就暴露在生产环境中，也会发生这种情况。

由于微服务和云计算的出现，这一漏洞尤其难以管理。在这种环境下，新的服务可能会被迅速启动，以满足暂时的需要，然后被遗忘，从未退役。如果旧的API被留在生产环境中连接，它可能会危及整个网络。

想尝试一下对这个安全漏洞的游戏化挑战吗？请进入我们的竞技场。[从这里开始]

不当的资产管理缺陷是如何影响API的？

不当的资产管理缺陷是现代的产物。以业务速度前进的组织有时每天都能旋转出成百上千的服务和微服务。这通常是快速完成的，而且没有创建任何附带的文档，也没有解释相关的API是用来做什么的，需要多长时间或其重要性。这可能会迅速产生API蔓延，随着时间的推移可能会变得无法控制，特别是如果没有全面的政策来定义API可以存在多久。

在这种环境下，很有可能一些API会丢失、被遗忘或从未退役。

有权限在正常流程之外创建新服务的用户有时也应受到指责。例如，一个营销小组可能会创建一个服务来帮助支持一个即将到来的事件，如产品发布，然后在事件完成后再也没有把它拿下来。后来有人看到这个服务及其相关的API，可能不知道它们为什么会存在，如果没有文档，它可能仍然是个谜。他们可能不愿意从生产环境中删除这些API，甚至不愿意将它们升级到新的版本，因为他们不知道这些API有多关键，也不知道它们是做什么的。

漏洞变得很危险，因为框架中的API的安全性随着时间的推移而提高。研究人员可能会发现一个漏洞，或者可以增加额外的安全性来阻止越来越流行的攻击类型。除非升级，否则较旧的API可能仍然容易受到这些攻击，所以黑客通常会搜索它们或使用自动工具来寻找它们。

在OWASP提供的一个真实案例中，一家公司升级了其用于搜索用户数据库的API，以修补一个关键的缺陷。但他们错误地将旧的API留在了原地。

攻击者注意到，新API的位置类似于（api.criticalservice.com/v2）。通过用(api.criticalservice.com/v1)替换这个URL，他们就能够使用带有已知漏洞的旧API。这最终暴露了超过1亿用户的个人记录。

消除不当的资产管理缺陷

从你的环境中消除不恰当的资产管理缺陷的唯一方法是对所有的API、它们的用途和版本进行严格的盘点。这应该从现有的API清单开始，关注的因素包括它们应该被部署到什么环境中，如生产或开发，谁应该对它们有网络访问权，当然还有它们的版本。

一旦完成，你需要实施一个流程，将文档自动添加到任何新创建的API或服务中。这应该包括API的所有方面，包括速率限制、如何处理请求和响应、资源共享、可以连接到哪些端点、任何适用的相关政策，以及其他任何以后需要审计的内容。你也应该避免在生产中使用非生产的API或来自开发环境的API。也可以考虑给API增加一个时间限制，在这个时间限制内，API的继续使用必须有其所有者的证明，以防止自动退役。

每当活动API的新版本可用时，执行风险assessment ，以确定你是否应该升级，以及该过程应如何进行，以避免破坏生产环境。一旦你迁移到新的API，从环境中完全删除旧的API。

做好这一切可以帮助防止不当的资产管理漏洞对你的组织、用户或网络造成伤害。请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试一下 Secure Code Warrior 培训平台的演示，以保持你所有网络安全技能的磨练和更新。

‍

之前的一篇博文描述了Java中的 "Bitwise vs Boolean Operator"。

• Java 陷阱 - 位操作符与布尔操作符

我们在一个有趣的小测验中加入了这个问题的变体，以及其他一些Java的问题，名为 "挑战Sensei"。

• scw.typeform.com/to/rgw7q7OE

如果你已经阅读了上面的博文，那么你将至少在其中一个问题上处于有利地位。

但是你的朋友可能不会，所以如果你觉得这个测验很有趣，你可以和他们分享，看看他们的分数是否和你一样高。

既然我们不想只是考查你。我们想尝试用这个来帮助教育和编纂知识。因此，我们创建了一个Github repo，其中有可运行的问题和解决方案的代码实例。

• github.com/SecureCodeWarrior/challenge-thesensei

这是一个 Sensei启用的 repo。

当你克隆 repo 并将其加载到 IntelliJ 时，假设你安装了Secure Code Warrior SenseiIntelliJ插件，那么它将自动看到你有一个.sensei 文件夹，并加载Sensei 的配方。

在IDE中浏览代码时，你应该看到IntelliJ提示你代码中存在错误，这应该使你更容易看到代码中的问题。

• 将鼠标悬停在突出显示的代码上，然后你会看到一个提示，告诉你有关错误的信息
• 使用显示上下文动作键：alt+enter（Windows）option+enter（macOS），我们可能有一个可以修复代码的QuickFix。

Sensei 食谱已被添加为。

• 比特运算符
• 分离式IP地址
• 断言命令

我们将在未来增加更多的配方和更多的解释文字，以涵盖代码的其余部分......但不要让这阻止你看一看代码并自己发现错误。

并记得尝试测验和"挑战Sensei"。

Java 陷阱 - 位操作符与布尔操作符

> "Java Gotcha" - 一个很容易意外实现的常见错误模式。

一个不小心陷入的相当简单的Java Gotcha是：使用Bitwise操作符而不是布尔比较操作符。

例如，一个简单的错误输入会导致写成"&"，而你真正想写的是"&&"。

我们在审查代码时学到的一个常见的启发式方法是。

> "&"或"|"在条件语句中使用时，可能不是故意的。

在这篇博文中，我们将探讨启发式方法，并确定我们可以识别和修复这个编码问题的方法。

问题是什么？位操作在布尔运算中工作良好

在布尔运算中使用Bitwise运算符是完全有效的，所以Java不会报告语法错误。

如果我构建一个JUnit测试来探索Bitwise OR (|)和Bitwise AND (&)的真值表，那么我们将看到Bitwise运算符的输出与真值表相匹配。鉴于此，我们可能会认为使用Bitwise运算符不是一个问题。

与真值表

@Test
    void bitwiseOperatorsAndTruthTable(){
          Assertions.assertEquals(true, true & true);
          Assertions.assertEquals(false, true & false);
          Assertions.assertEquals(false, false & true);
          Assertions.assertEquals(false, false & false);
    }

测试通过，这就是完全有效的Java。

OR真值表

   @Test
    void bitwiseOperatorsOrTruthTable(){
        Assertions.assertEquals(true, true | true);
        Assertions.assertEquals(true, true | false);
        Assertions.assertEquals(true, false | true);
        Assertions.assertEquals(false, false | false);
    }

这个测试也通过了，为什么我们更喜欢"&&"和"||"？

真值表图像是用 真值表工具从 web.standfor.edu.

问题。短路运行

真正的问题是Bitwise (&, |)和Boolean (&&, ||)运算符之间的行为差异。

布尔运算符是一个短路运算符，只在需要的时候进行评估。

比如说

if (args != null & args.length() > 23) {
    System.out.println(args);
}

在上面的代码中，两个布尔条件都会被评估，因为使用了Bitwise操作符。

• args != null
• args.length() > 23

这使得我的代码在args为空时容易出现NullPointerException，因为即使args为空，我们也会对args.length进行检查，因为两个布尔条件都要被评估。

布尔运算法则 短路评估

当使用&&的时候，比如说

if (args != null && args.length() > 23) {
    System.out.println(args);
}

一旦我们知道args != null的评估结果为false，条件表达式的评估就会停止。

我们不需要评估右侧的情况。

无论右侧条件的结果如何，布尔表达式的最终值将是假的。

但这永远不会发生在生产代码中

这是一个相当容易犯的错误，而且并不总是被静态分析工具所发现。

我使用了下面的Google Dork，看看是否能找到这种模式的公开例子。

filetype:java if "!=null & "
这次搜索从Android中带回了一些RootWindowContainer的代码
isDocument = intent !=null & intent.isDocument()

这种类型的代码可能会通过代码审查，因为我们经常在赋值语句中使用Bitwise运算符来屏蔽数值。但是在这个例子中，结果和上面的if语句的例子是一样的。如果intent曾经是空的，那么就会抛出一个NullPointerException。

很多时候，我们之所以能够摆脱这种结构，是因为我们经常进行防御性编码，并编写多余的代码。在大多数情况下，对!=null的检查很可能是多余的。

这是程序员在生产代码中犯的一个错误。

我不知道搜索结果的时效性如何，但当我进行搜索时，有结果回来了，有来自：谷歌、亚马逊、阿帕奇......和我的代码。

最近我的一个开源项目的拉动请求正是为了解决这个错误。

if(type!=null & type.trim().length()>0){
    acceptMediaTypeDefinitionsList.add(type.trim());
}

如何找到这个

当我在几个静态分析器中检查我的样本代码时，没有任何一个分析器发现这个隐藏的自毁代码。

作为一个团队，Secure Code Warrior ，我们创建并审查了一个相当简单的Sensei 的配方，可以接这个。

因为Bitwise运算符是完全有效的，而且经常用于赋值，我们把重点放在if语句的使用上，以及Bitwise &的使用上，以找到有问题的代码。

search:
  expression:
    anyOf:
    - in:
        condition: {}
    value:
      caseSensitive: false
      matches: ".* & .*"

当"&"被用作条件表达式时，它使用正则表达式来匹配，例如在if语句中。

为了解决这个问题，我们再次依靠正则表达式。这一次，我们使用QuickFix中的sed函数，将表达式中的&替换为&&。

availableFixes:
  - name: "Replace bitwise AND operator to logical AND operator"
    actions:
      - rewrite:
          to: "{{#sed}}s/&/&&/g,{{{ . }}}{{/sed}}"

结束语

这涵盖了最常见的误用比特运算符的情况，即实际上打算用布尔运算符的情况。

还有其他一些情况可能会出现这种情况，比如说分配的例子，但在编写食谱时，我们必须试图避免假阳性的识别，否则食谱会被忽略或关闭。我们建立配方来匹配最常见的情况。随着Sensei 的发展，我们很可能在搜索功能中增加额外的特殊性，以涵盖更多的匹配条件。

在目前的形式下，这个配方将确定许多活生生的用例，最重要的是，在我的项目中报告的那个用例。

注意：有相当多的代码勇士为这个例子和配方审查做出了贡献--Charlie Eriksen, Matthieu Calie, Robin Claerhaut, Brysen Ackx, Nathan Desmet, Downey Robersscheuten。感谢你们的帮助。

---

你可以使用 "Preferences\ Plugins"（Mac）或 "Settings\ Plugins"（Windows）从IntelliJ内部安装Sensei ，然后只需搜索 "sensei secure code"

我们在Secure Code Warrior GitHub账户中的`sensei-blog-examples`仓库里有很多这些博文的源代码和配方（包括这一篇）。

https://github.com/securecodewarrior/sensei-blog-examples

了解更多关于Sensei

什么是静态分析？

静态分析是在不执行应用程序的情况下对源代码进行自动分析。

当分析是在程序执行过程中进行的，那么它就被称为动态分析。

静态分析通常用于检测。

• 安全漏洞。
• 性能问题。
• 不符合标准。
• 使用过时的编程结构。

静态分析工具是如何工作的？

所有静态分析工具共同的基本概念是搜索源代码，以确定具有某种警告或与之相关的信息的特定编码模式。

这可能是简单的 "JUnit 5测试类不需要是'公共'的"。或者是一些复杂的识别，如 "在SQL执行语句中使用了不可信任的字符串输入"。

静态分析工具在实现这一功能的方式上有所不同。

• 源代码解析技术来创建一个抽象语法树（AST）。
• 文本正则表达式匹配。
• 上述各项的组合。

正则表达式对文本的匹配非常灵活，很容易写出匹配规则，但往往会导致大量的误报，而且匹配规则对周围的代码环境一无所知。

AST匹配将源代码视为程序代码，而不仅仅是充满文本的文件，这允许更具体、更有背景的匹配，并可以减少针对代码报告的误报数量。

持续集成中的静态分析

静态分析通常是在持续集成（CI）过程中进行的，以生成一份合规性问题的报告，该报告可以被审查以获得代码库随时间变化的客观观点。

有些人通过配置静态分析工具，使其只测量代码的特定部分，并且只报告规则的子集，从而将静态分析作为其代码质量的客观测量。

客观性是由所使用的规则提供的，因为这些规则在评估代码时不会随时间而变化。显然，所使用的规则的组合及其配置是一个主观的决定，不同的团队在不同的时间选择使用不同的规则。

在CI中进行静态分析是有用的，但可能会延迟对程序员的反馈。程序员在编码时并没有收到反馈，他们是在以后通过静态分析工具运行代码时收到反馈。在CI中运行静态分析的另一个副作用是，结果更容易被忽略。

为了帮助团队更加关注静态分析的结果，通常可以在构建过程中配置一个阈值指标，如果超过该指标，例如触发了一些规则，则构建失败。

IDE中的静态分析

为了更快地收到反馈，有许多IDE插件可以在IDE中按需运行静态分析规则，或在代码变化时定期运行。

当程序员在写代码时，可以在IDE中看到违反规则的情况，为了使规则更难被忽视，通常可以将违反规则的情况配置为在编辑器中呈现下划线的代码。

我个人认为这是一种改进我的编码的有用方法，特别是当使用静态分析工具所涵盖的新库时。虽然它可能会有假阳性的 "噪音"，或者你不感兴趣的规则。但这可以通过采取额外步骤配置静态分析工具以忽略某些规则来解决。

基于静态分析规则修复代码

在大多数静态分析工具中，规则的修复是留给程序员的，所以他们必须了解违反规则的原因以及如何修复它。

很少有静态分析工具还包括修复违规的能力，因为修复往往是根据团队和所使用的技术以及他们商定的编码风格来进行的。

默认规则

当静态分析工具带有默认的规则时，可能会对规则的质量产生错误的信心，很容易让人相信它们涵盖了程序员可能遇到的所有问题，以及规则应该适用的所有情况。有时，一个规则应该适用的情况可能很微妙，而且不容易被发现。

希望通过使用静态分析工具，并更详细地研究规则和违规行为，程序员将发展出在其特定领域背景下检测和避免问题的技能。

当领域需要上下文规则时，静态分析工具可能没有任何与你的领域或库相匹配的规则，此外，这些工具往往难以配置和扩展。

烦人的事

这些 "烦恼 "都不是不可克服的。

• 假阳性反应
• 缺乏修复
• 忽略规则的配置
• 添加特定环境的规则

但它们经常被用作借口，以避免首先使用静态分析工具，这是一个遗憾，因为使用静态分析可以非常有用，作为一种方法。

• 突出强调对初级开发人员的更好方法
• 对明显违反编码规定的行为获得快速反馈
• 确定程序员以前没有遇到过的晦涩难懂的问题
• 强化程序员采用了良好的编码方法（当没有报告违反情况时

基于IDE的静态分析工具

作为一个项目的个人贡献者，我喜欢使用在IDE中运行的静态分析工具，这样我就能快速收到对我的代码的反馈。

这补充了任何拉动请求的审查过程，以及一个项目可能有的CI整合。

我试图找出能给我带来优势的工具，并改善我的个人工作流程。

当工具在IDE中运行时，因为它们往往共享相同的基本GUI和配置方法，所以很容易将它们互换起来看待。

这些工具可能有重叠的功能或规则集，但为了获得最大的优势，我安装了多个工具来利用它们的优势。

我在编码时积极使用的静态分析IDE工具列举如下。

• 内置的IntelliJ检查 - 常见的编码模式
• SpotBugs - 常见错误
• SonarLint--常见的使用模式
• CheckStyle--常见的风格模式
• Sensei 来自Secure Code Warrior - 自定义规则创建

我使用它们是因为它们能很好地一起工作，相互增强和补充。

英特利杰检查

如果你使用IntelliJ，那么你已经在使用他们的检查。

这些是静态分析规则，在IDE中被标记出来。其中一些还有快速修复选项，可以重写代码以解决这个问题。

这些规则可配置为开启和关闭，并可选择用于在IDE中突出显示的错误级别。

有很多好的IntelliJ检查报告。我知道这一点，因为我在写这篇文章时阅读了它们。我把IntelliJ检查作为默认值，并没有对其进行配置，但为了从检查中获得充分的价值，你应该阅读它们，识别那些与你的编码风格相关的内容，并配置警告级别，以便你在代码中注意到它们。

IntelliJ检查的伟大之处在于，它们是随IDE免费提供的，它们有助于建立肌肉记忆。

• 在写代码时注意到源代码中的警告和错误
• 将鼠标悬停在被标记的代码上，了解违反规则的情况
• 使用alt+enter来应用问题的快速修复方法

斑点虫

SpotBugsIntelliJ插件使用静态分析来尝试并提醒你注意代码中的错误。

SpotBugs可以从IntelliJ首选项中配置来扫描你的代码，实际使用的规则可以在检测器标签中找到。

我倾向于在写完和审查完我的代码后使用SpotBugs，然后我会运行 "分析项目文件包括测试源"。

这确实有助于我识别错误、死代码和明显的优化。它还迫使我研究一些被标记的违规行为，以帮助我决定做什么。

SpotBugs将发现问题，但不提供任何试图解决问题的快速修复行动。

SpotBugs很容易配置，我发现它是一个有用的客观的第二意见，可以在我的IDE中咨询。

声波提示器(SonarLint)

SonarLint插件。

SonarLint可以从IntelliJ首选项中进行配置，以选择对代码进行验证的规则。

默认情况下，SonarLint是实时运行的，显示你正在编辑的当前代码的问题。

SonarLint不提供快速修复，但与违规报告相关的文件通常都很清楚，而且记录得很好。

我发现SonarLint在过去很有用，它能提醒我注意到较新版本的Java的新功能。

检查风格

CheckStyle插件提供了一个混合的格式化和代码质量规则。

CheckStyle插件与 "Sun Checks "和 "Google Checks "捆绑在一起。

这些的定义可以在网上很容易找到。

当一个项目花时间创建自己的规则集时，CheckStyle会增加最大的价值。然后，IDE插件可以被配置为使用该规则集，程序员可以在提交代码到CI之前进行扫描。

当违反CheckStyle的数量超过一个阈值时，CheckStyle通常被用作CI流程的构建失败插件。

Sensei

Sensei使用基于抽象语法树（AST）的静态分析来匹配代码和创建快速修复，这允许非常具体地识别有问题的代码。

AST允许与配方相关的QuickFixes理解周围的代码，例如，当在代码中添加一个新的类时，该类的任何导入将只被添加到源文件中一次，而不是为每个替换。

创建Sensei ，是为了方便建立自定义的匹配规则，这些规则在其他工具中可能不存在，或者难以配置。 

所有的配置都可以在GUI中进行，而不是修改一个配置文件。当创建新的配方时，GUI可以很容易地看到配方所匹配的代码。当定义快速修复时，代码的前后状态可以立即被比较。这使得它更容易创建非常有背景的配方，即对团队或技术，甚至对个别程序员来说是独一无二的。

我将Sensei 与其他静态分析工具结合使用，例如，大多数静态分析工具会发现问题，但不会修复它们。Sensei 的一个常见用例是在Sensei 中复制其他工具的匹配搜索，并通过快速修复来扩展它。这样做的好处是，应用的自定义修复已经符合你项目的编码标准。

我经常发现自己创建的Sensei ，在IntelliJ Intensions集中已经存在，因为Intension报告与我创建的上下文不太匹配，或者因为IntelliJ提供的QuickFix与我想使用的代码模式不匹配。

我增强了现有的工具，而不是试图完全取代它们。

Sensei ，当你确定一个普通规则的上下文变体时，也是非常有用的，例如，如果你使用的是静态分析工具不支持的SQL库，但静态分析引擎中的普通SQL规则仍然适用，那么你可以使用Sensei ，创建这些规则的特定库变体。

Sensei 不像上面提到的静态分析工具那样开箱就有大量的通用配方，它的优势在于可以很容易地创建新的配方，完成快速修复的配置，以适应你的特定编码风格和使用情况。

注意：我们正在开发一个公共配方库，以涵盖一般的使用情况。 你可以在这里找到它.

摘要

我倾向于选择那些能一起工作的、可配置的、易于扩展的工具，以满足我的特定环境。多年来，我一直在IDE中使用静态分析工具来帮助我识别问题，并更多地了解我使用的编程语言和库。

我结合使用上述所有的工具。

• IntelliJ Intentions帮助标记出开箱即用的常见代码问题，通常有相关的快速修复方法。
• SpotBugs可以发现我可能错过的简单错误，并提醒我注意性能问题。
• SonarLint识别了我不知道的Java特性，并提示我用更多的方法来模拟我的代码。
• CheckStyle帮助我遵守约定的编码风格，在CI期间也会强制执行。
• Sensei 帮助我创建QuickFixes，以增强静态分析工具发现的常见情况，并创建在其他工具中难以配置的特定项目或技术配方。

---

使用 "Preferences \ Plugins"（Mac）或 "Settings \ Plugins"（Windows）从IntelliJ内部安装Sensei ，然后搜索 "sensei secure code "即可。

你可以在Secure Code Warrior GitHub账户中的 "sensei-blog-examples "项目中找到常见使用情况的示例代码和配方库。

https://github.com/securecodewarrior/sensei-blog-examples

了解更多关于Sensei

Sensei 项目本身也有自己的一套配方，这些配方是随着时间的推移而建立起来的。这篇博文是Sensei 团队为其中一个场景建立配方的例子。Guice的一个错误配置，导致在测试中运行时报告NullPointerException。

这可以推广到许多依赖性注入的场景，即代码在语法上是正确的，但由于布线配置不正确，错误就会溜走。

这经常发生在我们学习技术的时候，我们总是犯一些简单的错误，忘记把东西连起来。但这种情况也发生在有经验的专业人士身上，因为......我们都会犯错，而且我们可能没有单元测试来覆盖所有的东西。

不正确的依赖性注入接线产生的运行时间异常

下面的代码在运行时以NullPointerException失败。

‍

injector = Guice.createInjector(new SystemOutModule());
CountReporter reporter = injector.getInstance(CountReporter.class);
String [] lines5 = {"1: line", "2: line", "3: line", "4: line", "5: line"};
reporter.reportThisMany(Arrays.asList(lines5));
Assertions.assertEquals(5, reporter.getCount());

这段代码在语法上是正确的，但由于我们在SystemOutModule配置中漏掉了一个requestStaticInjection，所以失败了。

‍

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
    }
}

当我们试图使用使用Injector创建的报告器时，它没有被完全实例化，当我们调用reportThisMany时，我们收到一个NullPointerException。

我们很可能在代码审查中漏掉了这一点，或者我们没有触发依赖注入的单元测试，而使它在我们的构建中溜走了。

‍

警告信号

在这种情况下，有一个警告信号，CountReporter有一个用@Inject注解的静态字段，但是......CountReporter类本身是封装私有的。

在一个复杂的代码库中，这可能是一个警告信号，表明代码是不正确的，因为配置绑定的模块类需要在同一个包中才能工作。

‍

class CountReporter {
    @Inject
    private static ILineReporter reporter;

我们犯的另一个错误是，我们可能在代码审查中发现，我们忘记了在SystemOutModule配置方法中实际绑定字段。

binder().requestStaticInjection（CountReporter.class）。

如果我们写了requestStaticInjection代码，那么在试图使用CountReporter时产生的语法错误会提醒我们注意这个简单的错误。

> 'reporters.CountReporter'在'reporters'中不公开。不能从包外访问

‍

遗憾的是。我们忘记了，代码中没有句法上的警告标志。

Sensei 能提供什么帮助？

我们可能不会使用Sensei 来拾取缺少的requestStaticInjection，因为我们所有的Guice配置布线都需要使用该方法，而且我们不能保证所有的布线都会像这个用例一样简单。

我们可以写一个Sensei 规则来寻找一些警告信号，说明我们的代码不合格。

在这种情况下，这将意味着。

• 找到任何带有@Inject注解字段的类
• 凡是不公开的课程。

上述情况是警告信号，他们不太可能是被布线了。

通过创建一个配方，那么我们就可以在编码过程中及早得到一个警告信号，并减少对我们的拉动请求或解决我们的技术债务的依赖，以使我们能够添加单元测试。

如何创建一个食谱？

我想完成的任务是。

• 创建一个配方，匹配在受保护的私有类中用@Inject注释的字段。

这应该能给我们足够的警告，以确定任何使用它的模块，并添加缺少的接线代码。

在我的CountReporter类中，我将使用Alt+Enter来创建一个新的配方，我将从零开始

我将为其命名并添加描述。

名字。Guice:Injected Field Not Public
说明。如果Injected字段不是公开的，那么代码可能没有被连接起来
Level。警告

我写的搜索是寻找一个有注解为Inject的字段的类，但它的范围没有被定为public。

search:
field:
with:
annotation:
type:"com.google.inject.Inject"
in:
class:
without:
modifier:"公共"

修复

配方中的QuickFix将通过改变范围来修正注入的类。但这并不是我必须要改变的唯一代码。

可用的修复方法。

- name: "Change class to public.记住也要请求对这个类进行注入"
actions:
- changeModifiers:
visibility:"public"
target: "parentClass"

当配方被触发时，我仍然有一个手动步骤要在我的代码中执行，添加包含requestStaticInjection的行来完全实例化对象。

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
        // instantiate via dependency injection
        binder().requestStaticInjection(CountReporter.class);
    }
}

我有可能再写一个配方来接上这个。我可能不会这样做，除非忘记添加静态注入成为我在编码时犯的一个半常规错误。

‍

摘要

如果我们发现自己犯了一个常见的根基模式的错误，那么Sensei ，可以帮助编纂围绕检测和修复问题的知识，然后希望它不会通过代码审查和进入生产。

有时，我们编写的配方会识别出启发式模式，即与之匹配并不能保证有问题，但很可能有问题。

此外，我们编写的食谱和快速修复方法不一定要完全全面，它们需要足够好，以帮助我们识别和修复问题，而不会过于复杂。因为当它们变得过于复杂时，就会变得更难理解，更难维护。

---

你可以使用 "Preferences \ Plugins"（Mac）或 "Settings \ Plugins"（Windows）从IntelliJ内部安装Sensei ，然后只要搜索 "sensei secure code"。

这篇文章的源代码和配方可以在Secure Code Warrior GitHub账户的`sensei-blog-examples`仓库中的`guiceexamples`模块中找到。

https://github.com/securecodewarrior/sensei-blog-examples

了解更多关于Sensei

为JUnit 5修改方法和类的可见性

编程的乐趣之一是需要不断地学习以保持更新。其中一个问题是，我们建立了熟悉的使用模式，这可能会影响新方法的采用。Sensei ，通过识别废弃的模式并提示我们继续使用的修复方法来帮助迁移。

举个例子，当我从JUnit 4迁移到JUnit 5时，我习惯于把所有的测试类和方法写成公共的。但在JUnit 5中，它们可以被打包为私有。

例如：而不是

public class Junit5VisibilityTest {
    @Test
    public void thisDoesNotNeedToBePublic(){
        Assertions.assertTrue(true);
    }
}

我真的想写。

class Junit5VisibilityTest {
    @Test
    void thisDoesNotNeedToBePublic(){
        Assertions.assertTrue(true);
    }
}

我花了一些时间来建立肌肉记忆，以编码到这一点，而且我仍然偶尔会失误。

使用Sensei

通过Sensei ，我可以创建配方，找到公共方法和类，并自动将声明修改为包的私有。

为了实现这一目标，我创建了一个配方。

名称 - JUnit。JUnit 5测试方法不需要公开
说明 - JUnit 5测试方法不需要公开可见性
等级 - 错误

我把它归类为错误，因为我想杜绝这种编码做法，而且当我在IDE中写代码时，我希望这个问题有更高的可见度。

修改集体宣言

为了找到类，我从Junit 5（即org.junit.jupiter.api.Test）中搜索有@Test子注解的任何类。

而在该类有修饰符public的地方。

search:
class:
with:
child:
annotation:
type:"org.junit.jupiter.api.Test"
修改器。"公共"

然后快速修复改变修改器，删除可见性，使其成为默认值，而默认值是包的私有性，这正是我所寻找的。

availableFixes:
- name: "remove public visibility from JUnit 5 Test class"
actions:
- changeModifiers:
visibility:""

修改方法声明

方法声明修正案的配方与类的配方基本相同。

首先，我搜索了JUnit 5中用@Test注解的公共方法。

搜索：
方法：
注释：
类型。"org.junit.jupiter.api.Test"
修改器。"公共"

然后我把修改器改成默认的可见性。

availableFixes:
- name: "Remove @Test method public visibility"
actions:
- changeModifiers:
visibility:""

提示：修改多种方法

Sensei 有能力对当前文件中的所有违规行为应用快速修复。

当我使用alt+enter来应用QuickFix时。

如果我展开QuickFix的名称菜单，我可以看到一个选项，即：。

"修复所有：'JUnit。JUnit 5测试方法不需要是公共的'文件中的问题"

当我选择该选项时，那么Sensei 将修正所有出现的问题，而不仅仅是我选择的那个。

修改类别

与方法不需要公开一样，类也不需要公开。

我可以创建一个配方和一个QuckFix来修改类。

名称 - JUnit。Junit 5测试类不需要是公共的
说明 - Junit 5测试类不需要是公共的
等级 - 错误

当我找到一个公有的类，并且有一个带有@Test注解的方法。然后我想改变其可见性。

搜索：
class:
modifier:"public"
anyOf:
- child:
method:
annotation:
type:"测试"

我可以再次用changeModifiers动作对类的定义进行修改。

availableFixes:
- name: "Remove @Test class public visibility"
actions:
- changeModifiers:
visibility:""

摘要

一个静态分析工具最初提醒我注意JUnit中推荐的这种方法。但静态分析工具并没有帮助我建立肌肉记忆，在编程时改变我的代码。

使用 "级别 "来提醒你。当它是一个我试图在我的编码中杜绝的问题时，我最初把它定为 "错误"，然后在我放弃编码方法时减少它。

请记住，你可以使用Sensei ，在应用快速修复时使用下拉菜单选项，同时修复当前文件的所有问题。

通过创建一个Sensei ，我可以实时看到我以前的编码方法。而且，如果我在编码中偶尔出现失误，可以快速修复它，以加强该方法。

---

你可以使用 "Preferences \ Plugins"（Mac）或 "Settings \ Plugins"（Windows）从IntelliJ内部安装Sensei ，然后只要搜索 "sensei secure code"。

这方面的源代码和配方可以在Secure Code Warrior GitHub账户的`sensei-blog-examples`仓库中的`junitexamples`模块中找到。

• https://github.com/securecodewarrior/sensei-blog-examples

自动添加一个私有构造函数与Sensei

在一个实用类中，当字段和方法都是静态的时候，没有明显的理由让我把它实例化。

例如，UtilityClass utility = new UtilityClass()。

下面的代码是一个实用程序类的简单实现。

public class UtilityClass {
    public static final Boolean ULTIMATE_TRUTH = true;
    public static boolean getTrue(){
        return ULTIMATE_TRUTH;
    }
}

这是静态分析工具可以发现的编码模式类型，但它们往往不提供修复问题的能力。

我可以使用Sensei 来识别编码模式，并自动生成一个私有构造函数，使我无法实例化该类。

搜索类

我将在公用事业类上添加一个新的配方，名为。

•  静态类：创建私有构造函数。

而最初，我将创建一个简单的匹配器来搜索一个类。

搜索。

  class: {}

这将匹配任何类，这足以让我开始写一个快速修复。一旦我有了一个有效的快速修复方法，我将改进搜索，使其在更有可能出现需要私有构造函数的类时突出显示。

快速修复

对于快速修复，我将希望生成一个私有构造函数。

在示例类中，这将看起来像。

   Private UtilityClass(){}。

为了将上述代码添加到我的类中，我的快速修复将添加一个方法，而该方法的名称将是一个使用类名的Mustache模板。

可用的修复方法。

- name: "add private constructor"
  actions:
  - addMethod:
      method: "private {{{ name }}}(){}"

在GUI编辑器中，我使用显示变量来创建小胡子模板，然后编辑字段，添加私有修饰符、大括号和小括号，使其在语法上正确。

现在，这将允许我在任何类中添加一个私有构造函数。

QuickFix的预览功能对我有帮助，因为我可以在编写Mustache模板时看到生成的代码。

现在我知道我可以解决这个问题了。我将细化搜索条件，在最合适的时候显示食谱。

搜索缺失的结构体

理想情况下，我不希望创建一个对每个类都标记错误的配方。因此，我将在搜索中添加一些额外的条件，以便我们只匹配那些没有构造函数的类。

搜索。

  class:
without:
child:
method:
constructor: true

YAML与GUI略有不同。

在GUI中，我将其配置为寻找一个没有子方法的类，该方法是一个构造函数'yes'。我们在GUI中使用'yes'而不是'true'，以使GUI更加人性化。

这个配方现在只对任何没有构造函数的类显示出来。

缩小搜索范围，寻找可能的肇事者

所以我可能想进一步寻找静态方法或字段的存在。

我寻找任何没有构造函数的类，它有所有公共静态字段或所有公共静态方法。

搜索。

  class:
with:
anyOf:
- child:
method:
allOf:
- modifier:"public"
- 修改器。"static"
- child:
field:
allOf:
- modifier:"static"
- 修饰语："static" "public"
without:
child:
method:
constructor: true

由于Sensei 是用来帮助我这个程序员在IDE中，而不是静态地分析代码和报告所有的错误，这个过滤器足以排除我的代码库中的大多数类，在这些类中我可能有充分的理由拥有一个默认的公共构造函数。

在一些项目中，这可能会走得太远，因为实用类可能有私有方法，所以我可能会选择寻找 "任何 "公共静态方法的存在，而不是 "所有"。

       - 子项：
领域：
anyOf：
- 修饰语。"static"
- 修改器。"公共"

提示

Sensei 不是用来取代静态分析工具的。Sensei 可以增强静态分析工具，以解决与你的编码过程或技术有关的常见问题。通过复制足够的匹配来突出一个问题，并通过生成快速修复代码来支持开发过程。

我想做的是创造一个足够简单的配方，包括我需要的所有情况，但要对它进行过滤，以便它不会在每个班级都被推荐。

在研究配方时，我试图降低它们的风险，在这种情况下，我不确定是否可以创建私有构造函数，所以我先创建了QuickFix。然后重构了搜索条件，使其更加具体。

有时在研究食谱时，我不确定如何进行搜索，所以我先在这方面下功夫。

我发现当我逐步建立配方时，在重构QuickFix和搜索之间切换，更容易创建配方。

---

你可以使用 "Preferences\ Plugins"（Mac）或 "Settings\ Plugins"（Windows）从IntelliJ内部安装Sensei ，然后只需搜索 "sensei secure code"

这方面的源代码和配方可以在Secure Code Warrior GitHub账户的`sensei-blog-examples`仓库中找到，在`pojoexamples`模块中。

https://github.com/securecodewarrior/sensei-blog-examples

‍

Tapjacking，是 "tap "和 "劫持 "的组合，就是这个意思。这是一种攻击，攻击者劫持用户的点击，诱使他做一些他不打算做的事情。那么，它是如何工作的，我们如何防止它？

我们的故事从屏幕覆盖开始。屏幕覆盖，或如谷歌所称，使用TYPE_APPLICATION_OVERLAY类型的窗口。 这些是绘制在其他应用程序之上的窗口，通常只遮挡屏幕的一部分。当一个应用程序请求新的权限时，这些窗口经常被使用（如下面的示例图片）。

这实际上是一个很酷很有趣的功能，越来越多的应用程序开始使用它，想想Facebook的聊天气泡，或者谷歌地图在你屏幕一角的导航，就像下面的截图。

然而，这些覆盖物也存在一些安全风险。任何活动的屏幕叠加都可以监听轻拍，否则Facebook怎么会知道我们轻拍或拖动了泡沫？这使得应用程序可以监视你，并有可能窃取密码和信用卡数据。

再进一步，这就是 "窃听 "一词的由来，覆盖层可以在其他应用程序上绘制东西，欺骗用户执行不同的动作。用户认为他是在与覆盖层互动，但实际上，他的点击也在底层应用中执行动作。这样一来，覆盖层可以欺骗你启用某些权限，或改变一些危险的设置，正如这个古老的YouTube视频所展示的那样。

上面的演示视频是2010年上传到YouTube的，所以是在较早版本的Android上完成的。但这种攻击在今天仍有意义，因为在新版本的安卓系统（如Nougat和Marshmallow）中出现了允许窃取的漏洞。

那么你能做些什么呢？作为一个用户，重要的是意识到这些覆盖的后果，并注意使用它的应用程序。从API级别23（Android 6.0 Marshmallow）开始，这已经成为一个必须由用户明确授予的权限。然而，这使得50%的安卓用户仍然很脆弱。你仍然可以在 "显示在其他应用程序之上 "的设置中检查哪些应用程序使用了这个权限。

作为开发者，我们有责任确保用户的操作是在用户完全知情和同意的情况下进行的。安卓系统为你的视图提供了一个设置，它的作用就是这样，叫做 filterTouchesWhenObscured. 当它被启用时，只要视图窗口被另一个可见窗口遮挡，框架就会丢弃收到的触控。就这么简单，把 filterTouchesWhenObscured 为 "true"，你的应用程序就不会被窃听。

祝您好运，下周见!

有时，应用程序必须能够验证一个行动是在用户完全知情和同意的情况下进行的，如授予许可请求、进行购买或点击广告。不幸的是，一个恶意的应用程序可以通过隐瞒视图的预期目的，试图欺骗用户，使其在不知情的情况下执行这些行动。

https://developer.android.com/reference/android/view/View.html

设备加密是对安卓设备上的所有数据进行加密的过程。一旦为安卓设备启用了这一功能，所有用户创建的数据在被写入存储空间之前就会立即被加密。这就保护了数据，即使任何未经授权的一方试图访问数据，他们也无法读取数据。这对智能手机设备来说是一个特别好的功能，因为这些设备是由用户随身携带的，比其他计算设备更容易丢失或被盗。任何好奇的发现者或小偷都无法访问数据，除非他能解锁手机。

安卓系统有两种类型的设备加密：全磁盘加密和基于文件的加密。

全磁盘加密

全盘加密在API级别19（安卓4.4 KitKat）中引入，但API级别21（安卓5.0 Lollipop）中的新功能真正启动了它的使用。全盘加密使用一个单一的密钥来保护整个设备的用户数据分区。该密钥由用户证书保护，在启动时必须提供这些证书，才能访问磁盘的任何部分。

这对安全来说是很好的，但这也意味着设备的大部分功能在用户输入他们的凭证之前是不可用的。这意味着当设备被重新启动但没有解锁时，一些功能如警报器无法运行，服务不可用，电话也不能接听。由于这个原因，第二种加密模式应运而生。

基于文件的加密

基于文件的加密，是设备加密的第二种模式，从API级别24（Android 7.0 Nougat）开始提供。在这种模式下，不同的文件用不同的密钥进行加密，可以独立解锁。有了这种加密模式，就有了直接启动模式，它允许加密的设备直接启动到锁屏，在解锁设备之前启用以前缺少的功能。

直接启动允许应用程序在设备解锁前在有限的环境中运行。这样一来，它们仍然可以按预期运行，而不会损害用户的信息。为了提供这种功能，安卓设备需要两个存储位置。

1. 凭证加密的存储。默认存储位置，只有在用户解锁设备后才能使用。
2. 设备加密存储。在直接启动模式下，以及在用户解锁设备后可用。

如果你的应用程序在直接启动模式下运行时需要访问数据，它应该使用设备加密存储。但要注意安全问题!设备加密存储不应该被用来存储任何敏感数据!设备加密存储是用一个密钥加密的，一旦设备成功启动，这个密钥就可以使用。任何只能由用户访问的数据都应该保存在默认位置，即凭证加密存储。

如果你想进一步了解什么是加密或为什么它很重要，请查看Secure Code Warrior 门户上的视频。或者你可以尝试通过玩一些挑战来测试你对加密的认识。

你的设备需要一个分步指南吗？请看这篇来自Pixel Privacy的Bill Hess的文章。

我希望你能学到一些新东西。下周见!

凭证加密存储，这是默认的存储位置，只有在用户解锁设备后才能使用。

https://developer.android.com/training/articles/direct-boot.html