行動経済学や心理学の本を読んでいて、いくつものバイアスが出てきた。
また、いつ見たかは忘れたけど、バグバウンティで発生するバイアスについて書かれた英語の記事もあった。
なので、ブログベースで私も書いてみようと思う。
内容としては、現場で見てきた確証バイアスの事例だ。
この分野に関して密接に研究したわけではないため、漏れ、不足、認識のミスなどあったらご容赦願いたい。
確証バイアスとはの概念も引用だが置いておく。
https://ja.wikipedia.org/wiki/%E7%A2%BA%E8%A8%BC%E3%83%90%E3%82%A4%E3%82%A2%E3%82%B9
過去の判断基準への異常な信頼
「なんか不思議な挙動する・・・」
「そういえば、似たような挙動で以前指摘してたな、これにしよう」
こういった、ちょっとルールに当てはまらないような挙動をした際、過去に似たような指摘をしているとそれにすぐ当てはめてしまう場合がある。
私もこう考えてしまうことはあるので、なんとも難しいものだ。
このケースの問題としては、「今回の挙動」にフォーカスしきれていないことだ。
「過去の指摘した挙動」と似ていることしかわからないため、「今回の挙動」がどういったものかを深掘りできていない。
この思考、おそらくだが過去に似た指摘がなければ深掘りしていたり、他の人に相談したりしていたはずなのだ。
（それをしないなら普通に見逃しだからな）
なので、「過去の指摘と同じだろう！」という確証バイアスの事例の１つだった。
エラーベースファジング結果への異常な信頼
「ん！？シングルクォート1つと2つで挙動が違う・・・！？SQLインジェクションだ！」
これは初学者による経験不足か、確証バイアスか悩むところではあった。
おそらくだが、二つ合わせた「経験不足＋限られた経験による確証バイアス」なのだろう。
脆弱性診断をしていると、大体の脆弱性は同じパターンで発生する。
普通にXSSが発生したりもするし、教科書通りのパターンでSQLインジェクションやパストラバーサルが発生したりもする。
その中でもSQLインジェクションは判断ミスが起きやすい。
バックエンドがどう処理をしているかわからないが、パーセントエンコードが2つ続くとエラーになるシステムを見たことがある。
他にも、奇数偶数でエラーが変わったり、WAFなのかリバースプロキシなのか環境の問題なのか適度にエラーが発生したりすることもある。
経験が浅いと「あー！！」といった感じで実は違う要因なのにSQLインジェクションを指摘しそうなことがある。
しかし、これはまだ良い。
この問題が発生しやすいのは、ある程度経験を積んだ人なのだ。
実のところ、「バックエンドの動きを予想し、エラーの内容を予測する」ということができる人は多くない。
そういった人は堅実に経験を積み重ねていくのだが、ある程度のラインに来ると「慣れ」になってしまう。
「慣れ」になったときにこのような謎エラーが起こるシステムに当たってしまうと、「はいはいSQLインジェクションね」といった感じで進めてしまう。
その後、軽くSQLインジェクションであることを確認して指摘してしまう。
これはピンポイントとなったが、結構あるあるだろう。
確証バイアスの説明でもある、「3つ並んだ数字の規則性を当てる」みたいなやつと同じやつな気がしる。
ここでの問題は、「軽くSQLインジェクションであることを確認して指摘」することだ。
念押ししたいなら、同時に「SQLインジェクションではないこと」も確認しなければならない。
適度にエラーになってしまうなら、シングルクォート１つだけを数１０リクエスト送ってみれば良い。
例で出したような「パーセントエンコードが2つ続くとエラーになるシステム」であれば、他のパーセンドエンコードの文字列を試してみれば良い。
この例が一番、確証バイアスの「反証する情報を無視または集めようとしない傾向」に適したものとなっただろう。
変化する判断基準への順応の遅れ
「この指摘項目は・・・こういう設定になってたらダメだったな」
「あれ！？最近の基準だと変わって・・・た？」
脆弱性診断は指摘する基準が1〜2年単位で変わることが多い。
大体が微々たるもので、重大なリスクになるものではないが、我々はペンテスターではないので、リスクが小さいからといって適当にして良いわけではない。
最近で結構困ったのがCookieのSamesite属性だ。
chromeがデフォルトでlaxにしたり、firefoxがデフォルトでlaxにしたりしなかったり、IEは全く関係なかったり、そんなこと言ってたらIEがサポート終了したりした。
脆弱性診断に関わる人全てがさまざまな基準について精通しているわけではないし、いつだって情報を追って理解しているわけではない。
そういった中で、このsamesite属性は結構厄介だった。
そもそも、「Cookieに新しい属性が増えますよ」ってことで基準を修正した後、浸透させるのも大変だ。
「Cookieの属性とはこういうもの」みたいなのが長く続いた人ほどアップデートするのが大変そうだった。
この例は個人が悪いわけではなく、いい意味でも悪い意味でも使える「慣れ」が悪い方向に出たかなと言った感じだった。
「RANGE」でも出てきたが、狭い分野に特化するとこういった変化に弱くなってしまうのだろう・・・。
対策
想定する結果と相反するエビデンスを揃えさせる
これはルール的なものだが、「発生した」エビデンスと「発生しなかった」エビデンスを残すようにさせる。
すると、エビデンス取得の過程で相反する事例を確認できるし、なんらかの要因があって作業者が気づかなかった場合も第三者の目がどこかで入ることによって確証バイアスの発生を少なくできる。
第三者の目を増やす
これはリソース的に難しいかもしれないが、見る目を増やせば確証バイアスが起こる確率も減らせる。
稼働率みたいなもんだ。
しかし、組織全体が同じ確証バイアスを共有していたり、そもそも疲弊していたりすると使えなかったりもする。
大事なのは余裕ということか。
機械的に判断する項目を増やす
そもそも人間の目が入らないようにするのも効果的だと思われる。
判断のリソースを曖昧な挙動に割り振ってしまおうというものだ。
SQLインジェクションであれば、パターンをかなり用意し、スキャナも並行して使用することでだいぶ検知の信頼性が上がる。
時間はかかってしまうが、確証バイアスの影響は減らせるだろう。
終わりに
初めて分野を組み合わせた記事を書いてみた。
楽しかったので、これからもやってもいいかもしれない。
書いていった事例は仕事で見つけて「ああ・・・」となったものばかりだ。
この事例は発生する確率が高いわけじゃない（高かったら構造的な問題だ）が、発生してしまったらお客様に申し訳ない。
可能な限りそういったことを減らしたいという気持ちもあったのでこれを書いてみた。
人がやる限り、確証バイアスをはじめとしたバイアスから逃れることはできないんだろうけども・・・。
コメント