情報処理安全確保支援士(情報セキュリティスペシャリスト) 試験情報＆徹底解説

〔gについて〕
図3の注¹⁾によれば、Mサイトではメールアドレスの変更時に次の2つのタイミングで通知を行っています。

• 画面09で変更要求したときに、変更前のメールアドレスに確認用URLの送付
• 確認用URLクリックで変更が確定したときに、変更前・変更後のメールアドレスに変更内容の通知

想定される攻撃では、不審なメールが求人企業に届かないとありますから、(2)の手順前にメールの通知先に細工をしておく必要があります。この際に利用できるのが、図Bのメールヘッダーインジェクション脆弱性です。図Bの攻撃の流れを確認します。

1. 画面09の会社名欄に、任意の会社名 + 改行コードとSMTPのToフィールド + 連続2回の改行コード（SMTPでヘッダーとボディの区切りを意味する空行）を入力して、変更登録する
   ●●株式会社 - 任意の会社名
   %0D%0ATo:abc@exmaple.com - 改行コードとSMTPのToフィールド
   %0D%0A%0D%0A - 連続2回の改行コード
2. Mサイトはデータベース上の会社名を、上記のメールアドレスを含む文字列に変更する
3. 画面09のメールアドレス欄に任意のメールアドレスを入力して、変更要求を行う
4. 確認用URLを含むメールが送信される。この際、Subjectフィールドにはデータベース上の会社名が出力され、会社名に含まれる改行コードにより偽のToフィールドが現れる。その後ろの"空行"の存在により、本来のToフィールドはメッセージボディ部に追いやられる
5. 攻撃者は受信したメールの確認用URLにアクセスする。変更確定時のメール通知も上記と同じ理由で、本来通知されるべき変更前のメールアドレスには届かない

この手順を使用すれば、正規ユーザーのメールアドレスに通知が届くことなく、登録メールアドレスを攻撃者のものに変えることができます。(2)ではメールアドレスを攻撃者のものに変更していますから、その前の(1)では図Cの文字列（メールアドレス部分を攻撃者のメールアドレスに変えたもの）を会社名欄に入力し、データベース上の会社名を改ざんしておく必要があります。

∴g＝画面09で，会社名に，図Cのabc@example.comを攻撃者のメールアドレスに変更した文字列を入力して変更ボタンをクリックする。

〔hについて〕
図Dでは、攻撃者がパスワード再設定まで完了したあと、求人企業として正規の機能を用いて求職者情報を大量に取得する流れが示されています。図4の4.1には「WebAPIを悪用して」と記載されているので、空欄hで問われている操作は、WebAPIを利用するための前段階の画面操作であると読み取れます。

Mサイトでは、求人企業がWebAPIを利用するために、まずWebAPIキーを確認又は新規発行する必要があります。この操作の流れは、図3に示された画面04から画面08までの遷移で表現されています。また、画面05と画面07では、いずれも求人企業のパスワードの入力が求められます。しかし、図Dの(5)までの手順で攻撃者はすでにパスワード再設定の手順を完了しており、自分の設定した新しいパスワードに変更済みです。そのため、攻撃者は画面05や画面07で再設定後のパスワードを入力することで、難なく認証を通過できます。

このようにして、攻撃者は画面04からの一連の操作を進め、途中のパスワード確認画面で再設定後のパスワードを入力することで、WebAPIキーを確認（画面06）したり、新たに発行（画面08）したりできます。その後、入手したWebAPIキーを用いてWebAPIを呼び出し、求職者の氏名や自宅住所などの属性情報を不正に取得することが可能になります。

(5)は再設定後のパスワードでログイン、(7)はWebAPIの利用ですから、(4)にはその間の「APIkey管理画面にアクセスし、再設定したパスワードを入力して、APIKeyを取得する」までの手順が当てはまります。

∴h＝画面04からの一連の操作において，画面05又は画面07で再設定後のパスワードを入力して，WebAPIキーを確認又は発行する。

〔ijについて〕
空欄iとjは、WebAPIの仕様に関する改善案と、その改善によってどのように被害を防止・軽減できるかという理由を、自分の言葉で記述させる問題です。表Fの項番1の欄には、もともと具体的な案は書かれておらず、診断者としてどのような仕様改善を提案できるかを見る設問になっています。

模範解答としては3つの例が示されていますが、趣旨としては「MサイトのWebAPI仕様（図2）に起因して発生し得る被害を、仕様レベルでどう抑え込むか」を書けていればよく、これらと同様の方向性を持つ案であれば得点対象になると考えられます。

1. i＝求職者IDが推測困難なものになるように、求職者IDの生成方法を変更する。
   j＝APIkeyが窃取された場合、該当求人企業への問合せ又は応募をした求職者の情報漏えいだけに被害を軽減することができるから
   
   本文では、求職者IDは「登録年月日8桁の数字＋その日に登録した順に000001から採番する6桁の数字」という、規則性の高い14桁の数字列であると説明されています。このような連番方式だと、攻撃者がAPIkeyを不正に入手した場合、WebAPIの機能③「任意の求職者IDを指定して求職者属性情報を取得する」を悪用し、日付部分を固定したまま000001、000002…と順番にIDを指定していくだけで、多数の求職者属性情報を機械的に取得されてしまうリスクがあります。
   
   そこで、iとして「求職者IDが推測困難なものになるように、求職者IDの生成方法を変更する」とし、jとして「APIkeyが窃取された場合、当該求人企業への問合せ又は応募をした求職者の情報漏えいだけに被害を軽減することができるから」と理由付けます。IDをランダムな文字列などに変更しておけば、攻撃者は連番総当たりで他社に関係する求職者IDを次々に指定することが難しくなり、現実的には、当該企業とやり取りした求職者のID程度しか把握できません。その結果、漏えい範囲を「当該企業に関係する求職者」に事実上限定できるという考え方になります。
   
   
