OWASP の API トップテンに掲載されているほとんどの脆弱性とは異なり、不適切な資産管理は、特にコーディング上の欠陥を中心としたものではありません。むしろ、この脆弱性は、古いAPIをより安全な新バージョンに置き換えるべきだったにもかかわらず、長い間そのままにしておくことを許してしまうような、人的または管理的な問題である。また、開発途中のAPIが脅威に対して完全に強化される前に本番環境にさらされた場合にも発生する可能性がある。

この脆弱性は、マイクロサービスやクラウドコンピューティングの出現により、特に管理が難しくなっています。そのような環境では、一時的なニーズを満たすために新しいサービスがすぐに立ち上げられ、その後は忘れ去られ、廃止されることはないかもしれません。古いAPIが本番環境に接続されたままになっていると、ネットワーク全体を危険にさらすことになります。

このセキュリティバグについて、ゲーム感覚でチャレンジしてみませんか？私たちのアリーナに足を踏み入れてみてください。[Start Here] (ここからスタート)

不適切な資産管理の欠陥は、APIにどのような影響を与えるのでしょうか？

不適切な資産管理という欠陥は、現代の産物です。ビジネスのスピードに追われる組織では、毎日何百、何千ものサービスやマイクロサービスを立ち上げることがあります。これは、付随するドキュメントの作成や、関連するAPIが何に使用されているのか、どのくらいの期間必要とされるのか、その重要性についての説明がないまま、素早く行われることが多い。特に、APIの存続期間を定義する包括的なポリシーがない場合は、時間の経過とともに手に負えなくなる可能性があります。

そのような環境では、いくつかのAPIが失われたり、忘れ去られたり、あるいは廃止されないことも大いにあり得ます。

また、通常のプロセス以外で新しいサービスを作成する権限を持つユーザーにも原因がある場合があります。例えば、マーケティンググループが、製品発表会などのイベントをサポートするためにサービスを作成し、イベント終了後にそのサービスを元に戻さない場合があります。後でそのサービスと関連するAPIを見た人は、なぜそのサービスが存在するのかわからないかもしれませんし、ドキュメントがなければ謎のままかもしれません。そのAPIがどれほど重要なのか、何をしているのかがわからないため、本番環境からそれらのAPIを削除したり、新しいバージョンにアップグレードしたりすることに抵抗を感じるかもしれません。

脆弱性が危険になるのは、フレームワークのAPIのセキュリティが時間とともに向上するからです。研究者が脆弱性を発見したり、最近増えているタイプの攻撃を阻止するために特別なセキュリティが追加されたりすることがあります。古いAPIは、アップグレードされない限り、それらの攻撃に対して脆弱なままであるため、ハッカーはしばしばそれらのAPIを探したり、自動化されたツールを使って探し出したりします。

OWASPが提供している実例では、ある企業がユーザーデータベースの検索に使用するAPIをアップグレードし、重大な欠陥を修正しました。しかし、誤って古いAPIをそのままにしてしまいました。

攻撃者は、新しいAPIの場所が(api.criticalservice.com/v2)のようになっていることに気づきました。このURLを(api.criticalservice.com/v1)に置き換えることで、既知の脆弱性を持つ古いAPIを代わりに使用することができました。この結果、1億人以上のユーザーの個人情報が流出しました。

不適切な資産管理の不備をなくす

不適切な資産管理の欠陥を環境から排除する唯一の方法は、すべてのAPI、その用途とバージョンをしっかりと把握することだ。そのためには、まず既存のAPIのインベントリーを作成し、本番環境や開発環境など、どのような環境にデプロイすべきか、誰がネットワークにアクセスすべきか、そしてもちろんそのバージョンなどの要素に着目する必要がある。

これが完了したら、新しいAPIやサービスが作成された際に、自動的にドキュメントが追加されるプロセスを導入する必要がある。これには、レート制限、リクエストとレスポンスの処理方法、リソースの共有、接続可能なエンドポイント、適用される関連ポリシーなど、APIのすべての側面が含まれており、後の監査に必要なものも含まれている。また、本番環境以外のAPIや開発環境のAPIを本番環境で使用することは避けるべきです。また、自動的に廃止されないように、APIの所有者がその使用を継続することを正当化しなければならない期限を設けることも検討してください。

アクティブなAPIの新しいバージョンが利用可能になるたびに、リスクassessment 、アップグレードすべきかどうかを判断し、本番環境を混乱させないためにそのプロセスをどのように行うべきかを決定する。新しいAPIへの移行が完了したら、古いAPIを環境から完全に削除する。

これらすべてを行うことで、不適切な資産管理の脆弱性が組織、ユーザー、ネットワークに被害を及ぼすことを防ぐことができます。この脆弱性についての詳細は Secure Code Warriorブログでは、この脆弱性や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法について、より詳しい情報を提供しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。

‍

以前のブログ記事では、JavaのGotchaである「Bitwise vs Boolean Operator」について説明しました。

• Java ゴッチャ - ビット演算子とブール演算子

私たちは、この問題のバリエーションと、その他のJavaの問題を加えて、「Challenge TheSensei 」という楽しいクイズを作りました。

• scw.typeform.com/to/rgw7q7OE

上記のブログ記事を読んだ方は、少なくとも1つの質問に答えることができるでしょう。

しかし、あなたの友人はそうではないかもしれません。あなたがこのクイズを楽しいと思ったら、友人と共有して、あなたと同じくらいのスコアを出すかどうかを確認することができます。

