[戻る]

Java読書会BOF「セキュア・バイ・デザイン」を読む会 第3回

開催概要

日時

2022年9月17日 10:00 - 17:00

場所

川崎市教育文化会館 第3会議室

出席者(敬称略)

高橋(徹)、高橋(智)、根本、遠藤、平山、吉本、岩室、石黒、加藤

第4章 安全性を確立する実装テクニック

4.1 不変性 (immutability)

4.1.1 一般的な通販サイトの例

注釈

本日は、p.129 の Customer クラスの設計から

  • (雑談) Java 19 の Virtual Threads が気になる

    • 軽量スレッドの一種のようだ

  • p.129 ロックの "開放" は "開放" か "解放" か

    • どちらとも言い切れなさそうだから間違いではなさそう

  • p.133 今の Java なら不変クラスの実装に Record Class を使うのも良さそう

  • p.137 リスト4.5 > -1 って条件は違和感がある、普通は >= 0 だと思う

    • 英語圏は greater than or equal より greater than を好むんだろうか

    • int でも float でも意味が変わらないような条件式のほうが好ましいように感じる

4.2 契約 (contract) を使った速やかな失敗 (fail-fast)

  • p.139 Hoare 卿といえばクイックソートも有名

  • p.142 事前条件といえば Java には昔 assert が導入されたけれどすっかり廃れてしまった

    • デフォルトで適用されないと普及しづらい

    • セキュアコーディングの観点では、いかなる場合でも事前条件はチェックすべき

    • Go でもエラーハンドリングの手抜きを防ぐためアサーションを導入していない

4.2.1 メソッドの引数に対する事前条件の確認

  • p.144 リスト4.7 NullPointerException にもメッセージ入れてほしい

  • p.145 不正データをログに吐くとどんな脆弱性になるか

    • ログを画面に表示するとかだと XSS 攻撃などができてしまうリスクがある

      • ログを見る側の問題のような気もするけれど、予めリスクを排除しておきたいということか

  • p.146 TIP null を防ぐなら @NonNull, @NotNull アノテーションみたいな方法もある

    • Android Studio みたいな静的解析をみんな使えるエコシステムがないと難しいのかも

4.2.2 コンストラクタでの不変条件 (invariant) の確認

4.2.3 オブジェクトの状態の確認と速やかな失敗 (fail-fast)

4.3 妥当性確認 (validation)

4.3.1 オリジン (発生源) の確認

  • p.153 ボットネットのレンタルサービスがあるとは

    • もしこれを使ったら不正アクセス禁止法に引っかかるのだろうか

  • p.154 連携システムの IP アドレスがわからないと IP 制限がしずらくて困る

    • 次の節のアクセス・キーを使うしかない

  • p.155 Authorization の読みはオーソリゼーションかオーソライゼーションか

    • US 英語: オーソリゼイシュン

    • UK 英語: オーソライゼーション

  • p.155 S3 のアクセスキー作るの大変そう

    • openssl と date コマンドがあれば SDK や CLI がなくても作ることができるが、少し面倒

4.3.2 データ・サイズの確認

  • p.158 リスト4.14 import が import static になっていない → 誤植だろうが、他のページのコードリストでも割と頻繁に見かける

  • p.158 リスト4.14 inclusiveBetween を使っているが、 isbn.length() が 10 か確認するだけで良いのではなかろうか

    • 将来 10 から 13 になることを想定しているのか？でも 11 や 12 は不正にしたいはずだ

    • inclusiveBetween を使うとエラーメッセージがより具体的になるのかも

  • p.159 計算量の多い正規表現は容易に作れてしまうので、事前の長さチェックは確かに有用そう

4.3.3 字句的内容 (lexical content) の確認

  • p.163 メールアドレスの最大桁数はいくつにすればいいのか・・・

    • 正規表現も何パターンかあって大変

    • Gmail のプラスエイリアスがはじかれたりとか・・・

      • Microsoft 365 も4月からプラスエイリアスがデフォルトで有効になった

4.3.4 構文 (syntax) の確認

  • p.164 リスト4.19 途中から matchPattern 使うの諦めて isTrue になっている

    • 第2引数 (message) のない isTrue は例外が出たとき意味がわからなくなりそう

4.3.5 データに対する意味 (semantics) の確認

まとめ

第5章 ドメイン・プリミティブ (domain primitive)

5.1 ドメイン・プリミティブ (domain primitive) と不変条件 (invariant)

5.1.1 ドメイン・モデルにおける最小の構成要素としてのドメイン・プリミティブ

  • p.173 リスト5.1 の public int value() は何に使うのか

    • これを使って得た int 値を計算に使われてしまったら元も子もない

    • 最終的に値を表示したいとき限定だろうか

    • データベースに格納するときは？API で JSON にするときは？

      • シリアライザー・デシリアライザーをドメインプリミティブに実装する？

    • いくらドメイン駆動設計できれいな世界を作っても、結局は外に出るときに生の値が露出するのは避けられない

  • p.173 「ドメイン・プリミティブ」と「値オブジェクト」の違いは、不変条件の確認の有無だけ？

    • 常識的には値オブジェクト作るときコンストラクタで不変条件のチェックもするだろう、わざわざ「ドメイン・プリミティブ」という別の用語を導入する意味は？

    • ことさら強調している不変性についても、元々の値オブジェクトの特徴に含まれるので、「ドメイン・プリミティブ」で付加された概念ではない

5.1.2 コンテキストの境界 (context boundary) によって定められる意味の境界

  • p.174 メールアドレスの大文字・小文字は結局どうすればいいのか

    • SMTP の推奨に従って大文字・小文字を区別しないほうに倒すのが良いのかもしれない

注釈

本日は、 p.177 の 5.1.3 の手前まで