2. i＝WebAPIのアクセス元IPアドレスを限定して接続を許可するように変更する。
   j＝WebAPIへの第三者による不正なアクセスを防ぐことができるから
   
   図2では、WebAPIの認証は「HTTPリクエスト内のAPIkeyが発行済みであり有効期限内であることを確認する」という方式だけになっており、APIkeyさえ手に入れば、攻撃者であってもインターネット上のどこからでもAPIを呼び出せてしまいます。一方で、WebAPIの利用主体は求人企業のアプリケーションプログラムに限られており、企業側の環境からのアクセス元IPアドレスはある程度固定されることが想定されます。
   
   そこで、iとして「WebAPIのアクセス元IPアドレスを限定して接続を許可するように変更する」と記述します。これにより、登録済みのIPアドレス以外からのAPI利用を拒否できるため、たとえAPIkeyが窃取されても、攻撃者側の環境からはWebAPIに接続できません。したがって、jとして「WebAPIへの第三者による不正なアクセスを防ぐことができるから」と説明することができます。
   
   
3. i＝WebAPIで取得できる求職者属性情報は、個人を特定できないものだけに限定するように変更する。
   j＝不正にWebAPIが利用されても、個人を特定できない情報の漏えいだけに被害を軽減することができるから
   
   本文冒頭にあるとおり、Mサイトに登録される求職者属性情報には、氏名、自宅住所、電話番号、勤務先など、個人が特定できる情報が含まれています。現在のWebAPIの仕様では、機能③で任意の求職者IDに対して求職者属性情報全体を取得できるため、APIが悪用されると、これらの個人情報が一括で漏えいするリスクがあります。
   
   そこで、iとして「WebAPIで取得できる求職者属性情報は、個人を特定できないものだけに限定するように変更する」とし、例えば年齢層や希望職種などの属性にとどめるよう仕様を見直します。これにより、万一攻撃者にWebAPIを不正利用された場合でも、流出するのは個人を直接識別できない情報に限定されます。このため、jとして「不正にWebAPIが利用されても、個人を特定できない情報の漏えいだけに被害を軽減することができるから」と理由を述べることができます。

〔klについて〕
空欄k,lも同様に、Webアプリケーションプログラムに関する被害を軽減するための改善案とその理由を自由に記述するものです。公式の解答例は3つあるのでそれぞれの趣旨を解説します。

1. k＝ログインの認証を，多要素認証に変更する。
   l＝アカウントの乗っ取りを防ぐことができるから
   
   図3の画面01からわかるように、現状のMサイトでは、利用者IDとパスワードだけでログイン認証を行っています。IDとパスワードだけの認証方式は、漏えい・総当たり・フィッシングなどで資格情報を盗まれた場合、そのままアカウントを乗っ取られてしまうという弱点があります。
   
   これを強化する方法として多要素認証があります。例えば、IDとパスワードに加えて、スマートフォンのSMSや認証アプリで表示されるワンタイムコードを入力させる方式などがこれに該当します。このように、たとえ知識情報であるIDとパスワードが盗まれても、利用者本人が所持する端末や生体情報がなければログインできないため、アカウントの乗っ取りを防ぐ効果があります。そのため、kは「ログインの認証を多要素認証に変更する」、lは「アカウントの乗っ取りを防ぐことができるから」とまとめるのが適切です。
   
   
2. k＝利用者ごとにアクセス元IPアドレスを限定して接続を許可するように変更する。
   l＝第三者による不正なアクセスを防ぐことができるから
   
   設問3②では、WebAPIのアクセス元IPアドレスを限定する案をWebAPI側の改善として挙げましたが、これは求人企業が自社システムからWebAPIを利用する場合の制御であり、Mサイトのログイン画面にアクセスする利用者全体を直接制御するものではありません。ここでの改善案は、Webアプリケーション側で、利用者ごとにアクセス元IPアドレスを制限することで、不審な場所やネットワークからの接続を抑止しようというものです。
   
   例えば、特定の企業のアカウントについては、その企業の拠点やVPNのIPアドレスだけを許可するようにすれば、攻撃者が全く別のネットワークから不正ログインを試みても、IP制限によってブロックできます。このように、正当な利用者が通常利用しないIPからのアクセスを拒否することで、第三者による不正なアクセスを防ぐことができるため、理由としてlの記述になります。
   
   
3. k＝求人企業プロパティ変更において，メールアドレス以外を変更した場合でも，メールを送信するように変更する。
   l＝不正に求人企業プロパティが変更された場合に気付くことができるから
   
   図3の画面状態遷移の説明を見ると、画面09の求人企業プロパティ変更では、メールアドレスを変更した場合にだけ確認用のメールが送信される仕様になっています。一方、図Bで示されたメールヘッダーインジェクションの攻撃手順では、まず会社名の変更フォームに特定の文字列を入力し、その後にメールアドレスを変更しています。もし会社名やその他のプロパティが不正に書き換えられても、メールアドレスが変わらない限り、現行仕様では求人企業側に通知が届かず、被害に気付きにくい状態です。メールアドレス以外のプロパティ変更時にも確認メールを送るようにしておけば、正当な担当者は「身に覚えのない変更通知」によって異常に気付き、早期にパスワード変更や問い合わせなどの対応を取ることができます。
   
   したがって、仕様としては「メールアドレス以外の項目を変更した場合でもメールを送信する」とし、その理由として「不正に求人企業プロパティが変更された場合に気付くことができるから」とするのが一つの回答になります。