単にクイズを出すだけではなく、教育や知識の体系化に役立てたいと考えています。これを利用して、教育や知識の体系化に役立てたいと考えています。そこで、問題と解決策の実行可能なコード例をまとめたGithub repoを作成しました。

• github.com/SecureCodeWarrior/challenge-the。sensei

これは Sensei有効なレポです。

レポをクローンしてIntelliJにロードすると、IntelliJプラグインがインストールされていると仮定して、自動的に.Secure Code Warrior SenseiIntelliJ Pluginがインストールされていると仮定すると、自動的に.sensei フォルダーがあることを認識し、Sensei レシピをロードします。

IDEでコードを閲覧していると、IntelliJがコードにエラーが存在することを確認するプロンプトを表示するはずで、これによりコード内の問題点を簡単に確認することができます。

• ハイライトされたコードの上にカーソルを置くと、エラーを知らせるプロンプトが表示されます。
• Show Context Actionキー：alt+enter (Windows) option+enter (macOS)を使用すると、コードを修正できるQuickFixが用意されている場合があります。

Sensei のレシピが追加されました。

• ビット演算子
• スプリットIPアドレス
• アサートオーダー

今後、レシピや説明文を追加して、コードの残りの部分をカバーする予定ですが、コードを見て自分でエラーを発見することを止めないでください。

そして、クイズに挑戦し、"Challenge theSensei" を忘れないでください。

Java ゴッチャ - ビット演算子とブール演算子

> "Java Gotcha" - 誤って実装してしまいがちなミスパターン。

Javaの簡単な失敗例として、ブール比較演算子の代わりにBitwise演算子を使用することがあります。

例えば、単純なミスタイプで、本当は「&&」と書きたかったのに「&」と書いてしまうことがあります。

コードをレビューするときに学ぶ一般的なヒューリスティックな考え方があります。

条件文の中で「＆」や「｜」が使われている場合は、おそらく意図したものではないでしょう。

このブログ記事では、ヒューリスティックを探り、このコーディング問題を特定して修正する方法を紹介します。

何が問題なのか？ビット演算はブーリアンでも問題なく使える

ビット演算子をブール値で使用することは完全に有効であり、Javaは構文エラーを報告しません。

JUnit Test でビットワイズ OR (|) とビットワイズ AND (&) の真理値表を調べると、ビットワイズ演算子の出力が真理値表と一致することがわかります。このように考えると、Bitwise 演算子の使用は問題ないと思われるかもしれません。

AND真理値表

@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.

問題点短絡動作

実際に問題となるのは、ビット演算子（&, |）とブール演算子（&&, ||）の動作の違いです。

ブール演算子は短絡的な演算子で、必要な分だけ評価します。

e.g.

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

上記のコードでは、ビットワイズ演算子が使用されているため、両方のブール条件が評価されます。

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

これでは、argsがnullの場合にNullPointerExceptionが発生する可能性があります。なぜなら、argsがnullの場合でも、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()

代入文の中でビットワイズ演算子を使って値をマスクすることはよくあるので、このようなコードはコードレビューを通過する可能性があります。しかし、この例では、上記のif文の例と同じ結果になります。intentがnullの場合は、NullPointerExceptionがスローされます。

このような構造になってしまうのは、防御的なコードを書いてしまい、冗長なコードを書いてしまうことが多いからです。!=nullのチェックは、ほとんどのユースケースでは余計なことかもしれません。

これはプログラマーがプロダクションコードで犯したエラーです。

検索結果がどれくらい最新かはわかりませんが、私が検索したときには、Google、Amazon、Apache...そして私のコードが戻ってきました。

私のオープンソースプロジェクトの一つで、最近行われたプルリクエストは、まさにこのエラーに対処するものでした。

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

これを見つけるには

私のサンプルコードをいくつかの静的アナライザーでチェックしたところ、どのアナライザーもこの隠れた自爆コードを拾いませんでした。

Secure Code Warrior のチームとして、これを拾うことができる、かなりシンプルなSensei のレシピを作成し、検討しました。

ビット演算子は完全に有効であり、代入にもよく使用されるため、問題のあるコードを見つけるために、if文の使用例とビット演算子の使用に焦点を当てました。

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

これは、" & " が条件式として使われている場合に、正規表現を使ってマッチさせるものです。

この問題を解決するために、再び正規表現を利用しました。今回は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など、かなりの数のコードウォリアーが協力してくれました。ご協力ありがとうございました。

---

IntelliJの「Preferences ‾ Plugins」（Mac）または「Settings ‾ Plugins」（Windows）から、「sensei secure code」を検索して、「Sensei 」をインストールできます。

Secure Code Warrior GitHub アカウントの `sensei-blog-examples` リポジトリには、これらのブログ記事（今回の記事を含む）のソースコードやレシピが多数用意されています。

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

についてはこちらをご覧ください。Sensei

静的解析とは？

静的解析とは、アプリケーションを実行することなく、ソースコードを自動で解析することです。

プログラムの実行中に解析が行われる場合、それは動的解析として知られています。

静的解析は、検出のためによく使われます。

• セキュリティの脆弱性。
• パフォーマンスの問題。
• 基準への不適合。
• 時代遅れのプログラム構造を使用している。

静的解析ツールはどのように機能するのですか？

すべての静的解析ツールに共通する基本的なコンセプトは、ソースコードを検索して、ある種の警告や情報が関連付けられた特定のコーディングパターンを特定することです。

