“典型的やられサイト”で学ぶセキュリティのワナ

え？　同じIDで登録できる？　コンビニ証明書で話題「同時処理」の危険性（2/4 ページ）

荒井　上野さん！　今大丈夫ですか？　できたので確認お願いします。ちょっと自信ないですけど……。

上野　セキュリティがモロ絡んでくると不安になるよね。見ていこうか。

上野　うん。機能はちゃんと組み込めてるね。

荒井　ありがとうござます。セキュリティ周りはどうですか？

上野　下手するとそこが原因でインシデントが発生してニュースになるかもしれない。

荒井　あぶない……。

上野　ここが勉強のしどころだね。じゃあどんな問題が発生しそうか見てみようか。

上野　まず1個目は衝突チェックをしていないところだね。このままだと同じIDのアカウントが複数存在できてしまう。

荒井　え？　でも入力画面の段階で、既存のIDと同じじゃないかは確認してますよ？

上野　うん。ぶつかる可能性があるのは同時に同じIDを登録しようとしたときだね。

荒井　そんなことありますかね？　かなり考えにくいんじゃないかと思うんですけど。

上野　可能性がほぼゼロだとしても想定しておくのは大事だからね。例えば「新しいシステムを作ったのでアカウント登録をしておいてください」って従業員に伝えたら、みんなだいたい同じタイミングで作業するよね。

荒井　はい。

上野　そこで「IDは部署名と名字を組み合わせればいいかな」と考えた営業部の佐藤さんが2人いたとする。

荒井　……「EigyoSato」がかぶるかもしれないってことですね。

上野　その通り。今回の実装では、アカウント情報の確認フェーズと登録フェーズがある。見てみると、確認フェーズでは既存のIDとの衝突チェックをしているけど、登録時にはロックがかかっていない。

　だから、佐藤Aさんと佐藤Bさんが同時に確認フェーズにいる間はIDが衝突する可能性がある。登録情報を確認する段階では互いにまだIDが存在していないから、“既存のID”として引っかかることがない。

　そして、登録ボタンを押すタイミングでは確認していないからそのまま同じIDを登録できてしまう。

同時に作業するっていってもコンマ何秒とかシビアな話ではなくて、登録作業を始めてから登録実行までの間なら最悪何時間でも“同時”判定になってしまう。

荒井　となると、可能性はかなり高そうですね。

上野　うん。いや可能性そのものは低いかもしれないけどありえる。うまく登録できないならまだマシなんだけど、両方登録できたらまずいよね。一つのデータに複数の操作が同時に加えられると、「レースコンディション」といって予期しない挙動が起きるかもしれない。

荒井　完全に理解しました。

この記事の著者

関連記事

• 

  川崎市のコンビニで他人の戸籍謄本誤発行　「2人同時に発行申請すると上書き」バグが原因　富士通

• 

  新人の作ったWebアプリが穴だらけ!?　ログイン画面に潜むセキュリティの”あるある”ワナ