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

今週は、Zipライブラリのデフォルト動作についてご紹介します。あなたがアプリケーション開発者であれば、これを使ったことがあるかもしれません。インターネットでダウンロードされるほとんどのリソースはZip形式ですが、これは理にかなっています。圧縮されたデータは小さいので、ダウンロードが速くなり、帯域幅を消費しません。

もっと具体的な例を挙げると、ゲーム用のテクスチャ、キーボードの自動補完用の言語パックなどがあります。多くのリソースは、アプリケーションに自動的にバンドルされておらず、後でダウンロードされます。

しかし、この機能を使用する際には注意が必要です。ZIPアーカイブ内のファイル名には、パストラバーサル情報が含まれていることがあります。これを解凍すると、意図したディレクトリの外にファイルが作成されてしまいます。これは、既存のファイルを上書きする目的で行われることが多いです。

以下の2つのファイルが入ったZIPアーカイブがあったとします。

file1
../file2

このアーカイブを解凍すると、file1は解凍ディレクトリ内の想定した場所に解凍されます。しかし、file2は、zipライブラリにアーカイブの展開を依頼した場所よりも1つ上のディレクトリに書き込まれました。

使用しているZIPライブラリがこのケースを適切に処理していない場合、攻撃者がシステム内に任意のファイルを書き込めるようになってしまうので注意が必要です。ライブラリが安全であるかどうかを常にチェックしてください。この経験則はどのようなライブラリにも有効ですが、特に、この種のファイルに対するzipライブラリのデフォルトの動作をチェックすることをお勧めします。

このケースがAndroidで適切に処理されなかった場合の結果を見てみましょう。Androidでは、Java Zipライブラリ(java.util.zip)が使用されており、このライブラリはデフォルトで上記のようなパストラバーサルを許可しています。

AndroidのDalvik Executable Format（.dex）では、1つのファイルが持てるクラスの数に制限があります。より多くのクラスを必要とするアプリは、APIレベル21（Android 5.0 Lollipop）以降に追加されたMultiDex Supportライブラリを利用することができます。このライブラリは、セカンダリの.dexファイルをアプリケーションのデータディレクトリに保存します。このディレクトリはアプリケーションのユーザーが書き込み可能で、.dexファイルが必要になったときにこのコードが読み込まれて実行されます。

つまり、攻撃者は、悪意のあるZIPアーカイブを使って、.dexファイルを上書きすることで修正することができ、さらに悪いことに、このファイルが読み込まれて実行されることで、リモートコード実行の脆弱性が生じます。これは単なる理論上の例ではなく、アプリストアで1億以上のダウンロード数を誇るアプリ「My Talking Tom」で実証されています。Black Hatで発表されたこのエクスプロイトのビデオをご覧ください。

常にzipライブラリの動作を確認し、その不安要素を把握しておきましょう。お使いの zip ライブラリでパストラバーサルを無効にできない場合は、各エントリの名前を検証してから抽出するようにしてください。名前は正規化されている必要があり、結果として得られるパスはアーカイブを抽出したいディレクトリにある必要があります。ついでに、ZIP爆弾を防ぐために、抽出されたアーカイブの合計サイズもチェックすべきですが、これは別の週の記事にします。

パストラバーサルに関するチャレンジをしてみたい方、セキュアコーディングのスキルを試してみたい方は、私たちのプラットフォームをご覧ください。

また次回、お会いしましょう。そして忘れないでください、安全なコードかコードでないかを

- 名前の前に任意の数の " ../ " が付いたファイルを zip に注入することができます
- zip ライブラリがこのケースを適切に処理するように注意しないと、意図した抽出ディレクトリの外に書き込むことができてしまいます
- zip ファイルが信頼されていない場合、攻撃者に任意の書き込みの脆弱性を与えてしまいます

https://www.blackhat.com/docs/ldn-15/materials/london-15-Welton-Abusing-Android-Apps-And-Gaining-Remote-Code-Execution.pdf

XML（Extensible Markup Language）は、機械にとって扱いやすく、人間にとっても読みやすいフォーマットで文書を符号化するためのマークアップ言語です。しかし、一般的に使用されているこのフォーマットには、複数のセキュリティ上の欠陥があります。XML関連のブログ記事の第1回目となる今回は、スキーマを使ってXML文書を安全に取り扱うための基礎知識を説明します。

OWASP は、XML および XML スキーマに関連するさまざまな脆弱性を 2 つのカテゴリに分けています。

不正なXML文書