これは、「JUnit 5のテストクラスは、"public "である必要はない」というような単純なものかもしれません。あるいは、「信頼されていない文字列入力がSQL実行文で使用されている」というような複雑な特定も可能です。

静的解析ツールは、この機能をどのように実装するかが異なります。

• ソースコードの解析技術で、抽象構文木（AST）を作成します。
• テキストの正規表現のマッチングを行います。
• 上記の組み合わせです。

テキストに対する正規表現のマッチングは、非常に柔軟性が高く、マッチングするためのルールを簡単に書くことができますが、多くの誤検出が発生したり、マッチングルールが周囲のコードのコンテキストを無視していたりすることがあります。

ASTマッチングでは、ソースコードを単なるテキストファイルではなく、プログラムコードとして扱います。これにより、より具体的で文脈に沿ったマッチングが可能となり、コードに対して報告される誤検出の数を減らすことができます。

継続的インテグレーションにおける静的解析

静的解析は、継続的インテグレーション（CI）プロセスの中で実行されることが多く、コンプライアンス問題のレポートを作成し、時間の経過とともにコードベースの客観的な見解を得るためにレビューすることができます。

コードの特定の部分のみを測定し、ルールのサブセットのみをレポートするように静的解析ツールを設定することで、コードの品質を客観的に測るために静的解析を利用する人もいます。

使用されるルールは、コードの評価に時間の経過とともに変化することがないため、客観性が保たれます。もちろん、使用するルールの組み合わせとその構成は主観的な決定であり、チームによって異なるルールを使用する場合もあります。

CIで静的解析を行うことは便利ですが、プログラマへのフィードバックが遅れる可能性があります。プログラマーはコーディング時にはフィードバックを受け取りませんが、後からコードを静的解析ツールで実行したときにフィードバックを受け取ります。CIで静的解析を行うことのもう一つの副作用は、結果が無視されやすくなることです。

チームが静的解析の結果にもっと注意を払うようにするには、通常、ビルドプロセスでしきい値メトリックを設定し、メトリックを超えた場合（例えば、いくつかのルールがトリガーされた場合）にビルドを失敗させることができます。

IDEでの静的解析

より早くフィードバックを得るために、要求に応じて、またはコードの変更に応じて定期的に、IDEで静的解析ルールを実行するIDEプラグインが数多くあります。

ルール違反は、プログラマーがコードを書いているときにIDE上で確認することができます。また、ルールを無視しにくくするために、違反箇所がエディタ上で下線付きのコードとして表示されるように設定することもできます。

個人的には、コーディングを改善するのに便利な方法だと思っています。特に、静的解析ツールでカバーされている新しいライブラリを扱うときには、この方法が有効です。ただし、誤検出や興味のないルールなど、「うるさい」こともあります。しかしこれは、特定のルールを無視するように静的解析ツールを設定するという余分なステップを踏むことで解決します。

静的解析ルールに基づいてコードを修正する

ほとんどの静的解析ツールでは、ルールの修正はプログラマーに任されているので、ルール違反の原因を理解し、どのように修正するかを考えなければなりません。

静的解析ツールの中には、違反を修正する機能を備えているものはほとんどありません。なぜなら、修正は、チームや使用している技術、合意しているコーディングスタイルに応じて行われることが多いからです。

デフォルトルール

静的解析ツールにデフォルトのルールが付属していると、プログラマが遭遇する可能性のあるすべての問題と、ルールが適用されるべきすべての状況をカバーしていると信じたくなるため、ルールの品質に対する誤った自信が生じることがあります。ルールが適用されるべき状況は微妙で、簡単には検出できない場合があります。

静的解析ツールを使用し、ルールや違反をより詳細に調査することで、プログラマーが自分の特定のドメインの文脈で問題を検出し、回避するスキルを身につけることを期待しています。

ドメインがコンテキストルールを必要とする場合、静的解析ツールにはドメインやライブラリにマッチするルールがないことがあり、さらにツールの設定や拡張が困難なことがよくあります。

アノニマス

これらの「煩わしさ」はどれも乗り越えられないものではありません。

• 偽陽性
• 修正不足
• ルールを無視する設定
• コンテキスト固有のルールの追加

しかし、これらは、そもそも静的解析ツールの使用を避けるための言い訳として使われることが多く、残念なことに、静的解析の使用は、その方法として非常に有用である。

• 若手開発者へのアプローチを強化
• 明確なコーディング違反に対する迅速なフィードバック
• プログラマーがこれまでに遭遇したことのないような不明瞭な問題を特定する。
• プログラマーが優れたコーディングアプローチを採用していることを補強する（違反が報告されない場合）。

IDEベースの静的解析ツール

プロジェクトの個人的な貢献者として、私は自分のコードに対する迅速なフィードバックを得るために、IDE内で実行される静的解析ツールを使いたいと思っています。

これは、プロジェクトが持つプルリクエストのレビュープロセスやCIの統合を補完するものです。

私は、自分の強みとなるツールを見つけ出し、個々のワークフローを改善するようにしています。

IDEで動作するツールは、基本的なGUIや設定方法が同じであるため、互換性があると考えてしまいがちです。

ツールの機能やルールセットは重複していることもありますが、最大限の効果を得るために、複数のツールをインストールしてそれぞれの強みを活かしています。

私がコーディングの際に積極的に使用している静的解析用のIDEツールは以下の通りです。

• 内蔵されたIntelliJ Inspections - 一般的なコーディングパターン
• SpotBugs - 一般的なエラー
• SonarLint - 一般的な使用パターン
• CheckStyle - よくあるスタイルパターン
• Sensei fromSecure Code Warrior - カスタムルールの作成

