初めまして、新月と言います。
2025年度のセキュリティキャンプの専門Bコースに申し込み、無事不合格となったためここに応募課題を供養しておきます。
敗因としては以下の通りだと思われます。
- 時間を十分に取れなかった(2時間で書いた)
- 時期が文化祭と完全に被っていた
- クラウドなどのモダンな技術をほぼ触ったことがなかった
- 課題で聞かれていることと若干ずれていることを書いていた(この記事にコピペしている時に気づきました。Q3など)
去年も落ちているので2年連続不合格です。
来年行きたいなと思いつつ2026年か、遠いなぁと思っています。
これから応募される方は自分を反面教師にして、頑張ってください。自分も頑張ります。
以下課題
セキュリティ・キャンプ全国大会2025
専門コースB【プロダクトセキュリティクラス】応募課題必答問題（Q.1 から Q.3 まで）の問題すべてと、選択問題（Q.4 から Q.6 まで）の中の少なくとも 1 問に解答してください。
【補足事項】
(1) この応募課題の設問は、どれも応募してくださるあなたの「現状の知識・経験の広さ・深さ」「興味・感心の範囲や強さ」を汲み取るためのものです。ぜひ自分の興味関心や知識、考えたこと、疑問等を各設問への解答として表現していただければと思います。
(2) 各設問で求めている内容が適切に盛り込まれている限り、解答の文字数の大小や日本語表現の巧拙は評価に大きな影響を与えません。また、日本語表現に関する軽微な誤りは評価に全く影響しません。とりわけ誤字脱字はあまり気にしなくて大丈夫です。
(3) 誇張を感じられる解答よりも、 ご自分の応募時点での経験や理解が真摯に表現できている解答を歓迎します。とりわけ、分からないことや確信の持てないことがあるときには「ここまでは分かったが、ここからは分からない」「これらの事例から ?でないかと推測できるが、?であると断言できるかは不明である」というような記述を含めていただけると嬉しいです。
(4) 選択問題においては「適切な論拠をもとにした、各設問に対して必要十分な情報を、適切な論理構造で表現できているか」を意識してください。
(5) 選択問題はきっかり 1 問のみ解答していただいても大丈夫です。2 問以上ご解答いただけると、選考においては、より応募してくださるあなたの魅力を汲み取りやすくなるかもしれません。なお、選びにくい問題・難易度が高そうな問題に挑戦している応募者の評価も高めになる傾向がありました。
(6) 解答に関して何かしらの実験を行う際には、法令等を必ず遵守してください。
(7) 最近著しい進化を遂げる LLM サービスを利用して解答を作成しても構いません。限られた期間で最大限によいと思える解答を作ること、それを通して自分の見識を広げるのに、それらの技術が貢献してくれるかもしれません。
【必答問題】
■ Q.1（応募のモチベーションについて）
「プロダクトセキュリティクラス」の講義のうち、特に受講したいと思う講義（複数可）に関して、その講義で「どのようなことを・なぜ学びたいか」を教えてください。とりわけ「なぜ学びたいか」の部分に関連して、いま応募を考えているあなたが感じておられる課題意識や、あなたの関心領域が伝わってくるような解答を歓迎します。
自分はB5『モダンなプロダクト開発を攻撃者の視点で捉える』を特に受講したいと考えています。
自分は最近バグバウンティに取り組んでいますが、クラウドやgithubなどのモダンな技術からのアプローチが苦手です。モダンな技術上で発生しうる脆弱性は、AWSなどの権限設定の不備による機微な情報の読み取りや、github上でのトークン露出、Ci/CDパイプラインの侵害など多くありその影響度も高いです。昨今のwebサービスの多くはクラウドで構成されており、webサービスそのものの脆弱性に限らず、その基盤部分であるクラウドや内部のCI/CDの部分の脆弱性を知ることでより多角的な視点が得られると考えています。以下の記事の様にawsでの権限設定不備の確認などは実際にバグバウンティでも行われますが、自分はクラウド運用の知識、経験不足からこのようなアプローチを十分に行えずにいます。
https://www.intigriti.com/researchers/blog/hacking-tools/hacking-misconfigured-aws-s3-buckets-a-complete-guide
これは自分の開発経験の少なさから生じるものであり、ぜひこの講義で不足しているクラウドやgithub等のモダンな技術の知識とそこで発生しうる脆弱性について学びたいと思っています。
プロダクトセキュリティクラスは自分の学びたい分野についての講義がとても充実しており特にB5の講義が、「バグバウンティ分野への応用」という上記したモダンな技術について学びたい理由にとても合致していて魅力を感じました。
また、自分はネットワーク分野、特にGSLBに興味がありこの技術が用いられるCDNなどで発生しうる脆弱性についても関心があります。そのためクラウドの中でもより基盤技術よりの部分でのセキュリティ的な懸念点や脆弱性、攻撃手法などを学べたらとても嬉しいです。
■ Q.2（これまでの経験について）
以下の経験について、差し支えのない範囲でできるだけ具体的に教えてください:
(1) Web アプリケーションの設計・開発経験（※ どんな些細なものでも構いません）
(2) パブリッククラウド技術の利用・構築経験（※ どんな些細なものでも構いません）
(3) 一般のプログラミングの経験やチームでの開発経験（※ 使ったことのある言語や、その用途などを教えてください。レイヤは問いません）
(4) コンテナ技術の利用経験
(5) CI/CD 環境のセットアップ・利用経験
なお、この問は「この応募課題を提出する時点での経験」を問うものです。この応募課題を見た時点での経験はなくても構いませんし、この応募課題の記入にあわせての学習を歓迎します。
(1)2024年度の桐朋祭にてホームページのバックエンド(特に投票機能)の設計を行いました。現在はドメインが失効していますが以下のwayback machineからアーカイブが閲覧可能です。
https://web.archive.org/web/20240624064609/https://tohofes-2024.net/
また先日行われた2025年度の桐朋祭にてコンピューター部のホームページ制作および公開の際に公開方法の検討及び実装のコードレビュー等を行いました。これは部員の自宅サーバからcloudflare tunnelを用いて公開されています。
以下のurlから閲覧可能です
https://tcc-archive.club/
いずれも期間中特に不具合無く動作しました。
(2)
バグバウンティの際にawsのバケットの認証不備などを確認するために用いるaws cliのセットアップとしてawsのiamを作成しました。また、2024年度のSecHack365にて内部でCTFを開催した際にCTFd及び問題サーバとしてawsを使用し運用、構築を行いました。
(3)
自分は2024年度のSecHack365にてC++で「fubuki」というGSLBに特化した権威DNSサーバ用ソフトウェアを開発しました。
権威DNSサーバの動作は以下のような流れとなっています。
パケットの受信
↓
データの解析
↓
応答の作成
↓
パケットの送信
パケットの受送信ではsocketを用いて非同期にipv4/ipv6のデュアルスタック環境での動作を可能にしています。
受信したパケットはパーサーに渡され、ここでRFCに従い解析が行われます。
以下はRFC1035に記載されているヘッダのフィールドの例です。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
ここではRFCを読み、わからないところは実際にパケットを見たりbindなどの実装を調べることで実装を行っています。
そうしてパケットは構造体として応答の作成を行う関数に渡されます。
ここではあらかじめ起動時に読み込まれるゾーンファイルからリソースレコードを読み出しドメインの階層構造を模したインメモリデータベースに格納されたデータを検索することで応答すべきレコードを特定しています。応答するレコードの制御部分にはluaを組み込むことが可能で、これにより柔軟な制御が可能となっています。
そうして最終的な応答に使われる構造体が作成され、それが実際にパケットとしてバイナリに直されます。ここでもRFCを読んだりパケットを見たり既存の実装を読んだりするなどして正常なパケットが作成される実装となっています。
また、これはGSLBに特化した権威DNSサーバ用ソフトウェアであるので、L3及びL4でのリアルタイムのヘルスチェックも実装されています。icmp及びtcpの任意ポートへの任意間隔でのヘルスチェック及びRTTやパケットロスなどのヘルスデータの取得をリアルタイムで行えることでより柔軟かつ精密な応答制御を可能にしています。このヘルスチェックとluaによる応答制御を用いることで様々な状況や用途に対応可能なGSLBに特化した権威DNSサーバ用ソフトウェアを実装しています。
以下は最終成果発表会で展示したポスターです。
https://sechack365.nict.go.jp/achievement/2024/pdf/17Dn.pdf
また脆弱性のpocを記述する際や簡単なツールを作成したりバグバウンティの際のreconを自動化するためにpythonやシェルスクリプトを使用しています。
(4)
自分は主にCTFを行う際に配布されたDockerfileやdocker-compose.ymlを用いて日常的に環境構築を行っています。またOSSのバグバウンティを行う際にはdockerコンテナ上に対象のOSSを稼働させています。
(5)
現時点では特にありません。(3)で紹介したfubukiの開発時にテストを記述しようと試みたものの機能の実装を優先したため結局使用しませんでした。
■ Q.3（あなたの感心・興味について）
Web に関連するサービス・プロダクトを作って提供することに関連する技術で、いまあなたが興味を持っているものがあれば、それについて自由に説明してください。少しでも Web との関連性がある技術であれば、それがハードウェア領域に近いものでも、ソフトウェア領域に近いものでも構いません。
自分はSSTIに興味を持っています。これはjinjaやtwigなどのテンプレートエンジンに悪意のあるペイロードを注入することで、通常は文字列として評価されるべきオブジェクトがコードとして評価され、それが実行されてしまうという脆弱性です。この脆弱性は主にサーバサイドでレンダリングを行う際に発生し、その高い影響度と攻撃の単純さからしばしば深刻な脆弱性となりえます。レンダリング時に発生する脆弱性という意味では、主にクライアントサイドで発生するのがxssでありサーバサイドで発生するのがSSTIと言えます。
この脆弱性はRCEに比較的簡単に繋がりうるにも関わらずレンダリングという頻繁に行われる処理に起因するので、攻撃が可能な範囲が広く発生した場合は深刻な脆弱性となりうるというとても厄介な脆弱性です。対策としてはそもそもコードとして評価されない様にレンダリングを行うという方法や、入力のsystemやexecなどの文字をフィルタリングするなどの方法があります。また、テンプレートエンジン自体がSSTIに対する対策を行っていることもあります。例えば以下のようにtwigではsandboxを用いてポリシーを設定することで悪意のあるペイロードをフィルタリングしたり、実行できる関数を制限したりすることが可能です。
https://twig.symfony.com/doc/3.x/sandbox.html
これらの対策を用いることで適切にレンダリングを行うことが可能になります。
しかしtwigで用いられるようなサンドボックスも設定不備などを悪用することでバイパスが可能となります。実際に自分が報告したCraftCMSにおけるSSTI(CVE-2025-46731)ではサンドボックスが設定されていたもののpopen()が使用可能だったためにサンドボックスをバイパスしRCEが可能となっています。
https://nvd.nist.gov/vuln/detail/cve-2025-46731
https://github.com/singetu0096/CVE-2025-46731
この様に適切な設定を行わなければテンプレートエンジン側での対策には限界があり、過信してはいけないことがわかります。
【選択問題】
■ Q.4（Web に関連する脆弱性・攻撃技術の検証）
「Top 10 web hacking techniques of 2024」( https://portswigger.net/research/top-10-web-hacking-techniques-of-2024 ) は、Web に関するセキュリティリサーチャーの投票により作成された、2024 年に報告された興味深い Web に関する攻撃テクニック 10 選です。この Top 10 中の事例の中で、興味を持てたもの 1 つに関して、以下を説明してください。
(1) 事例の概要
(2) 攻撃手法の詳細
(3) その他その事例に関して感じたこと・気がついたこと
なお、本設問では、関連する仕様や攻撃の適用可能な条件についての詳細な理解が垣間見えるような記述や、理解を深めるために行ったこと（例: ローカルで行った再現実験等）に関する記述を歓迎します。
(1)
私は「Unveiling TE.0 HTTP Request Smuggling」に興味を持ちました。
TE.0と呼ばれるhttp sumgglingの手法は、HTTP/1.1 の Transfer‑Encoding ヘッダーだけを送り、Content‑Length ヘッダーを省略することで、リバースプロキシとオリジンサーバのパーシングの食い違いを突く手法です。多くのプロキシ製品では「TE＋CL が両方あるとエラー」「CL だけならペイロードなし」「TE だけならチャンク付き」と実装しているため、この差異を悪用してリクエストを二重に通してしまいます。
実際に以下の記事ではGoogle IAPの解釈差異によってこの脆弱性を用いることでトークンの漏洩が発生すると述べられています。
https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/
(2)
まず攻撃者は、対象のAPIがOPTIONSやHEADといったボディなしメソッドを受け付けることを確認します。次に、HTTPリクエストにTransfer‑Encoding: chunkedのみを残し、あえてContent-Lengthを抜いたうえで、偽のチャンク終端を組み込んだ二重リクエストを構成します。たとえば以下のように最初はOPTIONSリクエスト、その後ろにGET /adminを連結したリクエストを送信すると、プロキシは「ペイロードなし」と判断してヘッダーをすぐにバックエンドへ転送し、接続を切りません。オリジンサーバ側は「チャンク付きだ」と解釈して残りバイトをすべて読み込み、偽終端以降の GET /admin を独立したリクエストとして処理してしまいます。その結果、本来アクセスできない管理者用エンドポイントに到達してしまうのです。
OPTIONS / HTTP/1.1
Host: victim.example
Transfer-Encoding: chunked
Connection: keep-alive
0
GET /admin HTTP/1.1
Host: victim.example
今までのhttpスマグリングはCLとTEの解釈差異を用いることでリクエストの密輸を行っていきました(CL.TEやTE.CLなど)が、今回はTEを0にすることでこれらと同じように解釈差異を発生させ、http request summglingを成功させています。
(3)
HTTP1.1の構文及びルーティングを定めたRFC7230には以下のような記述があります。
「A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field.」
ここではhttp sumgglingの可能性にも触れられており、MUST NOTという強い表現が使われています。しかし多くのプロキシやロードバランサはTE+CLの組み合わせはエラーとするもののTE単独のリクエストに対してはエラーにせずそのままチャンクとして扱ってしまうという挙動になっていました。これによりフロントエンドは「CLヘッダー不在＝ペイロードなし」と即座にバックエンドに転送しつつ接続を保持し、オリジンサーバは「TEあり＝チャンク付き」として後続バイトをすべてチャンク本体と誤認し、偽終端以降の第二リクエストを独立して処理してしまいます。まさに「Such a message might indicate an attempt to
perform request smuggling (Section 9.5) or response splitting
(Section 9.4) and ought to be handled as an error. 」というRFC7230内の記述のとおりであり、ヘッダ検証の重要性やプロトコル実装における規格への対応の重要性を実感しました。またこのような解釈差異を利用しとても綺麗に攻撃を成立させるこの手法に感動しました。
■ Q.5（パスキーに関連する標準や実装の調査）
(1) 任意のパスキーが使用されているサービスを実際に利用して使用感を調査したうえで、技術的・運用的・UXの観点から、あなたが課題だと思う点を述べてください。また、その解決策についても考えてください。なお、実際に利用できる環境にない場合はドキュメントの調査のみとして、使用感が分かる範囲で想像できる課題を考察してください。
(2) 認可と認証の違いについて、例を挙げて説明したうえで、OAuth 2.0 や OpenID Connect（OIDC）とパスキーの仕様（WebAuthn）の関係について説明してください。
(3) 従来の認証方式（パスワード、OTP、SMS認証など）と比較した場合、パスキーのメリットとデメリットを述べてください。
(4) 従来の認証方式（パスワード、OTP、SMS認証など）で提供されたWebアプリケーションにパスキーを実装するとき、サーバー側でどのような変更が必要ですか？
(5) あなたが企業のエンジニアだった場合、経営陣にパスキーの導入を提案するとしたら、どのようなポイントを説明しますか？
回答無し
■ Q.6（APIに関するセキュリティへの考慮）
(1) あなたが考える「APIに対する最大のセキュリティ脅威」を1つ挙げ、それに対する攻撃者の視点での調査プロセス（情報収集・攻撃手法の検討など）を考察し、それを防ぐための具体的な対策を述べてください。（ヒント：攻撃者の調査方法には、OSINT、リクエスト改ざん、脆弱性スキャン、レスポンス分析などが含まれます）
(2) マイクロサービスアーキテクチャでは、サービス間通信を安全に行うためのセキュリティ対策が必要です。マイクロサービス間のAPI通信におけるセキュリティ課題を1つ挙げ、それを解決するための手法を説明してください。
(3) APIゲートウェイは、マイクロサービスのエントリーポイントとして機能します。APIゲートウェイを導入することで防げるセキュリティリスクを1つ挙げ、それをどのように設定・運用すべきか説明してください。
(4) あなたのプロダクトのAPIが不正アクセスを受けている可能性があると判断された場合、どのようなログを確認し、どのような対応プロセスを取るべきか説明してください。
回答無し
いかがでしたでしょうか。今回は自分でもあまり満足できない出来だと思っています。
来年こそはちゃんと時間を割いて、胸を張って最高の回答だと言えるものを出したいです。
ここまで見て頂きありがとうございました。
Views: 0
