午後1

問1

設問1

(1) HTTPリクエストヘッダで改行を意味する文字列は何か

• 答え
  • %0D%0A

(3) メールヘッダインジェクションの対策方法

• 答え
  • メールヘッダを固定値にする
  • 入力を適切に処理するメール送信用のAPIを用意する
  • 外部からの入力全てについて、改行コードを削除する
• 解説
  • メールヘッダインジェクションはメールヘッダを改ざんする攻撃
  • メールヘッダの各値や、メールヘッダとメール本文は改行で分割されている
  • この特性を利用して、タイトルなどに改行コードを入力することで、送信先やメール本文を書き換えることができる

問3

設問2

(1) アカウントと銀行口座の紐付けで、キャッシュカードの所持が確認されずに暗証番号だけで照合されており、攻撃者が他人の氏名でアカウント作成を行い、他人の銀行口座と紐付けを行うリスクがある。その時の、具体的な手口を２つ答えよ

• 答え
  • 漏えいしている口座番号と暗証番号を悪用する方法
  • 口座番号と暗証番号をだまして聞き出し，悪用する方法

(2) オンラインでの本人確認方法で、本人確認書類を用いた方法を答えよ

• 答え
  • 方法の１例
    • 写真付き本人確認書類の画像
    • 容貌の画像

(3) デジタル署名で、署名に使うものと、確認に使うものをそれぞれ答えよ

• 答え
  • 署名：秘密鍵
  • 確認：公開鍵

設問3

(1) スマートフォンの画面ロックを設定してないと、どのような場合に不正利用が行われるか答えよ

• 答え
  • スマートフォンが盗まれて利用された場合

(2) あるアプリにログインした状態で、アプリの不正利用を防ぐための機能をどのように実装するとよいか、答えよ

• 答え
  • アプリの起動時に，PIN コードで利用者を認証する機能

午後2

問2

設問1

(1) CDNで分散配置されるサーバをなんというか

• 答え
  • キャッシュサーバ

(2) CDNの導入により、コンテンツサーバの負荷を軽減することができる。この特性により、どのような攻撃に対する耐性が向上するか

• 答え
  • DDoS

(3) HTTPヘッダの中で、アクセスしたい URI とポートの情報をもつヘッダをなんというか

• 答え
  • Hostヘッダ
• その他
  • Hostヘッダを改ざんする攻撃への対処法は？
    • 本来接続したいサーバとHostヘッダの値が一致していることを検証する

設問2

(1) Kerberos認証において、STの偽装が認証サーバで検知できないのはなぜか？

• 答え
  • STの検証は認証サーバでは行わないから

(2) STに対して、サーバ管理者アカウントのパスワードの総当たり攻撃が行われ、それが成功すると、そのアカウントでアクセスできるサーバが乗っ取られる。この攻撃は、サーバ側でログイン連続失敗時のアカウントロックを有効にしても対策にならないのはなぜか？

• 答え
  • STに対する総当たり攻撃には、サーバへのログインは必要ないから
• その他
  • Kerberos認証の流れ
    • クライアント　→　ID/パスワード　→　認証サーバ
    • クライアント　←　TGT　←　認証サーバ
      • TGT：クライアントのアクセス権限を示すチケット
    • クライアント（サービスAへのアクセス要求）　→　TGT　→　認証サーバ
    • クライアント　←　ST　左　認証サーバ
      • ST：アクセス対象のサーバ（サービス）ごとに発行されるチケット。アクセス対象のサーバの管理者アカウントのパスワードハッシュ値を鍵として暗号化
    • クライアント　→　ST　→ サービスA
    • クライアント　←　サービス提供　←　サービスA

設問3

(1) SAML認証で、IDaaS側はHTTPリクエスト中の何からSAML Requestを取得するか答えよ

• 答え
  • クエリ文字列