私がこれらを使用しているのは、それぞれがお互いを補強し、補うためにうまく機能しているからです。

IntelliJ Inspections

IntelliJをお使いの方は、すでにIntelliJのインスペクションをお使いだと思います。

これらは、IDEでフラグが立てられた静的解析ルールです。その中には、問題に対処するためにコードを書き換えるQuickFixオプションもあります。

ルールはオン・オフの設定が可能で、使用するエラーレベルを選択すると、IDEでハイライト表示されます。

良いIntelliJ Inspectionsはたくさんあります。これを書きながら、それらに目を通したからです。私はIntelliJ Inspectionsをデフォルトで使用しており、それらを設定していませんが、Inspectionsから最大限の価値を得るためには、それらに目を通し、自分のコーディングスタイルに関連するものを特定し、コード内でそれらに気づくように警告レベルを設定する必要があります。

IntelliJ Inspectionsの素晴らしい点は、IDEに無料で付属しており、マッスルメモリーを構築するのに役立つということです。

• コードを書くときにソースの警告やエラーに気づくことができる
• フラグのついたコードにマウスを合わせると、ルール違反を知ることができます。
• alt+enterで問題のQuickFixを適用する。

SpotBugs

SpotBugsIntelliJプラグインは、スタティック解析を使用して、コードのバグを警告します。

SpotBugsはIntelliJ Preferencesからコードをスキャンするように設定でき、実際に使用されるルールはDetectorタブで確認できます。

私は、コードを書いてレビューした後にSpotBugsを使うことが多いのですが、その際には「Analyze Project Files Including Test Sources」を実行します。

これは、バグや死んだコード、明らかな最適化などを特定するのに役立ちます。また、何をすべきかを判断するために、指摘された違反行為について調べざるを得ないこともあります。

SpotBugsは問題を発見しますが、問題解決のためのQuickFixアクションは提供しません。

SpotBugsは設定が簡単で、私のIDEで参考になる客観的なセカンドオピニオンとして重宝しています。

ソナーリント

SonarLintプラグインです。

SonarLintはIntelliJ Preferencesから設定することができ、コードを検証するルールを選択することができます。

デフォルトでは、SonarLintはリアルタイムで実行され、編集中のコードの問題を表示します。

SonarLintは迅速な解決策を提供するものではありませんが、違反レポートに関連する文書は通常、明確であり、十分な文書化がなされています。

これまでもSonarLintは、新しいバージョンのJavaの機能を知らせてくれる便利な存在でした。

チェックスタイル

CheckStyleプラグインでは、フォーマットとコード品質のルールを組み合わせて提供しています。

CheckStyleプラグインには、「Sun Checks」と「Google Checks」が同梱されています。

これらの定義は、インターネットで簡単に調べることができます。

CheckStyleが最も価値を発揮するのは、プロジェクトが時間をかけて独自のルールセットを作成したときだ。そして、IDEプラグインがそのルールセットを使用するように設定し、プログラマはコードをCIにコミットする前にスキャンを実行することができる。

CheckStyleは、CIプロセスにおいて、CheckStyle違反の数が閾値を超えた場合に、ビルド失敗のプラグインとして使用されることが非常に多い。

Sensei

Senseiは、AST（Abstract Syntax Tree）をベースにした静的解析を用いてコードを照合し、QuickFixを作成します。

例えば、新しいクラスをコードに追加した場合、そのクラスのインポートはソースファイルに一度だけ追加され、置換ごとに追加されることはありません。

Sensei は、他のツールでは存在しない、あるいは設定が難しいカスタムマッチングルールを簡単に構築するために作られました。 

設定ファイルを修正するのではなく、すべての設定をGUIで行うことができます。新しいレシピを作成する際には、そのレシピがどのコードにマッチするかをGUIで簡単に確認することができます。また、QuickFixを定義する際には、コードの修正前と修正後の状態をすぐに比較することができます。これにより、チームや技術、さらには個々のプログラマーに固有のレシピなど、非常に文脈に沿ったレシピを簡単に作成することができます。

私はSensei を他の静的解析ツールと組み合わせて使用しています。例えば、ほとんどの静的解析ツールは問題を発見しますが、修正することはできません。Sensei の一般的な使用例は、他のツールの一致する検索をSensei で再現し、クイックフィックスでそれを拡張することです。これには、適用されるカスタム修正が、プロジェクトのコーディング標準をすでに満たしているという利点があります。

私は定期的に、Intensionレポートが私が作成したコンテキストに全くマッチしていなかったり、IntelliJが提供するQuickFixが私が使用したいコードパターンにマッチしていなかったりするために、IntelliJ Intensionsセットに既に存在するSensei レシピを作成することがあります。

私は既存のツールを完全に置き換えようとするのではなく、既存のツールを補強します。

Sensei は、一般的なルールの文脈上のバリエーションを特定する場合にも非常に便利です。例えば、静的解析ツールでサポートされていないSQLライブラリを使用しているが、静的解析エンジンの一般的なSQLルールがまだ適用される場合、Sensei を使用して、これらのルールのライブラリ固有のバリエーションを作成することができます。

Sensei は、前述の静的解析ツールのように多くの一般的なレシピが用意されているわけではなく、特定のコーディングスタイルやユースケースに合わせて設定されたQuickFixを備えた新しいレシピを簡単に作成できることが強みです。