不正なXML文書とは、W3CのXML仕様に準拠していない文書のことである。不正なドキュメントになる例としては、終了タグの削除、異なる要素の順序の変更、禁止された文字の使用などがあります。これらのエラーはすべて致命的なエラーとなり、ドキュメントは追加の処理を受けるべきではありません。

不正な文書に起因する脆弱性を回避するためには、W3Cの仕様に準拠し、不正な文書の処理に著しく時間がかからない、十分にテストされたXMLパーサーを使用する必要があります。

無効なXML文書

無効なXML文書は、うまく形成されているものの、予期しない値を含んでいます。ここで、攻撃者は、文書が有効であるかどうかを識別するためのXMLスキーマを適切に定義していないアプリケーションを利用することができます。以下に、正しく検証されなかった場合に意図しない結果をもたらす可能性のある文書の簡単な例を示します。

トランザクションをXMLデータで保存するウェブストアです。

   <purchase></purchase>
     <id>123</id>
     <price>200</price>
   

And the user only has control over the <id> value. It is then possible, without the right counter measures, for an attacker to input something like this:</id>

   <purchase></purchase>
     <id>123</id>
     <price>0</price>
     <id></id>
     <price>200</price>
   

If the parser that processes this document only reads the first instance of the <id> and <price> tags this will lead to unwanted results. </price></id>

また、スキーマの制限が不十分であったり、他の入力検証が不十分であったりして、負の数や特殊な小数（NaNやInfinityなど）、あるいは非常に大きな値が想定外の場所に入力されてしまい、同様の意図しない動作が発生することもあります。

不正なXML文書に関する脆弱性を回避するには、正確で制限のあるXMLスキーマを定義して、不適切なデータ検証による問題を回避する必要があります。

次回のブログ記事では、ジャンボ・ペイロードや、OWASPトップテンの第4位であるXXEなど、XML文書に対するより高度な攻撃を紹介します。

それまでの間、私たちのポータルで、XML入力検証のスキルを磨いたり、挑戦したりすることができます。

XMLおよびXMLスキーマの仕様には、複数のセキュリティ上の欠陥が含まれています。同時に、これらの仕様は、XMLアプリケーションを保護するために必要なツールを提供しています。XML文書のセキュリティを定義するためにXMLスキーマを使用しているにもかかわらず、ファイル検索、サーバサイドリクエストフォージェリ、ポートスキャン、ブルートフォースなど、さまざまな攻撃を行うために使用することができます。

https://www.owasp.org/index.php/XML_Security_Cheat_Sheet

ロギングとモニタリングが不十分な欠陥は、認証の失敗、アクセス拒否、入力検証エラーなどのロギングに関するサイバーセキュリティ計画が失敗した場合に多く発生します。本番環境の他の場所でも発生する可能性がありますが、最も関連性が高いのは、無効なログイン試行を阻止できなかった場合です。

これは、サイバーセキュリティチームが攻撃を知らないため、攻撃に対応できないという意味で、危険な脆弱性です。これは攻撃者にとって大きなアドバンテージとなり、システムへのさらなる侵入や認証情報のアップグレードを試みている間、攻撃者に気づかれずに済むことになります。実際、適切なロギングとモニタリングがなければ、大きな被害が出る前に攻撃を検知して阻止することは非常に難しく、不可能になります。

今すぐチャレンジして自分の実力を試してみませんか？これをチェックしてください。

ロギングやモニタリングが不十分な場合、攻撃者はどのように利用するのでしょうか？

どのようなAPIでも、ログレベルが正しく設定されていなかったり、低く設定されていたり、エラーメッセージに十分な詳細が含まれていなかったり、ログ機能が全く存在していなかったりすると、ロギングやモニタリングが不十分になる恐れがあります。

興味深い例として、ハッカーがあるウェブサイトやサービスの危険なユーザー名のリストを大量に入手した場合が挙げられます。実験の結果、ログインに3回失敗すると、システムからロックアウトされ、サイバーセキュリティ担当者に通知されることがわかりました。

この情報をもとに、単一のアカウントにブルートフォースをかけるのではなく、"123456 "や "password "などの一般的なパスワードを使用して、侵害されたリストのすべてのユーザー名でログインを試みるスクリプトを作成します。その際、ロックアウトやアラートの閾値を下回るように、各ユーザー名を1回または2回だけ試すのがコツです。運が良ければ、少なくとも数個のパスワードをすぐに盗むことができます。その後、ログインカウンターがリセットされるのを1日待って、"qwerty "や "god "などの別のパスワードを使って再度プロセスを実行するだけです。管理者が彼らの行為に気づかなければ、攻撃者はこのリストを何度も確認し、最終的に弱いパスワードを持つほとんどのアカウントを侵害することができます。