• その他
  • SAML認証の流れ
    • クライアント　→　サービス要求　→　SaaS
    • クライアント　←　SAML Requestの生成　←　SaaS
      • IDaaSに認証を要求するSAML Requestを生成し、エンコード
      • エンコード結果と、IDaaSのログイン画面のURLを組み合わせて、リダイレクト先URLを生成する
    • クライアント　→　SAML Requestを含むHTTPリクエスト　→　IDaaS
      • IDaaSはHTTPリクエストのクエリ文字列からSAML Requstを取得する
      • 信頼関係が構築されたSaaSからの認証要求であることを検証する
    • クライアント　←　ログイン画面応答　←　IDaaS
    • クライアント　→　認証情報　→　IDaaS
      • 認証処理を実施
      • 認証が成功すると、SAMLアサーションとそれに対するデジタル署名を含めたSAML Responseの送信フォームを生成する
        • デジタル署名は、SAML ResponseがIDaaSのものであること、偽造されてないことを検証するのに使う
        • アサーション(Assertions)とは、SAMLの重要な概念のひとつで、XMLでフォーマットされたメッセージとして、ユーザーの認証情報、属性、ユーザーの権限の認可といったものが記述されています。
    • クライアント　←　SAML Responseの送信フォーム　←　IDaaS
    • クライアント　→　SAML Response　→　SaaS
      • SAML Responseのデジタル署名を検証し、デジタル署名がIDaaSのものであること、SAMLアサーションの偽装がないことを確認する
      • SAMLアサーションの内容を検証し、サービス提供するべきかどうかを決定する
    • クライアント　←　サービス提供　←　SaaS
  • IDaaSとSaaS間で必要な事前準備
    • SAMLアサーションで用いる属性
    • SAML Requestを含むリダイレクトで使うURL
    • デジタル署名に利用する、デジタル証明書

設問4

(1) OAuth 2.0 の処理の流れを答えよ

• 答え
  • 利用者　→　サービス要求　→　サービスA
  • 利用者　←　リダイレクト　←　サービスA
    • リダイレクトの時にstateパラメタを付与する
    • 利用者にstateパラメタを持たせることで、認可コードが送信されてきたときに検証できる
  • 利用者　→　認可要求　→　IDaaS
  • 利用者　ー　認可同意処理　ー　IDaaS
  • 利用者　←　リダイレクト　←　IDaaS
  • 利用者　→　認可コード　→　サービスA
    • 認可コードとstateパラメタを送信し、サービスAで検証することで、利用者が送信した認可コードであることを確認することができる
  • サービスA　→　トークン要求　→　IDaaS
  • サービスA　←　トークン応答　←　IDaaS
  • サービスA　→　情報の取り合わせ　→　サービスB
  • サービスA　←　情報の応答　←　サービスB
• その他
  • PKCEとは
    • サービスAへのアクセスにサービスAのスマホアプリを使うときに、攻撃者の用意した不正なアプリをインストールすると、認可コードを横取りされる可能性がある
    • そこで、アプリでランダムな検証コードとその値を元にしたチャレンジコードを作成して、チャレンジコードを認可要求に追加、検証コードをトークン要求に追加する
    • ２つのコードを検証することで、検証コードを知らない攻撃者からのトークン要求を排除できる
    • この仕組みを標準化しているのがPKCE

設問5

(1) 以下の前提があるときの、OpenID Connectの認証フローを答えよ

• 前提
  • サービスAからサービスBへAPIを使って情報を連携したい
  • サービスAはサービスBの認証サーバでログインすれば使える
• 答え
  • クライアント　→　サービス要求　→　サービスA
  • クライアント　←　リダイレクト　←　サービスA
  • クライアント　→　認証要求　→　サービスBの認証サーバ
  • クライアント　ー　ログイン処理　ー　サービスBの認証サーバ
  • クライアント　←　リダイレクト　←　サービスBの認証サーバ
  • クライアント　→　認可コード　→　サービスA
  • サービスA　→　トークン要求　→　サービスBの認証サーバ
  • サービスA　←　トークン応答　←　サービスBの認証サーバ
  • サービスA　→　APIでの情報連携　→ サービスB
• その他
  • nonce値とは
    • サービスBの認証サーバからIDトークンを応答するときに、攻撃者に傍受され不正利用されるのを防ぐ仕組みです
    • まず、認証要求の時にnonce値を生成し付与して送信します
    • 次に、IDトークンに含まれるnonce値を検証することで、攻撃者が傍受して利用していないか検証できます