注：一般的な使用例をカバーするレシピの公開を目指しています。 ここで見つけることができます。.

概要

私は、一緒に機能し、設定が可能で、自分の特定の状況に合わせて簡単に拡張できるツールを選ぶ傾向があります。問題を特定したり、使用しているプログラミング言語やライブラリについて詳しく知るために、IDEの静的解析ツールを何年も使用してきました。

私は前述のツールをすべて組み合わせて使っています。

• IntelliJ Intentionsは、一般的なコードの問題にフラグを立て、しばしば関連するQuickFixを提供します。
• SpotBugsは、私が見落としていたかもしれない簡単なバグを見つけ、パフォーマンスの問題を知らせてくれます。
• SonarLintは、私が気づいていなかったJavaの機能を特定し、コードをモデリングするための新たな方法を提案してくれます。
• CheckStyleは、CIの際にも強制される、合意されたコーディングスタイルに適合させるのに役立ちます。
• Sensei は、静的解析ツールで見つかった一般的なシナリオを補強するQuickFixの作成や、他のツールでは設定が難しい特定のプロジェクトや技術のレシピの作成に役立ちます。

---

IntelliJの「Preferences ŌPlugins」（Mac）または「Settings ŌPlugins」（Windows）から、「sensei secure code」を検索して、「Sensei 」をインストールします。

Secure Code Warrior GitHub アカウントの `sensei-blog-examples` プロジェクトには、一般的な使用例を示すサンプルコードやレシピが格納されています。

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

についてはこちらをご覧ください。Sensei

Sensei プロジェクト自体にも、時間をかけて構築された独自のレシピがあります。このブログ記事は、Sensei チームがレシピを構築したシナリオの一つの例です。Guiceの設定ミスにより、テスト時にランタイムでNullPointerExceptionが報告されてしまいました。

これは、コードが構文的には正しくても、配線の構成が間違っていたためにエラーが出てしまうという、多くのDependency Injectionのシナリオに一般化できます。

これは技術を学んでいるときによく起こることで、配線を忘れてしまうという単純なミスを繰り返してしまいます。しかし、これは経験豊富なプロにも起こることで、まあ...誰でもミスをするし、すべてをカバーするユニットテストを持っていないかもしれません。

不適切な依存性注入の配線によるランタイム例外

以下のコードは、実行時に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クラス自体はpackage privateです。

複雑なコードベースでは、これはコードが間違っているという警告サインになるかもしれません。というのも、バインディングを設定するモジュールクラスが同じパッケージになければ、この機能は働かないからです。

‍