OWASP が提供している例では、ある動画共有プラットフォームが、不十分なロギングとモニタリングの脆弱性を悪用したクレデンシャルスタッフィング攻撃を受けたことがあります。この会社は、ユーザーから苦情が来るまで、この攻撃が起こっていることを知りませんでした。最終的には、API ログから証拠を発見し、すべてのユーザーに強制的なパスワード変更の通知を行い、規制当局に攻撃を報告しなければなりませんでした。  

ログ・モニタリングが不十分な脆弱性の解消

自動化と常時監視を行うことで、この脆弱性に終止符を打つことができます。まず、認証に失敗した場合はすべてログに記録する必要があります。そのログは、STIXやTAXIIのような機械で読める形式にして、閾値に関係なく攻撃を探すように訓練されたセキュリティ情報・イベント管理（SIEM）システムに取り込めるようにしておく必要があります。

また、ログファイルの保護も必要です。ログファイルを機密情報として扱い、攻撃者による削除や変更から保護してください。ログファイルのバックアップと暗号化の両方を行うのが良い方針です。

最後に、カスタムダッシュボードとアラートを作成して、疑わしい活動があれば、できるだけ早く検出して対応できるようにします。攻撃者がシステムを使用する時間をなくせば、検知されないように低コストでゆっくりとした攻撃手法を用いることができなくなります。

この脆弱性に関する詳細な情報や、組織やお客様を被害から守る方法については、ブログのページをご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織やお客様を守るための方法をご紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。

2015年以来、私たちは世界中の開発者を対象に、セキュリティに対する積極的で前向きなアプローチを行っています。コードを保護するためのスキルを身につけてもらい、再作業や修正を減らし、セキュリティチームを楽しい警察以外のものとして見てもらえるように支援しています。

私たちは、開発者が銀河系中のコードを安全に保護するために、開発者のそばにいることを約束しています。しかし、そろそろ状況を変えて、戦場で鍛えられたセキュリティ意識の高い開発者を次のレベルに引き上げる時です。

この度、Secure Code Warrior プラットフォームの新機能として、Missions がリリースされました。この全く新しいチャレンジカテゴリーは、開発者によるセキュリティトレーニングの次の段階であり、ユーザーはセキュリティの知識を思い出すことから、実際のシミュレーション環境でそれを適用することになります。

最初にプレイできる公開ミッションは、GitHubのUnicode侵害のシミュレーションです。一見、単純そうに見えますが、実に巧妙な脆弱性であり、解剖するのが楽しいのです。セキュリティ研究者の0xsha氏は、この同じバグが大文字小文字の変換によってDjangoを悪用する方法について包括的なケーススタディを行い、同時に脆弱性の挙動がプログラミング言語によってどのように変化するかを明らかにしました。このセキュリティ問題については、まだまだ多くの発見がありますが、私たちのミッションはその出発点として最適なものです。

GitHubの真っ向勝負（ケースマッピング）の衝突

セキュリティ研究グループのWisdomは、2019年11月28日のブログ記事で、GitHubで発見したセキュリティバグについて報告しました。彼らは、UnicodeのCase Mapping Collisionを利用して、誤ったメールアドレス（攻撃者のように考えれば、脅威主体が選んだメールアドレス）へのパスワードリセットメール配信を引き起こすことができたことを概説しました。

セキュリティの脆弱性は決して良いニュースではありませんが、ホワイトハットのセキュリティ・リサーチャーは、コードベースの中に悪用可能なエラーを発見した場合には、救いの手を差し伸べてくれます（言うまでもありませんが）。彼らのブログやレポートはしばしば素晴らしい読み物となり、新しい脆弱性やその仕組みを知ることはとても素晴らしいことです。

セキュアコーディングの能力を次のレベルに引き上げるためには、一般的な脆弱性（特にクールな新しい脆弱性）を見つけるだけでなく、悪意のある脅威のアクターがこれらの新しい技術を使ってデータを掘り起こすための肥沃な土地を探していることを知っているので、非常に強力な力となります。

では、実際にやってみましょう。UnicodeのCase Mapping Collisionがどのように悪用されるのか、それがリアルタイムでどのように見えるのか、そして、セキュリティ・リサーチャーの心構えを持って、自分で試してみることができるのかをご紹介します。

今すぐCase Mapping Collisionに挑戦してみませんか？ステップアップしてください。

ユニコード。複雑で無限のカスタマイズが可能、そして絵文字だけではない

