ソースコードを読んでみよう
Ctrl+U やSourcesタブでページの「中身」を覗き、開発者が残してしまった認証情報・コメント・デバッグ用変数からフラグを発見するCTFの定番手法を体験します。
📋 目次
📄 Webページの三層構造｜ソースコードとは何か
すべての命令はブラウザに丸見えで送られている
クライアントサイドのコードはすべてユーザーが読める
Webサイトを動かすHTML・CSS・JavaScriptはすべて「クライアントサイド」のコードです。サーバーはこれらのファイルをそのままブラウザへ送信しており、ユーザーは開発者ツールや「ページのソースを表示」でいつでも内容を確認できます。「見えない＝安全」ではないことを理解することがセキュリティの第一歩です。
Webページは大きく3つの層で構成されています。HTML（構造）はページの骨格を定義し、見出し・段落・リンクといった要素を記述します。CSS（見た目）は色・フォント・レイアウトなど視覚的なスタイルを担います。JavaScript（動作）はボタンのクリック処理・フォームの検証・APIの呼び出しなど、インタラクティブな動作を実現します。
CTFにおいて重要なのは、これら3層のすべてが攻撃者（あなた）にとって読み取り可能だということです。開発者がデバッグのために残したコメント、テスト用の認証情報、まだ削除されていない設定値……こうした「うっかりミス」がCTFのフラグにつながります。
サーバーサイドのコードは見えない
PHPやPython（Django/Flask）・Node.jsなどのサーバーサイドコードは、サーバー上で実行された結果（HTMLなど）だけがブラウザに届きます。データベースの内容やサーバー上のファイルシステム情報は直接見えません。ただし、設定ミスや情報露出の脆弱性があれば、間接的に読み取れることもあります（それは上級編のトピックです）。
🔍 ソースを「覗く」3つのツール
目的に応じてツールを使い分ける
ソースコードを確認するには複数の方法があります。場面に応じて使い分けることで、より素早くフラグのヒントを見つけられます。
Ctrl+U（ページのソースを表示）
最も手軽な方法です。Ctrl+Uを押すと、新しいタブにページのHTMLソースが表示されます。埋め込まれたCSSやJavaScriptも含まれており、Ctrl+Fでキーワード検索できます。ChromeとFirefoxで使えます。「まず全体像を確認したい」という最初のステップに最適です。
Sourcesタブ（開発者ツール）
F12 → Sourcesタブを開くと、ページが読み込んだすべてのファイルがツリー形式で表示されます。外部JSファイル（app.js・main.min.js等）も個別に確認でき、ブレークポイント設定やステップ実行まで可能です。minified（圧縮）されたファイルは{}ボタン（Pretty-print）でコードを整形できます。
Networkタブ（前話との連携）
第6話で学んだNetworkタブを使うと、JavaScriptファイルやAPIレスポンスも確認できます。リクエスト一覧でTypeを「JS」や「Fetch/XHR」にフィルターすると対象ファイルが見つかります。Ctrl+Uでは見えないダイナミックに読み込まれるスクリプトの確認に有効です。
⚠️ 開発者のうっかりミス｜ソースに残るヒント
CTFで実際によく見かける「うっかりパターン」
CTFの問題は現実のWebセキュリティ脆弱性をベースに設計されています。「ソースコードに機密情報が残っている」問題は、実際の開発現場でも繰り返し発生するミスです。代表的なパターンを覚えておきましょう。
| パターン | 典型的な例 | どこを確認するか |
|---|---|---|
| HTMLコメント | <!-- admin password: abc123 --> | Ctrl+U → Ctrl+F で「password」検索 |
| JSコメント・TODO | // TODO: remove hardcoded key | Sourcesタブ → JSファイル → Pretty-print |
| ハードコード認証情報 | var ADMIN_PASS = 'secret!'; | Ctrl+U → Ctrl+F で「PASS」「CRED」「SECRET」 |
| デバッグ用変数・ログ | console.log('debug flag:', flag); | Consoleタブ（第2話参照）+ Sourcesタブ |
| APIキーの埋め込み | const API_KEY = 'sk-proj-xxx'; | Sourcesタブ → JS検索 → 「key」「token」「api」 |
| data属性への情報格納 | <div data-secret="flag{...}"> | Elementsタブ（第5話）+ Ctrl+U |
なぜこういうミスが起きるのか
開発時にはテスト環境で動作確認のために一時的に認証情報をソースに書くことがよくあります。本来はデプロイ前に削除・環境変数化するべきですが、「あとで直そう」がそのまま本番環境へ。バージョン管理（Gitなど）のコミット履歴に残り続けることもあります。CTFではこういった「現実的なミス」を模した問題が多く出題されます。
🧩 CTFで使うソース読み解きテクニック4選
実戦で役立つ検索・解析の手順
Ctrl+F でキーワード一撃検索
Ctrl+U でソースを開いたら、まず Ctrl+F でキーワード検索を試みます。探すべきキーワード：flag・CTF{・password・pass・secret・admin・token・key・TODO・FIXME・debug・cred。これだけで解ける問題が意外と多いです。
minifiedファイルをPretty-printで整形する
圧縮（minify）されたJSファイルは1行に詰め込まれていて読みにくいですが、Sourcesタブ左下の{}（Format）ボタンで整形できます。整形後にCtrl+Fでキーワード検索すると、変数名・文字列・コメントがすべて検索対象になります。本番サイトでよく使う手順です。
変数をたどる（コードトレース）
フラグが変数に代入されている場合、その変数がどこで使われているかをCtrl+Fで追跡します。例：var f = 'CTF' → f + と検索して文字列連結の全体像を把握。Base64エンコードや文字コード変換が挟まっている場合は、Consoleでatob(...)やString.fromCharCode(...)を実行して復元します。
ソースマップ（.map ファイル）を探す
本番JSファイルに対応するapp.js.mapが公開されている場合、元のソースコードをほぼそのまま復元できます。Sourcesタブで右クリック→「ソースマップを使用」でアクセスできることも。CTFでは明示的にこの手法を求める問題が出ることがあります。
🧩 5分CTFチャレンジ：クライアント認証を突破せよ！
ソースに残った認証情報を見つけてログインする
下の管理者ポータルは、JavaScriptのクライアントサイドで認証チェックを行っています。ソースコードに開発者がうっかり残した認証情報が埋め込まれています。Ctrl+U または Sourcesタブを開き、認証情報を見つけてログインしてください。
チャレンジの手順
① Ctrl+U でページのソースを開く（または F12 → Sourcesタブ） → ② Ctrl+F で「CRED」「pass」「TODO」などを検索 → ③ JavaScriptコメントの中にある認証情報を見つける → ④ 下のログインフォームにユーザー名とパスワードを入力 → ⑤ 管理者ダッシュボードが開いたらフラグを確認 → ⑥ 入力フォームに入力して正解！
⚠ このシステムは権限のある管理者のみアクセスできます。不正アクセスは記録されます。
クライアントサイドのソースコードから認証情報を発見しましたね。すばらしい！
フラグ：
⚠ 実際のWebアプリでは必ずサーバー側でセッション検証を行ってください。
上の管理者ポータルにログイン成功すると表示されるフラグを入力してください。フォーマットは CTF{...} です。
Ctrl+U でページのソースを開き、Ctrl+F で「CRED」または「TODO」または「pass」と検索してみてください。JavaScriptのコメントブロックに注目しましょう。
JavaScriptコメントの中に user と pass の情報が書かれています。それをそのままログインフォームに入力すると管理者ダッシュボードが開き、フラグが表示されます。
📝 まとめ＋FAQ＋次回予告
今回のポイントを振り返ろう
第8話では、Webページを構成するHTML・CSS・JavaScriptが「クライアントサイドにすべて送信される」という基本原則を学び、開発者のうっかりミスによりソースコードに残った認証情報を発見してクライアントサイド認証を突破する体験をしました。Ctrl+U と Ctrl+F は最もシンプルながら非常に強力なCTF入門ツールです。
・HTML/CSS/JSはすべてブラウザに送信されるためユーザーが読める
・Ctrl+U でページのHTMLソース全体を一瞬で表示できる
・Sourcesタブでは外部JSファイルも含めすべてのリソースを閲覧可能
・Ctrl+Fで「pass」「TODO」「secret」「admin」「key」を検索するのが基本
・minified JSは{}（Pretty-print）で整形してから読む
・クライアントサイドのみで認証チェックするWebアプリはCTFの格好の標的
Q. 本物のサイトのソースコードも同じように読めますか？
はい、Ctrl+Uや開発者ツールで読めます。ただし、「実際のサービスで認証情報が見つかった場合は脆弱性報告（バグバウンティ）を通じて報告する」のがエシカルなセキュリティ研究者の行動です。悪意ある利用は不正アクセス禁止法等に抵触します。CTFの学習で培ったスキルは許可されたテスト環境でのみ使用してください。
Q. Javascriptを難読化（obfuscate）したら安全ですか？
難読化はソースを読みにくくしますが、ブラウザが実行できる＝復元できる、という原則は変わりません。難読化されたJSはPretty-printや専用のdeobfuscatorツールで元に近い形に戻せます。難読化はセキュリティではなく、あくまで「読みにくくする措置」にすぎません。機密情報はサーバーサイドで管理することが唯一の答えです。
Q. Gitの履歴にも認証情報が残ることがあるってどういうことですか？
コードをGitでバージョン管理している場合、「一度コミットした内容は履歴に永久に残る」という特性があります。git logやgit diffで過去のコミットを遡ると、すでに削除した認証情報が見つかることがあります。GitHubなどに公開リポジトリとして上げた場合は即座に無効化・ローテーションが必要です。
Q. CTFでソースコードが圧縮・難読化されていたらどうしますか？
まずSourcesタブの{}（Format）でPretty-print。次にconsole.logでフラグに関係しそうな変数をダンプ。それでも難しければ、Deobfuscate.io・beautifier.ioなどの外部ツールに貼り付けてみます。デバッガー（第9話）でブレークポイントを設定して実行時の変数値を確認する方法も有効です。
JavaScriptデバッガーを使う
Sourcesタブのデバッガー機能でブレークポイントを設定し、実行中の変数値を覗いてフラグを入手するCTFテクニックを体験します。
📚 参考情報
- Chrome DevTools — Sources パネル公式ドキュメント（Google）
- OWASP「Sensitive Data Exposure」— A02:2021
- MDN Web Docs「View page source」（Mozilla）
コメント