class CountReporter {
    @Inject
    private static ILineReporter reporter;

もう一つのミスは、コードレビューで指摘されたかもしれませんが、SystemOutModuleのconfigureメソッドで実際にフィールドをバインドすることを忘れてしまったことです。

binder().requestStaticInjection(CountReporter.class);

もしrequestStaticInjectionのコードを書いていたら、CountReporterを使おうとしたときに発生したSyntax Errorが、単純なエラーを警告してくれたでしょう。

reporters.CountReporter」は「reporters」では公開されていません。外部のパッケージからはアクセスできません。

‍

悲しいことに。私たちは忘れていて、コードには構文上の警告表示がありませんでした。

Sensei はどのように役立つのでしょうか？

Sensei というのも、Guiceのすべての設定配線がこのメソッドを使用する必要があり、すべての配線がこの使用例のように単純であることを保証できないからです。

Sensei のルールを書いて、コードに問題があることを示すいくつかの警告サインを探すことができます。

この場合、それはつまり

• Injectアノテーションされたフィールドを持つクラスの検索
• クラスが公開されていないところ。

以上のことから、配線がされている可能性は低いという警告が出ていた。

レシピを作成することで、コーディング中の早い段階で警告のサインを出すことができ、プルリクエストや技術的負債を解決してユニットテストを追加できるようにすることへの依存度を減らすことができます。

レシピの作成方法は？

私が完成させたい課題は

• 保護されたプライベートクラスにある@Injectでアノテーションされたフィールドにマッチするレシピを作成します。

これで、これを使用しているモジュールを特定し、不足している配線コードを追加するための十分な警告が得られると思います。

私のCountReporterクラスでは、Alt+Enterで新しいレシピを作成し、最初から始めることにします。

これに名前をつけて説明を加えます。

名前ガイス。Injected Field Not Public
説明。Injectedフィールドが公開されていない場合、コードが配線されていない可能性があります。
Level:警告

私が書いた検索は、Injectとしてアノテーションされたフィールドを持つクラスを探しますが、それはpublicとしてスコープされていません。

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

修正

レシピのQuickFixでは、スコープを変更することで注入されたクラスを修正します。しかし、変更しなければならないコードはそれだけではありません。

availableFixes:

- name: "Change class to public.Remember to request injection on this class"
アクション:
- 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 、問題の検出と修正に関する知識を体系化することができます。そうすれば、コードレビューを通過して本番に入ってしまうこともなくなるでしょう。

私たちが書くレシピは、ヒューリスティックなパターンを識別することがあります。つまり、それらを照合しても問題があるとは限らず、問題がある可能性が高いのです。

また、私たちが書くレシピやQuickFixは、完全に網羅されている必要はありませんが、複雑になりすぎず、問題の特定や解決に役立つ程度のものである必要があります。なぜなら、複雑になりすぎると、理解するのが難しくなり、維持するのも難しくなるからです。

---

IntelliJの「Preferences ‾ Plugins」（Mac）または「Settings ‾ Plugins」（Windows）から、「sensei secure code」を検索して、「Sensei 」をインストールすることができます。

この記事のソースコードとレシピは、Secure Code Warrior GitHub アカウントの `sensei-blog-examples` リポジトリの `guiceexamples` モジュールにあります。

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

についてはこちらをご覧ください。Sensei

JUnit 5 のメソッドとクラスの可視性の変更

プログラミングの楽しさの1つは、常に最新の状態を保つために必要な学習です。Sensei は、非推奨のパターンを特定し、今後使用するための修正方法を提示することで、移行を支援します。

例えば、JUnit 4からJUnit 5に移行したとき、私はテストクラスやメソッドをすべてpublicに書くことに慣れていました。しかし、JUnit 5では、それらをパッケージ・プライベートにすることができます。

e.g. instead of:

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

本当は書きたいんだけどね。

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

このようにコーディングするためのマッスルメモリーを構築するのに時間がかかり、今でもたまに失敗することがあります。

使用方法Sensei

Sensei を使えば、パブリックなメソッドやクラスを見つけて、宣言をパッケージ・プライベートに自動的に修正するレシピを作ることができます。

そのために、私はレシピを作りました。

名前 - JUnit:JUnit 5 test methods do not need to be public
説明 - JUnit 5 test methods do not need public visibility
レベル - エラー

私は、このコーディング手法を根絶したいと考え、IDEでコードを書いているときにこの問題をより明確にしたいと考え、この問題をErrorに分類しました。

クラス宣言の修正

クラスを見つけるために、私はJunit 5の@Testの子アノテーションを持つすべてのクラスを検索します（org.junit.jupiter.api.Testなど）。

そして、そのクラスが修飾子 public を持つ場合。

search:
class:
with:
child:
annotation:
type:"org.junit.jupiter.api.Test"
modifier:"public"

そして、クイックフィックスでは、モディファイアを変更して可視性を取り除き、デフォルトにします。

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

メソッド宣言の修正

メソッド宣言の修正レシピは、クラスのレシピとほぼ同じです。

まず、JUnit 5の@Testでアノテーションされたパブリックメソッドを探します。

search:
method:
annotation:
type:"org.junit.jupiter.api.Test"
modifier:"public"

そして、モディファイアをデフォルトの可視性に変更します。

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

ヒント：複数のメソッドを修正する

Sensei は、現在のファイルのすべての違反にQuickFixを適用する機能を持っています。

alt+enterでQuickFixを適用した場合。

QuickFixの名前のメニューを展開すると、以下のようなオプションがあります。

"Fix All: 'JUnit:JUnit 5 test methods do not need to be public "の問題をファイルに記載"

このオプションを選択すると、Sensei は、私が選択したものだけでなく、すべての問題の発生を修正します。

クラスの修正

メソッドがパブリックである必要がないのと同じように、クラスもパブリックである必要はありません。

レシピとQuckFixを作成してクラスを修正することができます。

名前 - JUnit:Junit 5 Test classes do not need to be public
説明 - Junit 5 Test classes do not need to be public
レベル - エラー

公開されているクラスで、@Testアノテーションが付いたメソッドを見つけたとき。そして、可視性を変更したいと思います。

search:
class:
modifier:"public"
anyOf:
- child:
method:
annotation:
type:"Test"

再びchangeModifiersアクションでクラス定義の変更を行うことができます。

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

概要

静的解析ツールは、当初、JUnitのこの推奨されるアプローチを警告してくれました。しかし、静的解析ツールでは、プログラミング中に自分のコードを変更するための筋肉の記憶を作ることはできませんでした。

レベル」を使って警告します。コーディングで解決しようとしている問題の場合、最初は「エラー」にして、コーディングのアプローチから自分を解放していくように、このレベルを下げていきます。

なお、Sensei は、QuickFix を適用する際にドロップダウンメニューオプションを使用することで、現在のファイルのすべての問題を同時に修正することができます。

Sensei レシピを作成することで、これまでの自分のコーディング手法をリアルタイムで確認することができます。そして、たまにコーディングに失敗しても、そのアプローチを強化するためにQuickFixすることができます。

---

IntelliJの「Preferences ‾ Plugins」（Mac）または「Settings ‾ Plugins」（Windows）から、「sensei secure code」を検索して、「Sensei 」をインストールすることができます。

このためのソースコードとレシピは、Secure Code Warrior GitHubアカウントの`sensei-blog-examples`リポジトリの`junitexamples`モジュールにあります。

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

でプライベートコンストラクタを自動的に追加します。Sensei

ユーティリティクラスでは、フィールドやメソッドがスタティックである場合、インスタンス化する理由は明らかではありません。

例：UtilityClass utility = new UtilityClass();

以下のコードは、Utilityクラスの簡単な実装です。

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

このようなコーディングパターンは、静的解析ツールが拾い上げることができますが、問題を解決する能力は供給されないことが多いです。

Sensei を使ってコーディングパターンを特定し、プライベートコンストラクタを自動的に生成して、私がそのクラスをインスタンス化できないようにすることができます。

クラスを検索する

ユーティリティクラスに新しいレシピを追加します。

•  スタティッククラス：プライベートコンストラクタの作成

そして最初は、クラスを検索するためのシンプルなマッチャーを作ります。

の検索を行います。