"ユニコード」という言葉は一般の人には馴染みがないかもしれませんが、ほとんどの人が毎日何らかの形で使っているはずです。WebブラウザやMicrosoftのソフトウェアを使ったことがある人、絵文字を送ったことがある人は、Unicodeを間近で見たことがあるはずです。これは、世界中のほとんどの文字体系のテキストを一貫してエンコードし、取り扱うための規格で、誰もが（デジタル上で）1つの文字セットを使って自分自身を表現できるようにするものです。現在、143,000以上の文字があるので、アイスランド語を使おうが、トルコ語のドットレスを使おうが、その中間の文字を使おうが、問題ありません。

Unicodeには非常に多くの文字が含まれているため、多くの場合、文字を別の「同等の」文字に変換する方法が必要になります。例えば、ドットレスのあるUnicode文字列をASCIIに変換すると、単純に「i」になるのは理にかなっていると思いませんか？

膨大な量の文字をエンコードすることは、大きな災害を引き起こす可能性があります。

Unicodeのケースマッピングの衝突は、ビジネスロジックの欠陥であり、その核心は、2FAで保護されていないアカウントの乗っ取りにつながる可能性があります。問題の脆弱性を説明するために、実際のコードスニペットでこのバグの例を見てみましょう。

app.post(/api/resetPassword, function (req, res) {
  var email = req.body.email;
  db.get(SELECT rowid AS id, email FROM users WHERE email = ?, [email.toUpperCase()],
      (err, user) => {
          if (err) {
              console.error(err.message);
              res.status(400).send();
          } else {
              generateTemporaryPassword((tempPassword) => {
                  accountRepository.resetPassword(user.id, tempPassword, () => {
                      messenger.sendPasswordResetEmail(email, tempPassword);
                      res.status(204).send();
                  });
              });
          }
      });
});

論理的には次のようになります。

1. ユーザーから提供されたメールアドレスを受け取り、一貫性を保つために大文字にします。
2. メールアドレスがすでにデータベースに存在しているかどうかをチェックする
3. もしそうであれば、新しい一時的なパスワードを設定します（ちなみに、これはベストプラクティスではありません。代わりに、パスワードリセットを可能にするトークンを含むリンクを使用してください。)
4. そして、ステップ1で取得したアドレスに、一時的なパスワードを記載したメールを送信します（これは多くの理由から、非常に悪い習慣です。

オリジナルのブログ記事で提供されている例では、ユーザーが電子メール John@GıtHub.com (トルコ語のドットレスiに注意)のパスワードリセットを要求した場合に何が起こるかを見てみましょう。

1. John@Gıthub.com を JOHN@GITHUB.COM に変換するロジックです。
2. それをデータベースで調べて、ユーザー JOHN@GITHUB.COM を見つけます。
3. 新しいパスワードを生成し、それを John@Gıthub.com に送信します。

なお、このプロセスでは、機密性の高いメールを誤ったメールアドレスに送信してしまいます。おっと!

このユニコードの悪魔を追い出すには

この特定の脆弱性の興味深い点は、脆弱性となる要因が複数あることです。

1. 実際のUnicodeキャスト動作
2. データベースに登録されているメールアドレスではなく、ユーザーから提供されたメールアドレスを使用することを決定するロジックです。

理論的には、Wisdomのブログ記事にあるように、この特定の問題を2つの方法で解決することができます。

1. ピュニコード変換でメールをASCIIに変換する
2. ユーザーが入力したメールアドレスではなく、データベースに登録されているメールアドレスを使用する

ソフトウェアを強化する際には、可能な限り多くの防御策を講じてチャンスを逃さないようにすることが大切です。このエンコーディングを悪用する別の方法があるかもしれませんが、それはまだ知られていません。リスクを減らし、攻撃者が開いている可能性のある窓を閉じるためにできることは何でもあります。

自分で試してみませんか？

ほとんどの開発者は、データの漏洩がビジネスに悪影響を及ぼすことを認識しています。しかし、セキュリティを意識したエンジニアは、増大する脆弱性、侵害、サイバーセキュリティの悩みに対する強力な解毒剤となります。

あなたの安全なコーディングと意識向上のスキルを次のレベルに引き上げる時が来ました。このGitHubの脆弱性を、フロントエンドとバックエンドの両方のコンテキストで、悪いコードの影響を見ることができる、没入型の安全なシミュレーションで体験しましょう。攻撃者は有利な立場にいるので、競技場を均等にして、ホワイトハットのカウンターパンチで本物のスキルを適用しましょう。