脆弱性とは｜Webセキュリティ入門

このレッスンで学ぶこと

脆弱性は、セキュリティの話でいちばんよく出てくる言葉です。この回では、この言葉がバグとどこで重なり、どこで離れるのかを見ます。

読み終えるころには、脆弱性が生まれやすい場所を5つ挙げられるようになります。

バグは、意図した動作と実際の動作が食い違っている状態です。脆弱性は、安全に関する前提が破られる弱点です。

多くの脆弱性はバグですが、そうでないものもあります。仕様どおりに動いていて、テストも全部通っていて、それでも脆弱性ということが起こります。

たとえば「注文番号をURLに入れると注文の詳細を返す」という機能は、仕様どおりに動いています。番号を変えれば別の注文が返るのも、仕様の素直な帰結です。足りないのは「その注文がその人のものか確かめる」という、誰も書かなかった要件です。

脆弱性はコードの誤りとは限らない

書いたコードが間違っているのではなく、書かれなかった確認が抜けている。これが脆弱性のもっとも多い形です。

弱点が集まりやすいのは、次のような場所です。

信頼の置き方を間違えたところ。 ブラウザから届いた値を、そのまま正しいものとして扱う。ブラウザから送られた価格をサーバーがそのまま信じて計算する、という例がこれにあたります。

確認が抜けたところ。 「ログインしているか」は確かめたが、「その人のものか」は確かめていない。片方だけの確認は、確認していないのと同じ結果を招くことがあります。

設定のまま置かれたところ。 初期パスワード、公開されたままの管理画面、詳細すぎるエラー表示。どれもコードの問題ではありません。

古いまま動いているところ。 使っているライブラリに弱点が見つかっても、更新しなければ弱点はそこに残り続けます。

組み合わさったところ。 単体では無害な2つが、つながると成立する。個別のレビューでは見つかりにくく、実際に通して試したときに初めて見えます。

テストは、想定した使い方が想定どおりに動くことを確かめます。攻撃は、想定していない使い方をします。この2つは重ならないので、テストが全部通ることは安全の根拠になりません。

これがセキュリティの学び方を、ふつうの開発と少し違うものにします。正しい入力で正しい結果が出ることを確かめるだけでなく、「この値を誰が決めているのか」「この確認は誰のために行われているのか」を問い直すことが要ります。

脆弱性があっても、必ず被害が出るとは限りません。外部から到達できない場所にあるかもしれませんし、悪用しても得られるものが無いかもしれません。

起こりやすさと影響の大きさで見る、というリスクの考え方がここで効きます。見つかった弱点を、到達しやすさと影響の大きさで並べ、大きいものから直します。すべてを同時に直そうとすると、どれも直らないまま時間だけが過ぎます。