Javaを学び始めると、
あるタイミングで必ず出てくる言葉があります。
それが、
シリアライズ
です。
「オブジェクトを保存できる」
「そのまま送れる」
そう聞くと、とても便利な仕組みに感じますよね。
しかし実際の現場では、
Javaのシリアライズは危険
使うべきではない
と言われることが多くあります。
なぜでしょうか。
この記事では、
- Javaのシリアライズとは何か
- なぜセキュリティ問題になるのか
- どんな考え方をすれば事故を防げるのか
を、
怖がらせるためではなく、理解するため
に、じっくり解説します。
Javaのシリアライズとは何か
まずは、とてもシンプルに説明します。
シリアライズを一言で言うと
オブジェクトを、そのまま保存や転送ができる形にする仕組み
です。
Javaの世界では、
プログラムの中に、
- 人を表すオブジェクト
- 注文を表すオブジェクト
- 設定を表すオブジェクト
など、たくさんのオブジェクトがあります。
シリアライズは、
それらを
- ファイルに保存したり
- ネットワークで送ったり
できるように変換します。
なぜ便利に見えるのか
初心者の方がシリアライズを見て
「すごい」
と感じる理由は、とても自然です。
なぜなら、
- 自分で項目を一つずつ変換しなくていい
- そのまま元に戻せる
- 実装が簡単に見える
からです。
しかし、
この
「そのまま」
という点こそが、問題の始まりになります。
なぜJavaのシリアライズは危険と言われるのか
結論から言います。
Javaのシリアライズが危険と言われる理由は、
「データだと思って扱っていたものが、実行の引き金になる」
からです。
データと命令の境界があいまいになる
本来、
データとは、
- 数値
- 文字
- 状態
のような、
ただの情報
であるべきです。
ところがJavaのシリアライズでは、
- オブジェクトの構造
- クラスの情報
- 内部の状態
まで含めて復元されます。
つまり、
「どんなクラスを、どんな順番で動かすか」
という情報まで、
外から来たデータに含まれてしまうのです。
読み込んだだけで起きること
ここが、とても重要なポイントです。
デシリアライズ、
つまり
復元する処理
では、
- コンストラクタ
- 特定のメソッド
が、
自動で実行されることがあります。
つまり、
「読むだけ」
「代入するだけ」
のつもりでも、
プログラムが動いてしまう
可能性があるのです。
デシリアライズ脆弱性の正体
ここからが、
セキュリティ問題の核心です。
攻撃者は何を狙うのか
攻撃者は、
あなたのコードを
一行一行書き換える必要はありません。
狙うのは、
- 外部から受け取ったデータ
- それをデシリアライズしている処理
です。
もしそこに、
「信じて復元してしまう処理」
があれば、
攻撃は成立します。
なぜ自分のコードを書き換えなくていいのか
Javaの世界では、
- 多くのライブラリ
- 多くのフレームワーク
が使われています。
それらの中に、
- 特定の条件で動く処理
- 組み合わせると危険になる処理
が存在することがあります。
攻撃者は、
「それらをどう並べれば動くか」
を知っています。
だから、
- 自分では危険なコードを書いていない
- 普通にライブラリを使っている
それでも、
攻撃が成立してしまう
のです。
実際の事故に共通する特徴
これまでに起きた多くの事故には、
共通点があります。
それは、
「外部から来たデータを、無条件で信じた」
という点です。
よくある思い込み
現場では、こんな声をよく聞きます。
- 内部システムだから大丈夫
- 社内ネットワークだから安全
- ずっと使ってきた仕組みだから問題ない
しかし、
攻撃は
想定外の経路
から入ってきます。
Javaのシリアライズは、
一度入り口を許すと、
被害が大きくなりやすい仕組みです。
Javaエンジニアが知っておくべき原則
ここで、
とても大切な原則を紹介します。
原則
外部から来たデータを、オブジェクトとして復元しない
これだけです。
使ってよい場面
Javaのシリアライズが
完全に悪いわけではありません。
たとえば、
- 完全に閉じた環境
- 自分のコードだけで完結している
- 外部入力が一切関与しない
こうした条件がそろえば、
問題にならないケースもあります。
ただし、
条件を一つでも外れるなら、避ける
これが現実的な判断です。
絶対に避けるべき場面
次のような場合は、
使うべきではありません。
- ネットワーク経由で受け取る
- ユーザが操作できる
- 将来変更される可能性がある
設計段階で
少しでも外部が関わるなら、やめる
これが安全な選択です。
危険な設計が生まれる理由
なぜ、
危険な設計が生まれてしまうのでしょうか。
それは、
「楽をしたい」
「早く作りたい」
という、人として自然な感情があるからです。
よくある発想
- オブジェクトをそのまま保存したい
- 変換処理を書くのが面倒
- 昔のコードをそのまま使いたい
しかし、
セキュリティ事故は、
楽をした結果として起きる
ことがほとんどです。
安全な代替手段の考え方
では、どうすればよいのでしょうか。
答えは、
目的を分解すること
です。
本当に必要なのは何か
多くの場合、
本当に必要なのは、
- 状態を保存したい
- 情報を送信したい
という点です。
それなら、
- 必要な項目だけを
- データとして
扱えばよいのです。
Javaが得意な設計
Javaは、
- 型がはっきりしている
- 構造を明示しやすい
- 設計を整理しやすい
という特徴があります。
だからこそ、
「何を渡すか」
「何を復元しないか」
を明確にした設計がしやすいのです。
レビューで役立つチェック視点
現場でコードを見るときは、
次の視点を持ってみてください。
- このデータはどこから来ているか
- オブジェクトである必要はあるか
- 将来、入力経路が増えないか
この問いを立てるだけで、
多くの事故は防げます。
まとめ
最後に、この記事の要点をまとめます。
- Javaのシリアライズは便利
- しかし、外部入力と組み合わさると危険
- 問題は機能ではなく、理解不足
- Javaは思想を理解すると、とても安全な言語
「使うな」ではなく、
「理解して選べ」
これが、
Javaエンジニアに求められる姿勢です。
絶対にJavaプログラマーになりたい人へ
もしあなたが、
- Javaを仕事にしたい
- 危険な設計を見抜けるエンジニアになりたい
- 表面的な知識で終わりたくない
そう思っているなら、
まずは自己学習をしっかり行いましょう。
おすすめなのが、
絶対にJavaプログラマーになりたい人へ。
https://amzn.asia/d/3E1CYbv
考え方から学ぶことで、
理解の深さが変わります。
それでも、
- 自分の設計が正しいか不安
- セキュリティ観点でレビューしてほしい
- 転職まで含めて相談したい
そんな方は、
サイゼントアカデミー
https://academy.cyzennt.co.jp
を検討してみてください。
Javaを軸に、
現場で通用する力
を身につけたい人にとって、
とても心強い環境です。
Javaのシリアライズを理解することは、
Javaそのものを理解することにつながります。
一歩ずつ、
安全な設計ができるJavaエンジニア
を目指していきましょう。
コメント