今年の東京会場。
Aトラックで参加しました。
今回の記事では、提出課題の解答を全部公開しようと思います。
【問1】
あなたがミニキャンプに応募された動機について教えてください。また、この講義で学んだことを何に役⽴てたいかを教えてください。
回答
私が応募した理由は、将来、⾼校の情報科教員を目指している身として、教科書に書かれている知識だけでなく、具体例を交えた授業を自分で行えるようにしたいと考えたからです。
⼤学の講義では、ネットワークの基礎を学びました。授業内で紹介された実際の攻撃⼿法やその防御策、インシデント対応の考えなどを本ミニキャンプの専⾨的な講義を通じて、深く学び、教育現場での教材作りに活かしたいと考えています。
例えば「セキュリティの重要性」というテーマの基で授業を⾏う際には、セキュリティリスクが高まる事例を紹介するなどして、⽣徒が問題を⾃分事としてを捉え、⾃衛できるようリテラシーを育むための授業作りを⽬指します。また、Webアプリケーションを作成する実習を行う際に、安全な設計基準を提示する際の参考にもしたいと考えています。
【問2】
Webサービスにおける認証において、「この端末を記憶する」というように⼀定期間 ID/パスワードの⼊⼒を省略できるものがあります。
これはどのように実現されているのかまとめてください。
回答
Webサービスにおける「この端末を記憶する」機能はオートログイン機能などと呼ばれ、主にWebサーバーからブラウザに送られる「Cookie（クッキー）」と、サーバー側で発⾏される「認証トークン」を組み合わせて、実現されています。この処理は以下の3つのステップに分けて説明することができます。
- トークンの発⾏と保存
ユーザーがIDとパスワードを⼊⼒して初回ログインに成功すると、サーバー側は「認証トークン」を⽣成します。これは、セキュリティの観点から推測不可能な⻑い⽂字列になっています。このトークンはサーバー側のデータベースに保存されると同時に、有効期限（例：30⽇間）が設定され、Cookieとして、ユーザーのブラウザにも送信‧保存されます。- 再アクセス時の⾃動送信
ユーザーが⼀度ブラウザを閉じて、後⽇、再び同じWebサイトを訪れた際、ブラウザは保存しているCookieを⾃動的にサーバーへ送信します。- サーバーでの照合と認証の省略
サーバーは送られてきたトークンと、⾃⾝のデータベースに保存されているトークンが正当なものかを照合します。これらが完全に⼀致し、かつ有効期限内であることが確認できれば、「前回正しくログインしたユーザー本⼈である」と判断されます。
このように、パスワード⾃体を端末に保存させるのではなく、⼀時的な「⾝分証（トークン）」をCookieとして持たせ、サーバー側で都度確認することで、セキュリティを保ちつつ⼊⼒を省略する利便性を実現しています。
【問3】
社内からの通信は制限されていることが多いですが、あなたが社内のネットワーク管理者だとしたらどのような制限を掛けますか？またその
⽬的はなんですか？
1つ以上の⽅法を回答してください。
回答
社内のネットワーク管理者として、外部からのサイバー攻撃と内部からの不正な情報持ち出しの両⽅を防ぐため、以下の2つの制限を実施します。
- ファイアウォールにおける「デフォルト拒否（ホワイトリスト⽅式）」の徹底
制限の内容: 社内から外部への通信において、パスワードが平⽂で流れるプロトコルや外部からの攻撃に悪⽤されやすいプロトコルの通過を原則として禁止する。そして、DNSやICMPなど、機器ごとに必要最⼩限の通信のみを許可します。
⽬的: 知的財産などの持ち出しを防ぐためです。また、万が⼀内部の端末がマルウェアに侵害された場合でも、外部の攻撃者サーバーとの不正な通信経路を塞ぐことができるので、外部への情報流失を防ぐ狙いもあります。
２. 権限の分散とエンドポイントの制限
制限の内容: ネットワーク上のシステムに対して、システム管理者を含め、権限を分散させます。また、主たる情報の持ち出し⼿段であるUSBメモリ等の外部記録媒体への書き出し制限を徹底するとともに、通信や操作の監視体制を強化し、「監視している旨」を社内に明確に通知します。
⽬的: 内部の⼈間による不正な情報持ち出しや、過失による情報漏洩を防ぎ、情報漏洩の原因として多い「うっかりミス」を未然に防ぐため。また、権限の分離と物理的な持ち出し制限によって経路を物理的にも塞ぐ狙いもあります。
【問4】
ご⾃⾝が普段利⽤しているWebサービスの中でOAuth 2.0 または OpenID Connect が利⽤されていると思われるサービスを具体的にひとつ挙げてください。
そのサービスにおいて攻撃者はどのようなことを⽬的に攻撃を仕掛けてくる可能性があるのか、その攻撃によってユーザーやWebサービスの運営者はどのような被害にあってしまう可能性があるのか、それらを防ぐためにはどのような対策を講じる必要があるのか、⼀連の流れを考えて回答してください。
注意点
ご⾃⾝で想像して回答する、もしくは過去に発⽣した事例を調査して回答するか、どちらでも構いません。本講義はOSI参照モデルのアプリケーション層、プレゼンテーション層、セッション層を中心とした対策を想定しています。その前提を考慮して回答してください。
回答
Qiita では、Google や GitHub などのアカウント情報を連携させてログインを行う「ソーシャルログイン」として、 OAuth 2.0 の認可コードグラントフロー等が実装されています。
攻撃者の主な⽬的として、ユーザーアカウントの乗っ取りによるリソース情報の不正取得や個⼈情報の漏洩があります。
具体的な攻撃⽅法として、OAuth の認可フローの隙を突く2つの手法が考えられる。
第⼀に、「CSRF（クロスサイトリクエストフォージェリ）攻撃」です。攻撃者が⾃⾝のアカウントで認可コードを取得した直後に通信を遮断します。そして、その URL をフィッシングメールなどを通じて被害者にクリックさせることで、被害者側のセッションに対して強制的に攻撃者のアカウントを紐付けます。
第⼆に、「ブラウザ履歴からのセッションハイジャック」です。図書館などの共⽤PCにおいて、被害者のブラウザ履歴に残った URL から認可コードを取得し、攻撃者⾃⾝の認可レスポンスのコードと書き換えて不正アクセスを⾏います。
これらの攻撃が成功した場合、ユーザー側はアカウントを乗っ取られるだけでなく、⾮公開の記事を勝⼿に改ざんされたりする可能性があります。さらに、アカウントが攻撃者に紐付いた状態でユーザーが個⼈情報を更新すると、その内容まで攻撃者に漏洩してしまうという深刻な問題も発⽣します。
攻撃を防ぐためには、OSI参照モデルのセッション層（第5層）およびアプリケーション層(第7層)において、以下の制限が必要です。
1つ⽬は「stateパラメータによるCSRF保護」です。
クライアントアプリはIDプロバイダーへの認証要求を送る前に nonce という、推測不可能な文字列を生成し、ローカルのセッション等に保存した上で要求パラメータに付与します。認証完了後にコールバックを行ったときに返却された state 値と 、保存した値が完全一致するかを検証することで、攻撃者による偽造された要求を防ぎます。
2つ⽬は「認可コードのライフサイクル制限」です。漏洩時のリスクやセッションハイジャックを防ぐため、認可コードは必ず「1回のみの使⽤」に制限し、10分で無効化する仕組みを実装します。
おわりに
会場の様子はこちらの記事がわかりやすいと思うので、紹介しておきます。
https://qiita.com/PenguinCabinet/items/56ed69a0171377b3ae9b
思い出としては、
Macばかりを使っていて、Winの操作に慣れるまで思ったより時間がかかってしまったことです。
おかげで、ターミナルの操作がボロボロでした。
8月のネクストに参加することが確定したので、今のうちからシェル周りを固めています。
では、またの機会に！！