  class: {}

これはどんなクラスにもマッチするので、クイックフィックスを書き始めるには十分です。うまくいくクイックフィックスができたら、プライベートコンストラクタを必要とするクラスがある可能性が高いときに、検索がハイライトされるように改良してみます。

クイックフィックス

クイックフィックスでは、プライベートコンストラクタを生成したいと思います。

例のクラスでは次のようになります。

   private UtilityClass(){}。

上記のコードを自分のクラスに追加するために、私のQuick FixはMethodを追加し、メソッドの名前はクラスの名前を使用したMustacheテンプレートにします。

availableFixes:

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

GUI Editorでは、Show Variablesを使ってMustacheテンプレートを作成し、フィールドを編集してprivate modifier、brackets、bracesを追加して、構文的に正しいものにしています。

これで、どのクラスにもプライベートコンストラクタを追加できるようになりました。

QuickFixのプレビューでは、Mustacheのテンプレートを書きながら、生成されたコードを確認できるので助かります。

これで問題を解決することができました。最適なタイミングでレシピが表示されるように、検索条件を改良してみます。

欠落したコンストラクタの検索

理想的には、すべてのクラスに対してエラーのフラグを立てるようなレシピは作りたくありません。そこで、検索条件を追加して、コンストラクタを持たないクラスにのみマッチするようにします。

の検索を行います。

  class:
without:
child:
method:
constructor: true

YAMLはGUIとは若干異なります。

GUIでは、コンストラクタの'yes'である子メソッドのないクラスを探すように設定しています。GUIでは'true'の代わりに'yes'を使うことで、少しでも人間に優しいGUIを実現しています。

このレシピは、コンストラクタを持たないクラスに対してのみ表示されます。

原因となりそうなものを絞り込む

そこで、さらに踏み込んで、静的なメソッドやフィールドの存在を確認したいと思います。

コンストラクタのないクラスで、すべてのパブリックスタティックフィールドまたはすべてのパブリックスタティックメソッドを持つクラスを探します。

の検索を行います。

  class:
with:
anyOf:
- child:
method:
allOf:
- modifier:"public"
- modifier:"static"
- child:
field:
allOf:
- modifier:"static"
- modifier:"public"
without:
child:
method:
constructor: true

Sensei は、コードを静的に分析してすべてのエラーを報告するのではなく、プログラマーである私を IDE で支援するために使用されているので、このフィルタは、私のコードベースでデフォルトのパブリック コンストラクタを持つ正当な理由があるほとんどのクラスを除外するのに十分です。

プロジェクトによっては、ユーティリティークラスがプライベートメソッドを持っている可能性があるので、「すべて」ではなく「任意の」パブリックスタティックメソッドの存在を探すことにするかもしれません。

