セキュリティ・キャンプ 2025 全国大会 参加を決めた理由と応募課題メモ
はじめに
この記事の対象読者
- セキュリティ・キャンプに興味を持っている方・雰囲気を知りたい方
- 応募課題について書き方のコツを探している方
上記のような方々へ、私の経験をお話しできれば良いかなと思っています。参考にしていただき、是非ともセキュリティ・キャンプに参加してみてください。
なお、2に該当する読者もいるかと思いますので、この記事では主に応募課題と参加者について書いていきます。
↓当日参加レポート↓
記事の下部にも掲載します。
セキュリティ・キャンプって何？
「セキュリティ・キャンプ」は、学生に対して情報セキュリティに関する高度な技術教育を実施し、次代を担う情報セキュリティ人材を発掘・育成する事業です。2004年に開始され、現在はセキュリティ・キャンプを首都圏で毎年1回、ミニキャンプを毎年各地で10回程度開催しています。 セキュリティ・キャンプ及びセキュリティ・キャンプミニへ参加するには、応募課題を提出し、書類審査に通過する必要があります。
ということで全国からセキュリティに興味のある学生を集めて、合宿形式で講義や開発が行われます。
※上記動画は2023年時点ですので、2025年やそれ以降とは内容が異なる場合があります
今回はセキュリティ・キャンプ 2025 全国大会に参加してきましたので、どんな様子であるかを書いていきます。
著者について
- 大学1年生にて応用情報技術者試験に合格
- 大学3年生にて情報処理安全確保支援士試験に合格
- 大学4年生にてセキュリティ・キャンプ参加(専門B)
- 情報系のハッカソンやイベントに参加していたわけではない
- セキュリティ・キャンプに参加する前はこのような記事さえも書いていない
そもそもなぜ応募しようと思ったのか
元々、大学3年生の頃にCTF(Catch the flag)に参加したことがきっかけに情報セキュリティに興味を持ちました。その後セキュリティ・キャンプ 2024 全国大会の存在を知り,一度缶詰となり学習する1週間は面白そうと思うようになりました。しかし、その頃には既に応募は締め切られており、地方のセキュリティ・ミニキャンプに参加しました。
その後、2025年になり、セキュリティ・キャンプ 2025 全国大会の募集が始まったため、応募しました。
参加者について
どのような人が参加しているのか
セキュリティ・キャンプには、実に様々な方が参加してきます。
- Sechackに参加している方
- 自身でCTFを運営している方
- サークルなどを運営している方
- OSを魔改造している方
しかしながら、上記に該当しない方の参加も多いと感じています。更に大学生だけではなく、中学生・高校生・専門学校・高専生なども参加しています。
共通して言えることは、セキュリティに興味があり、各々様々な経験を持っているということです。
その経験に大きい小さいは関係なく、大きな一つの経験を持っている方がいれば、ほんの小さな経験をいくつも持っている方もいます。
学歴や経歴、資格などは本当にバラバラだなという印象を受けました。
自分って本当に参加できるの？
恐らく、セキュリティ・キャンプを知っている方は、「自分には縁のない世界だ」と思っている方も多いかと思います。
正直、私自身も上には上がいるという中で、「自分は本当にやっていけるだろうか」と不安に思うところがありましたが、ひとまず「申し込んでみよう、面白そうだから」という単純な動機で応募しています。
割と単純な動機であっても、行動に移すことが大切だと思います。
応募課題について
倍率について
セキュリティ・キャンプ 全国大会に参加するためには、応募課題というのを突破しなければなりません。
毎年倍率は高いようで、公式には具体的な数値は発表されていないが
参加にはエントリーと応募課題の提出が必要となる。前年の応募倍率はおよそ5～6倍だった。前回参加者からは「楽しんで学ぶことの大切さを学んだ。同志を見つけられてやる気が向上した」「さまざまな分野で活躍している人々と交流することで自分の世界が広がった」などの声が寄せられているという。
を見る限り、かなりの倍率になるらしいです。
何を意識して書くのか
実はIPAのホームページに意識してほしいことがちゃっかり書いてあります。下記は2025年の一部です。
残念ながらキャンプには募集定員がありますので、定員を超えた場合は参加者を選考する必要があります。選考では学校のテストのようにセキュリティの知識・技術力を点数化して行うのではなく、情報セキュリティに対する向き合い方（知識を深めたい意欲や、技術力を伸ばしたい熱意、課題に取り組む姿勢、考察の過程など）や、情報セキュリティを通じて社会をより良くしたいという気持ちをよく見て、総合的に判断しています。
応募課題には難しい課題があるかもしれません。回答が正解でなかったとしても、課題に対してどのようにして取り組んだか、そして何が得られたかなど、自分なりに調べて考えたことをしっかり記載いただき、応募してください。応募内容を見る講師たちは、どのような回答を応募してくれるかを毎年楽しみに拝見しています。
個人的には下記を意識して書きました。
- 自分がこれまで何をやってきたのかを記述する
- 成果だけではなく課題も併せて書く
- 課題に対し正解を書こうとは考えない
- 応募課題が難しいので正解ばかり考えていると挫折します...
- 分からないことは調べて「分からなかったから調べた」という旨を記述する
- 複数の視点から書くことを意識する
- 例えば、技術的な視点だけでなく、ビジネス的視点なども併せて書く
- 相手に人物像が見えるように書く
- 文章はなるべく簡潔に書く
- 箇条書きを使用する
- 句点(。)や改行などで文書の区切りをある程度つける
私は「応募課題は講師とのコミュニケーション」というように考えています。つまり応募課題は記述テストではなく、講師の方々に対し「自分はこういう人だ」というのを最初に伝える場です。したがって、ただ解答を書こうとするのではなく、読み手が自分について分かってもらうように書くことが重要です
私はそれを意識した結果、文書の中にこれまでの経験を入れたり、課題に取り組む際の思考過程を書いたり、例えにして自分の表現に落とし込むようになりました。(そのため文書が乱雑です。審査してくださった講師の皆様本当にごめんなさい...)
提出までは日をおいて見直し等をおこなっていたので、2~3日くらいかけたかなと思います。
ちなみに私が応募したコースの応募課題はChatGPTやGeminiといった生成AIを使ってよいとのことでしたので、最初のうちはドラフトを書いて、それをGeminiに添削させていましたが、文書が自分らしくないなと思い、途中からそのまま書くようにしました。
↓自分が参加した専門Bの応募課題↓
どのくらい書いたのか
自分は必答問題・選択問題の全てに回答しました。意外とどの選択問題も面白そうだなと思ったからです。
文字数としては、全部で1.2万字くらい書きました。
ただ、合格した方の中には2万字以上書いた方も普通におられたようです。
先人の応募課題の回答で色々と良いものがあるので、「セキュリティキャンプ 応募課題晒し」
などで調べてみて、いろいろな方の記事を見てみてください。
Q4,Q5の私の回答
私が出した応募課題のうちQ4とQ5の回答を一部抜粋して公開します。当時のものをそのまま掲載していますので、誤字脱字等はご容赦ください。
Q.4
(1)
私が興味を持ったのは「 DoubleClickjacking: A New Era of UI Redressing」です。
これは、ダブルクリックを行わせることで、ユーザーに意図しない権限の付与などを行わせる攻撃手法です。
(2)
この攻撃手法は、ユーザーに特定のボタンをダブルクリックさせ、意図しないボタンを押させることで、権限の付与や不正な操作を行わせるものです。以下にOAuth認証を行うWebアプリケーションにおける攻撃例を示します。OAuthを提供するサービスは別途ログイン操作を実施済みであり、Cookieにログイン情報が保存されている前提とします。
- ユーザーに特定のボタンをダブルクリックさせるように誘導する。この特定のボタンは次の画面のユーザーに意図せず押させたいボタンと同じ位置に配置する
- はじめのクリックにより、OAuth認可と行うページへ遷移させる
- 外部サービスのOAuth認証ページの「許可する」ボタンをクリックさせる(この際ユーザーは前のボタンをダブルクリックしたつもりでいるため、意図せず「許可する」ボタンを押してしまう)
- その後、ユーザーは意図せずOAuth認可を許可してしまい、アプリケーションに対し、外部サービスの情報へのアクセス権限を付与してしまう
(3)
元々、クリックジャッキングという手法があり、これは透明な<iframe>を利用し、ユーザーに意図せずボタンを押させる手法がありました。しかし、X-FRAME-OPTIONSヘッダーを利用することで、他のサイトの<iframe>を読み込まなくなり、クリックジャッキングは防止されるようになりました。
ダブルクリックジャッキングは、OAuthの認可がワンクリックで行えてしまうことが問題であると考えます。例えば、1つのページで同意にはチェックボックスと認可ボタンを配置し、チェックボックスにチェックを入れないと認可ボタンが押せないようにすることで、ダブルクリックジャッキングを防止することが可能と考えます。
実際にこの方法について説明しているページでは、どのようにすれば防止できるかを説明していました。
方法としては、マウスが動いているかどうかを確認し、マウスが動いていない状態でダブルクリックを行うと、ダブルクリックジャッキングの可能性があるため、ダブルクリックを無効化するという方法です。
チェックボックスを設置するという方法とともに実際に作成してみることにより、効果を検証しました。
まず、チェックボックスを設置する方法ですが、この方法は確実にダブルクリックジャッキングを防止することが可能です。
しかし、ユーザーにとっては、チェックボックスにチェックを入れるという手間が増えるため、その点のユーザビリティの低下に繋がる可能性もあります。
続いて、マウスが動いていない状態でダブルクリックを無効化する方法ですが、実際に実装したところ、ダブルクリックで認可が行われてしまいました。可能性としては私の実装に問題がある可能性もありますが、マウスの微細な動きに反応してしまった可能性も考えられます。そのため、この方法は、ダブルクリックジャッキングを防止することができない可能性があります。
実際にGithubやDropboxでは、ダブルクリックジャッキングを防止するために、アクセスしてから2秒程度はクリックできないようにするという方法を採用しているようです。
Q.5
(1)
今回は、Github + Google パスワードマネージャーのパスキーを実際に利用し、使用感を調査しました。今回のパスキーはGoogleアカウントに紐づくものでした。そのため、パスキーを利用するにはChromeブラウザが必要となります。この方法のパスキーを同期パスキーというようです。サインインの際には、上部にパスキーを使用する旨の表示が出て、共通のPINを入力し、サインイン処理が行われました。
この課題点として、サービスへのログインについて、Googleに依存してしまうことが挙げられます。これは、Googleアカウントが乗っ取られてしまった際のパスキーの漏洩の危険性があるということです。ユーザーとしては、Googleアカウントのパスワードを強固にしたり、2段階認証プロセスを有効にするなど、特段の対策が必要になります。また、Googleアカウントが何かしらの理由で、ロックされてしまうと、一切パスキーなどのサービスへアクセスすることができなくなり、他のサービスも連鎖的に利用できなくなる可能性があることです。そのため、重要なサービスについては、デバイス固定パスキーや別のサービスの同期パスキーといったサービスとの併用が必要になります。
(2)
認可とは、ユーザーに対し、特定のアクセス権限を与えることを指します。それに対し、認証とは、ユーザーの身元を確認することを指します。顔認証がかかっているオートロックがかかっている会社を例を挙げて説明すると、認可とは、ユーザーに対し、どの部屋にアクセスできるかを決定することです。認証とは顔認証でユーザーが誰であるかを確認します。仮にオフィスとサーバールームがあるとし、Aさんはオフィスにアクセスできるが、サーバールームにはアクセスできないとします。この場合、Aさんがサーバールームに入ろうとした際に認証に成功したが、サーバールームへの認可はされていないということになり、ドアは開きません。逆にオフィスの場合は、認証に成功し、オフィスへの認可もされているため、ドアは開きます。
さて、OAuth 2.0 や OpenID Connect（OIDC）とパスキーの仕様の関係についてですが、OAuth 2.0は認可のためのプロトコルであり、OpenID Connect（OIDC）は、OAuth 2.0を拡張し、認証を行えるようにしたプロトコルです。通常2つを併せて利用されることが多いです。但し、これらに認証の方法までは定義されていません。そのため、OAuth 2.0 や OpenID Connectの提供サービスへの認証の方法として、パスキーを利用することが可能です。
(3)
パスキーのメリットとして、3つ挙げられます。1つ目は。ユーザーによる文字情報の入力が不要となる点が挙げられる。これまでパスワードやSMS認証と行った方法で、ユーザーから文字情報の入力が必須であったが、パスキーを利用することにより、デバイスやブラウザに紐づいた認証情報が利用できます。
2つ目は、サーバー側にパスワードを保存する必要がなくなる点です。これまでのパスワード認証では、サーバー側にパスワードを保存する必要があり、そのパスワードが漏洩してしまうと、ユーザーのアカウントが乗っ取られてしまう危険性がありました。しかし、パスキーを利用することで、サーバー側が保存するべきデータはデバイスから送信される署名を検証するための公開鍵のみとなります。そのため、デバイス側から秘密鍵が漏洩しない限り、アカウントが乗っ取られる危険性は大幅に減少します。
3つ目は、パスキーを利用することで、フィッシング攻撃に対する耐性が向上する点です。これまでのパスワード認証では、フィッシングサイトに誘導されてしまうと、ユーザーは意図せずパスワードを入力してしまい、アカウントが乗っ取られてしまう危険性がありました。しかし、パスキーを利用することで、フィッシングサイトに誘導されても、端末内に保存されている秘密鍵はオリジン(ドメイン)と紐づいて保管されるため、フィッシングサイトを利用した、パスキーの盗難は非常に困難となります。そのため、フィッシング攻撃に対する耐性が向上します。
デメリットとしては、パスキーがデバイスあるいはサービスに依存してしまうということです。デバイスを紛失したり、何かしらの理由で提供サービスにアクセスできなくなってしまった場合は、パスキーを利用した認証ができなくなってしまいます。そのため、パスキーを利用する場合は、デバイス固定パスキーや同期パスキーといった複数の方法を併用する必要があります。
(4)
まずは、WebAuthnプロトコルが利用できるようにエンドポイントを追加する必要があります。恐らく、仕様上、https://example.com/auth/endpointのような特定のリンクのエンドポイントを追加する必要があると推察しますが、具体的なリンクについては調査できていません。
また、ユーザーごとに公開鍵を管理する必要があるため、その部分を管理できるようにデータベースの構成を変更する必要があります。
そして、サービスがパスキーによるサインインに対応できるように、バックエンド側の認証処理の変更が必要になります。
(5)
まず、パスワード認証の脆弱性や、ユーザーによる運用の現状について説明します。ここでは特にユーザーによるパスワードの使いまわしが多いことを説明します。
続いて、パスワード漏洩のリスクや影響について説明します。パスワードが漏洩すると、ユーザーのアカウントが乗っ取られ、不正利用されることを説明します。そして、他者のサービスからパスワードが漏洩した場合、弊社のサービスのアカウントにも影響が及ぶ可能性があることを強調します。
その後、パスキーを利用した認証のメリットについて説明します。パスキーを利用することで、パスワードを覚える必要がなくなり、フィッシングサイトなどでのパスワード漏洩のリスクが大幅に減少することを説明します。併せてSMS認証とも比較し、SMS認証はフィッシングサイトなどで誤って入力してしまうリスクを減少させることができないことを説明します。
最後にパスキーを導入することの会社に対するメリットを説明します。
パスキーを導入することで、ユーザーのパスワードを保存する必要がなくなり、パスワード漏洩による不正アクセスのリスクを大幅に減少させることができることを説明します。また、パスワード管理のコストや、パスワード漏洩による社会からの信用を失うリスクも減少することを説明します。
以上より、経営陣に向け、パスキーを導入することのメリットを説明し、導入を検討してもらうようにします。
次の記事
ここまで応募課題や参加者に関してまとめてみました。次の記事にて実際に参加した様子をまとめます
セキュリティ・キャンプの参加が決まった方へ
先にセキュリティ・キャンプを経験した身として、楽しむためのアドバイスを記します
- 名刺交換を口実にどんどん話そう!!
- 名刺交換をきっかけに色々な話ができると思います
- LT大会で発表しよう!!
- 発表するって緊張したり大変ですが、5分間ですので割と一瞬で過ぎさります。折角セキュキャンに挑戦したのですから、更にLTに挑戦してみてもいいと思います
- 分からないことはチューターや講師の方にどんどん質問しよう!!
- チューターも講師もプロです。折角のセキュキャンですから、機会をどんどん活用しましょう
その他、同じクラスのペンギン内閣さんがセキュリティキャンプを楽しむためのTipsを載せた記事を書いていますので、こちらも参考にしてみてください。
Discussion