       - 子：
フィールド：
anyOf：
- 修飾語。"static"
- 修飾子。"public"

ヒント

Sensei は、静的解析ツールを置き換えるためのものではありません。Sensei は、コーディングプロセスや技術に関連する一般的な問題に対して、静的解析ツールを補強することができます。問題を浮き彫りにするのに十分なマッチングを再現し、QuickFixコードを生成することで開発プロセスをサポートします。

私がやろうとしているのは、必要な場面をすべて含んだシンプルなレシピを作ることですが、すべてのクラスで提案されないようにフィルタリングすることです。

今回の場合、プライベートコンストラクタを作成できるかどうかわからなかったので、まずQuickFixを作成しました。その後、検索条件をより具体的にするためにリファクタリングを行いました。

レシピを作るときに、検索の仕方がよくわからないことがあるので、まずそれを解決します。

レシピは、QuickFixのリファクタリングと検索を切り替えながら、段階的に構築していくと作りやすいですね。

---

IntelliJの「Preferences ‾ Plugins」（Mac）または「Settings ‾ Plugins」（Windows）から、「sensei secure code」を検索して、「Sensei 」をインストールできます。

このためのソースコードとレシピは、Secure Code Warrior GitHub アカウントの `sensei-blog-examples` リポジトリの `pojoexamples` モジュールの中にあります。

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

‍

タップジャッキングとは、「タップ」と「ハイジャック」を組み合わせた言葉で、まさにその意味です。攻撃者がユーザーのタップを乗っ取り、意図しないことをさせる攻撃です。では、どのような仕組みで、どのようにして防ぐことができるのでしょうか。

まず、スクリーンオーバーレイについて説明します。スクリーンオーバーレイとは、Googleでは「TYPE_APPLICATION_OVERLAY」タイプのウィンドウと呼ばれています。 これは、他のアプリの上に描画されるウィンドウで、通常は画面の一部が見えなくなるだけです。これらは、アプリが新しい許可を要求するときに（下の画像の例のように）よく使用されます。

Facebookのチャットバブルや、Google Mapsのナビゲーションが画面の隅に表示されるなど、この機能はクールで楽しいもので、ますます多くのアプリケーションで採用されています。

しかし、これらのオーバーレイには、いくつかのセキュリティリスクがあります。アクティブなスクリーンオーバーレイは、タップの音を聞くことができ、私たちがバブルをタップしたりドラッグしたりしたことをFacebookが知ることはできません。これにより、アプリがあなたを監視し、パスワードやクレジットカードのデータを盗む可能性があります。

さらに、タップジャッキングという言葉があるように、オーバーレイは他のアプリの上に何かを描き、ユーザーを騙して異なるアクションを実行させることができます。ユーザーはオーバーレイとインタラクトしていると思っていますが、実際には、ユーザーのタップは下にあるアプリのアクションを実行しています。このようにして、オーバーレイはユーザーをだまして、特定の許可を有効にしたり、危険な設定を変更したりすることができます。この古いYouTubeのビデオでは、その様子が示されています。

上のデモンストレーションビデオがYouTubeにアップロードされたのは2010年のことなので、古いバージョンのAndroidで行われています。しかし、NougatやMarshmallowなどの新しいバージョンのAndroidでタップジャックを可能にする脆弱性が明らかになったため、この攻撃は現在でも有効です。

では、どうすればいいのでしょうか？ユーザーとしては、これらのオーバーレイがもたらす結果を認識し、それを使用するアプリに注意することが重要です。APIレベル23（Android 6.0 Marshmallow）の時点で、この機能はユーザーが明示的に許可しなければならないものになりました。しかし、これではAndroidユーザーの50％がまだ脆弱であると言えます。どのアプリがこの許可を利用しているかは、設定の「他のアプリよりも表示」で確認することができます。

開発者は、ユーザーのアクションがユーザーの完全な知識と同意に基づいて行われることを確認する義務があります。Androidでは、それを実現するための設定をビューに用意しています。 filterTouchesWhenObscured. この設定を有効にすると、ビューのウィンドウが他の可視ウィンドウによって隠された場合、フレームワークは受信したタッチを破棄します。これはとても簡単なことです。 フィルタータッチズウィン・オブスキュア を true に設定すれば、アプリはタップジャッキングから安全になります。

頑張ってください。また来週お会いしましょう

時には、許可要求の承認、購入、広告のクリックなど、ある行為がユーザーの完全な知識と同意に基づいて実行されていることを、アプリケーションが確認することが不可欠な場合があります。残念ながら、悪意のあるアプリケーションは、表示の意図された目的を隠すことで、ユーザになりすまして無意識にこれらのアクションを実行させようとする可能性があります。

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

デバイス暗号化とは、Androidデバイス上のすべてのデータを暗号化するプロセスです。Android端末でこの機能を有効にすると、ユーザーが作成したすべてのデータは、ストレージに書き込まれる前に直ちに暗号化されます。これにより、権限のない第三者がデータにアクセスしようとしても、データを読み取ることができないようにデータが保護されます。スマートフォンは、他のコンピュータ機器に比べて紛失や盗難に遭いやすいため、この機能は特に有効です。スマートフォンのロックを解除しない限り、好奇心旺盛な発見者や泥棒はデータにアクセスできません。

Androidでは、デバイスの暗号化として、「フルディスク暗号化」と「ファイルベース暗号化」の2種類があります。

フルディスクの暗号化

フルディスク暗号化は、APIレベル19（Android 4.4 KitKat）で導入されましたが、APIレベル21（Android 5.0 Lollipop）の新機能により、本格的に利用されるようになりました。フルディスク暗号化は、1つの鍵を使ってデバイスのユーザーデータ・パーティション全体を保護します。鍵はユーザーの認証情報とともに保護され、ディスクのどの部分にもアクセスできるようにするには、起動時に認証情報を提供する必要があります。

これはセキュリティ上は素晴らしいことですが、ユーザーが認証情報を入力するまで、デバイスのほとんどの機能が利用できないことを意味します。つまり、ロックが解除されていない状態でデバイスが再起動されると、アラームなどの一部の機能が動作しなかったり、サービスが利用できなかったり、電話が受けられなかったりするのです。このような理由から、2つ目の暗号化モードが作られました。

ファイルベースの暗号化

デバイス暗号化の2番目のモードであるファイルベースの暗号化は、APIレベル24（Android 7.0 Nougat）から利用可能です。このモードでは、異なるファイルが異なる鍵で暗号化され、それぞれ独立してロックを解除することができます。この暗号化モードに伴い、暗号化されたデバイスがロック画面に直接起動し、デバイスのロックを解除する前にこれまで欠けていた機能を有効にすることができる「ダイレクトブート」モードが登場しました。

Direct Bootは、デバイスのロックが解除される前に、アプリが限られたコンテキスト内で動作することを可能にします。これにより、ユーザー情報を損なうことなく、期待通りの機能を発揮することができます。この機能を提供するために、Android端末には2つのストレージが必要です。

1. クレデンシャル暗号化ストレージ。ユーザーがデバイスのロックを解除した後にのみ利用できる、デフォルトの保存場所。
2. デバイス暗号化ストレージ。ダイレクトブートモードで、ユーザーがデバイスのロックを解除した後に利用可能。

Direct Bootモードで実行中にアプリがデータにアクセスする必要がある場合は、「デバイス暗号化ストレージ」を使用する必要があります。ただし、セキュリティ上の問題に注意してください。デバイス暗号化ストレージは、機密データの保存には使用しないでください。デバイス暗号化ストレージは、デバイスが正常に起動するとすぐに利用可能なキーで暗号化されます。ユーザーのみがアクセスできるデータは、デフォルトの場所であるクレデンシャル暗号化ストレージに保存する必要があります。

暗号化とは何か、なぜ暗号化が重要なのかについて詳しく知りたい方は、Secure Code Warrior ポータルのビデオをご覧ください。また、暗号化に関する知識を試すために、いくつかの課題に挑戦してみてはいかがでしょうか。

あなたのデバイスのためのステップバイステップのガイドが必要ですか？Pixel PrivacyのBill Hess氏の記事をご覧ください。

何か新しいことを学んでいただけたでしょうか。また来週お会いしましょう

クレデンシャル暗号化ストレージ：デフォルトのストレージの場所で、ユーザーがデバイスのロックを解除した後にのみ利用できます。

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