支援士講座 - 情報処理安全確保支援士

1.HTTPの基礎を復習
2.Webフォームを作成してみよう
3.HTTPレスポンスヘッダのセキュリティに関する項目
- 3.1 全体像
- 3.2 HSTS
4.セッション管理
5.クロスサイト攻撃
- 5.1 XSS
- 5.2 クロスサイトリクエストフォージェリ
6.その他の攻撃
7.攻撃と対策のまとめ
8.FIDO
9.認証連携
10.メールセキュリティ
- 10.1 メールの基本
- 10.2 メールのセキュリティ
11.脆弱性管理
12. DDoS攻撃と対策
13.TLSのシーケンス
- 13.2 暗号化スイート
14.ネットワークセキュリティ
- 14.1 DNSセキュリティ
15.Linuxのコマンド等
16.説明し忘れ

イベント概要はこちらです。
https://nespe.connpass.com/event/344641/

1.HTTPの基礎を復習

1.1 HTTPのリクエストとレスポンス

https://nw.seeeko.com/archives/http#2http%E3%81%AE%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%81%A8%E3%83%AC%E3%82%B9%E3%83%9D%E3%83%B3%E3%82%B9
・「(2)実際のパケットを見てみましょう。」は、指定されたIPアドレスに対して、http://（指定されたIPアドレス）　に接続してWiresharkで確認しましょう。

1.2 HTTPヘッダとメッセージボディ

https://sc.seeeko.com/entry/http#11-HTTP%E3%81%AE%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%81%A8%E3%83%AC%E3%82%B9%E3%83%9D%E3%83%B3%E3%82%B9
ここで、改行コードを意図的に入れることで、HTTPヘッダインジェクション攻撃につながります。

1.3 （参考）Linuxへのアクセス

実際に触ってみたい人は、休憩やら合間時間に触ってみてください。

(1)事前作業（主催者）

以下を実行しています。

# パスワードを設定
PASSWORD="****（秘密）****"

# ユーザおよびディレクトリの作成とアクセス権限
for i in $(seq 1 310); do
  useradd -m -s /bin/bash user${i}
  echo "user${i}:${PASSWORD}" | chpasswd

  mkdir /var/www/html/user${i}
  chown user${i}:user${i} /var/www/html/user${i}
done

# ログファイルへのアクセス権の付与
chmod o+r+x /var/log/httpd

(2)皆さんの作業

TeratermでSSH接続する。IPアドレスとPWは別途指示
Googleスプレッドシートに自分のユーザ名を予約してください。

#自分のディレクトリに移動。4のところは、自分のユーザ番号
cd /var/www/html/user4/         
#初期ファイルの作成（中身はhelloのみ）
echo hello>./index.html

lsコマンドで、ファイルが作成されているか確認しましょう。

[user4@xxx user4]$ ls
index.html

いかのどちらかに接続すると、helloの文字が表示されたWebページにアクセスできるはずです。

http://IPアドレス/user4/index.html
http://IPアドレス/user4/

(3)参考：Linuxにおけるエディタの操作

今回はLinuxの研修ではなく、あくまでも支援士の研修です。よって、Linuxの説明はしませんが、操作に慣れた人はやってみるといいでしょう。
以下のサイトに、古くからある標準のテキストエディタであるvi、または、改良版（iMproved)のvimの基本的な操作がまとまっています。
eng-entrance.com
最低限の操作であれば、以下だけ覚えておきましょう。
・i　で編集モードにする
・ESCで編集モードを抜ける　-->　ESCキーを押した後、Shift を押しながらzzで保存
　　　　　　　　　　　　　-->　ESCキーを押した後、間違えて保存したくないなら :q!　
では、以下でエディタを開き、好きな文字を入れてみましょう。HTMLの構文にする必要はありません。

cd /var/www/html/user4/
vi index.html

1.4 メソッド

情報処理安全確保支援士のR6秋問3では、このようにメソッドやステータスコードが表示されています。

Wiresharkで先ほどの通信を見てみると、以下のようになっていると思います。Webサーバのログとは違うのですが、項目はなんとなく対比できることでしょう。

Q.GETとPOST、PUTの違いは？

A.ここを参照ください。

Q.上記URLにおける、「過去問（H23AP問9設問1）」を解く

1.5 ステータスコード

・こちらを参照
・上記において、過去問（H25SC秋午後Ⅱ問1）を解く。

1.6 User-Agent

・こちらを参照してください。ただ、直近の試験ではほぼ出ていない。
・上記サイトにて、過去問（R1秋SC午後2問2）の問題を解く
・あとで、Linuxサーバにアクセスし、ログを見てみましょう。あなたの接続ログのUser-Agentは？

1.7 ログの確認

この問題では、しばしログを見る問題が登場します。たとえば、先ほどの1.4 メソッド(1)概要ログで紹介したものや、似たようなログとしてプロキシサーバのログも登場します。
以下はR6秋問１のプロキシサーバのログです。特徴としては、利用者IDや、フィルタアクション（許可や拒否）が含まれています。

にも慣れておきましょう。

(1)Webサーバのログ確認

・主催者から指定されたWebサーバに接続してください。（例）http://54.95.xx.yy
・自分のグローバルIPアドレスを調べます。
　ネットで「自分のIPアドレス」などで検索すると、調査してくれるサイトが表示されます。例）
https://www.cman.jp/network/support/go_access.cgi
・ログファイルを見てみましょう。
- CentOSの場合：/var/log/httpd/access_log
・Logがたくさんありますね。これではどれが自分のログかがわかりません。そこで、grepを使って、自分のIPアドレスのログがあるかを確認します。

cat /var/log/httpd/access_log | grep 203.113.0.132

(2)ログの内容の確認

・Q.先ほどのログの項目を全て説明してください。

A.解説は以下にありますが、ポイントだけ。
・200は、ステータスコードで、200 OK
・その次はレスポンスボディのサイズ（バイト数）
・その次の"-" は、Referer 。この例では参照元ページが無かった（直接アクセスされた）。
・Mozilla/5.0 ...　は、User-Agent。
・過去問（H30SC秋午後Ⅱ問2）を基にしたログはこちらで解説。
　また、このリンク先の後半に、宿題とした問題があります。

1.8 エンコーディング

特にパーセントエンコーディングは軽くみておきましょう。
https://sc.seeeko.com/entry/about_encryption#6%E3%82%A8%E3%83%B3%E3%82%B3%E3%83%BC%E3%83%89

2.Webフォームを作成してみよう

2.1 入力フォーム

ここからはエディタが操作できないと難しいので、分からない人は講師の画面で確認ください。

(1)フォームの作成

作業としては、以下のコマンドにて、login.htmlファイルを作成します。

cd /var/www/html/
cd user4
vi login.html
vi result.php

作成するファイルは以下の2つです。

login.html
<FORM ACTION="result.php" METHOD="POST"> ID：<INPUT TYPE="text" NAME="id" VALUE=""><br> <INPUT TYPE="submit" VALUE="Login"> </FORM>

result.php ※結果表示のスクリプト
<?php print($_REQUEST['id']); ?> さん、ログインしました。

(2)結果の確認

❶講師用共有のサイト（ http://54.95.x.y/page/login.html )または、各人のサイトhttp://IPアドレス/user4/login.htmlに接続してください。

❷IDとしてshienshiを入力します。

❸Loginボタンを押す。
その結果、遷移後の画面（result.php）は以下のようになる。

2.2 input要素

(1)概要説明

input要素には，データを入力したり送信したりするためのさまざまなタイプ（type属性）があります。

タイプ	説明
text	1行のテキスト入力欄を表示。ユーザーが自由にテキストを入力できます。
password	パスワード入力欄を表示。入力された文字がマスクされます。
hidden	非表示の入力欄。hidden（直訳すると「隠された」）のとおりで画面に表示することはありません。利用者に見せることなくデータをフォームに埋め込んで送信できます。セッション管理に利用される場合もあります

(2)passwordに変更

❶login.htmlにおいて、INPUT TYPE="text" の部分をpasswordに変更します。
❷すると今度は、入力した文字がマスクされます。

❸Loginボタンを押してみましょう。
遷移後の画面（result.php）は同じです。

(3)hiddenに変更

❶login.htmlにおいて、INPUT TYPE="text" の部分をhiddenに変更します。
・参考ですが、過去問（R6秋問4)だとこんな感じで出題されました。セッション管理に利用されています。

・参考ついでに、valueについて整理しておきます。

属性	入力できるか*	valueの意味*	実際に送信される値
type="text"	ユーザーが変更可能	初期値	ユーザーがFormに入力した値
type="hidden"	ユーザーは変更不可	送信する固定値（初期値＝送信値）	valueに書かれた内容

❷今度は、入力欄が表示されなくなりました。

hiddenの場合、ユーザに入力させるのではなく、画面上では見えない形でパラメータを受け渡すなどに利用されます。
❸VALUE="shienshi"として値を指定しましょう。

login.html
<FORM ACTION="result.php" METHOD="POST"> ID：<INPUT TYPE="text" NAME="id" VALUE="shienshi"><br> <INPUT TYPE="submit" VALUE="Login"> </FORM>

❹Loginボタンを押してみましょう。
遷移後の画面（result.php）は、先と同様にshienshiの文字が見えます。

❺参考：実際の送信データ
hiddenフィールドの情報は、HTTPリクエストの「ボディ」に入り、wiresharkなどでパケットを見ると、以下のように送信されます。

id=shienshi

渡す情報が複数の場合、以下のように&でつなげて送信されます。

id=shienshi&name=user1

2.3 POSTとGETの違い

https://sc.seeeko.com/entry/http#2POST%E3%81%A8GET%E3%81%A8%E3%81%84%E3%81%862%E3%81%A4%E3%81%AE%E3%83%A1%E3%82%BD%E3%83%83%E3%83%89

3.HTTPレスポンスヘッダのセキュリティに関する項目

3.1 全体像

HTTPレスポンスヘッダには、セキュリティに関する重要な項目がいくつかあります。

3.2 HSTS

・HSTS（HTTP Strict Transport Security）の基本的な解説はこちらに記載しています。
・支援士R6秋の午後問4設問1(5) p284～解説も参照ください。
・問題を1問解きましょう。以下のStrict Transport Securityに関して、空欄eを答えよ。

A.解答例：Mサイトへの接続をHTTPSに強制することができる。

Q.HSTSとCookieのSecure属性は、どちらもHTTPSを強制するようことが目的に見えるが、何が違う？

A.以下に整理します。

項目	CookieのSecure属性	HSTS (HTTP Strict Transport Security)
レイヤ	Cookie単位	ドメイン全体
目的	CookieをHTTPで送らせない	ブラウザをHTTPSに強制リダイレクト
防げる攻撃	Cookie盗聴（セッションID漏洩）	通信盗聴・改ざん、中間者攻撃など

4.セッション管理

4.1 セッション管理の概要

セッション管理の方法は、以下に整理しています。
https://sc.seeeko.com/entry/session
「(2)Cookieの内容」まで。

4.2 実際にやってみよう

今回は、以下のサイトを参考にさせてもらいました。
https://codelikes.com/php-session/

(1)Cookieの取得を確認

❶login.html に接続　
・以下に接続してください。
http://指示されたIPアドレス/session/login.html
・HTTPリクエストやレスポンスにCookieが無いことを確認します。

❷user1でログインします。
ユーザ名は何でもいいのですが、user1、パスワードはpassとしました。

ログインすると、ログイン後のホーム画面（home.php）にリダイレクト（302）されます。このとき、Set-Cookieにて、セッションとなるPHPSESSIDが払い出されます。

❸home.phpに接続
利用者のブラウザは、リダイレクトされるので自動でhome.phpに接続するのですが、このとき、Cookieによるセッション情報を保持します。
HTTPリクエストヘッダに、CookieとしてPHPSESSIDが記載されていることが確認できます。

❹ブラウザで、Cookieを確認
F12を押して開発者ツールを起動します。アプリケーションタブ（英語の場合はapplicationと表示）で、先ほどWiresharkで確認したCookieの値が確認できることでしょう。

❺マイページに行って、ボタンを押してみよう。
セッション情報を管理しているので、毎回Cookieを押すことで、自分のカウントも保持される。

❻どこでセッションを管理しているか
セッション情報は、サーバのどこで管理されているか。今回の場合、/var/lib/php/sessionです。

#フォルダの移動
cd /var/lib/php/session
#user1のセッション情報を探す
grep -r user1
sess_a1gv9juku1dqheem5t37s5nqs1:userId|s:5:"user1";

これを見てもらうと、先ほどWiresharkで確認したセッションIDと同じ情報が保管されていることがわかります。
※chmod o+x+r -R /var/lib/php/session/で権限付与しています。

(2)簡単なセッションハイジャックをやってみよう

❶Cookieを削除しましょう。
開発者ツールでは、Cookieを書き換えることができます。違う値に書き換えて、F5でページをリロードしてみましょう。「○○さん、」の部分はどうなりましたか？
❷Cookieを他のセッションに変えてみましょう
ブラウザを立ち上げ、別のユーザであるuser2を作成してみましょう。そのユーザのCookieを確認し、先ほどのCookieのセッションIDに書き換えてみましょう。
セッションを乗っ取り、user2を表示することができましたか？

(3)セッションハイジャックの理解

・このページで内容を確認
・セッションハイジャックの対策を理解する。Cookieのどれを使えばいい？？

(4)セッションフィクセーション攻撃

・支援士R6の秋午後問4設問1(1) p277～解説
・ここで、セッションIDを強制的に利用させる方法は、p281の設問1(3)の解説
・セッションフィクセーション攻撃の対策はこちら。もちろん、セッションハイジャック攻撃の対策であるCookieの対策は実施しましょう。

4.3 Cookieの属性

(1)全体像

復習を兼ねて、全体を確認
https://sc.seeeko.com/entry/session#2Cookie%E3%81%AE%E5%86%85%E5%AE%B9

(2)HTTPonly

https://memo.seeeko.com/entry/httponly

(3)SameSite属性

支援士R6春の午後問3設問2(2) p107～解説
Noneなどにしていると、わなサイトからの怪しいPOSTの通信であるにもかかわらず、セッション情報が送られるので、正しいリクエストとして処理されてしまいます。（つまり、情報が書き換えられたりします）

5.クロスサイト攻撃

5.1 XSS

(1)概要

・クロスサイトスクリプティングの概要を、情報セキュリティの教科書のp119から解説。反射型、格納型、DOM型の3つがあります。
・3つの比較をH26秋PM2-2の解説（セスペ26秋）から紹介します。

(2)反射型XSSをやってみる

では、実際にやってみましょう。
R3秋SC午後Ⅱ問1の内容をもとに、実際にPHPで動作を確認しましょう。
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000apad-att/2021r03a_sc_pm2_qs.pdf
ページは以下。

❶（備考欄に着目して）なにも対処しないページを作る。
・description.php

<html>
<meta http-equiv="content-type" charset="UTF-8">
備考：
<form action="./submitdescription.php" method="post">
    <input type="text" name="description" value=""><br>
    <input type="submit" value="内容を確認する" >
</form>
</html>

以下のフォームができる。文字を入力しよう。

・submitdescription.php

<html>
<meta http-equiv="content-type" charset="UTF-8">
備考：
<?php
print($_REQUEST['description']);　
?>
です。
</html>

送信ボタンを押した後の画面

❷XSSを仕掛けてみる
ここで、入力フォームに以下を入れる。

<script>alert('XSS!')</script>

すると、アラートが出る

これが、XSSの脆弱性である。

❸悪質な警告を出す。
Alertでは、もちろん日本語も入力できます。
ただ、メールをクリックさせるので、メールのときは以下のようにUnicodeエスケープシーケンスに変換して、なにが書いてあるかわからないようにしてあるかもしれません。※エスケープシーケンスとは、文字列中に通常の文字としては使えない特殊な文字（例えば改行やタブ、または特定の記号など）を表現するための、決められた記法です。

<script>
alert('\u3042\u306a\u305f\u306e\u30d1\u30bd\u30b3\u30f3\u304c\u30a6\u30a4\u30eb\u30b9\u611f\u67d3\u3057\u307e\u3057\u305f\u3002\u3044\u307e\u3059\u3050paypay\u30670801254XXX\u306b5000\u5186\u9001\u91d1\u3057\u3066\u304f\u3060\u3055\u3044\u3002\u5bfe\u51e6\u65b9\u6cd5\u3092\u9023\u7d61\u3057\u307e\u3059');
</script>

❹別のページに遷移させる
先の入力フォームで、以下をいれてみよう。

<script>window.open('https://sc.seeeko.com');</script>

すると、私の支援士のページに自動で遷移してしまう。

http://www.example.com/submitdescription.php?description=%3Cscript%3Ewindow.open%28%27https%3A%2F%2Fsc.seeeko.com%27%29%3B%3C%2Fscript%3E

もし、www.example.comが著名なサイト（でも、XSSの脆弱性あり）であった場合、上記のリンクを以下のメールで広く送ったとします。※今回の演習の場合、前半はhttp://x.x.x.x/page/submitdescription.php?description= になると思います。

ご利用の会員の皆様

以下の弊社サイトから、パスワード変更をお願いします。
http://www.example.com/submitdescription.php?description=%3Cscript%3Ewindow.open%28%27https%3A%2F%2Fsc.seeeko.com%27%29%3B%3C%2Fscript%3E

www.example.comの安全なサイトと思ってクリックする可能性がある。でも、実際には、私のページに遷移する。こうやって複数のサイトをまたいで（クロスして）、攻撃をするのがクロスサイトスクリプティング（XSS）。

(3)DOM型XSSをやってみる

（女性）反射型のXSSとDOMベースのXSSの違いがあまり分かりません
一番の違いは，問題文にあるように「DOMベースのXSSでは攻撃者が注入するデータがWebサイトからの応答中に出力されない」ということである。
図２のスクリプトを簡単に言うと、「リンクのうちハッシュ（＃）以降の文字列をブラウザに表示しなさい」ということである。ハッシュ（＃）以降はサーバには送られず，クライアントがリクエストを受け取るまで保持している。Webサーバからの命令（図２のスクリプト）を受け取ったクライアントは，保持しているハッシュ（＃）以降の文字列を表示（実行）してしまう。

・まず、DOMを体験してみましょう。こちらのサンプルを動かしてみてください。
http://54.95.x.y/page/dom.html
・つづいて、サンプルスクリプトを実行してみましょう。
URLはhttp://5x.x.x54/page/dom2.html
次に、#のあとに数字を入れてリロード。http://5x.x.x54/page/dom2.html#456
・サンプルスクリプトも入れてみましょう。
・この攻撃を解説すると、このようなdocument.write を使ったWebページを用意すると、攻撃者の踏み台にされてしまいます。しかも、#以降はサーバに送られないので、ログにも残らず、不正をされたことも気が付かないことでしょう。
・攻撃者は、反射型XSSと同様に、#以降にスクリプトを仕掛けたメールを送り、正規の利用者にそれを踏ませることで、情報搾取だったり、フィッシングページに遷移させたりします。

(4)対策

・脆弱なページを作らない
・Content-Security-Policy (CSP)

5.2 クロスサイトリクエストフォージェリ

・情報セキュリティの教科書のp120から解説。
・こちらでも解説
・Q.CSRFの対策を述べよ。

6.その他の攻撃

6.1 クリックジャッキング攻撃

(1)概要

概要はこちら
以下を実行してみましょう。
http://54.95.x.y/page/cj.html
http://54.95.x.y/page/cj2.html
こちらを見ると、攻撃がうまく仕掛けられていないページが見えます。
http://54.95.x.y/page/cj3.html

Q.ちなみに、iframeのページは、手前側ですか？奥側ですか？
↓
↓
↓
A.「手前」と覚えてください。

(2)過去問を解いてみよう

R4春SC午後Ⅱ問1です。

↓
↓
↓
↓
↓
↓
A.解答例：空欄c：イ空欄d：ア空欄e：ア
空欄f：ア空欄g：イ空欄h：イ
※詳しくは、支援士R4のp88～

(3)対策

過去問にズバリ解説があります。

支援士R4のp90～
・こちらと、こちらの記事も参照ください。

6.2 SQLインジェクション攻撃

・概要はこちら
・以下のページで試してみよう
http://54.95.x.y/sql/
・❶R7春SC午後問2

Q1.この問題ですが、「クエリパラメータarticleの値はSQLでの検索では数値型として扱われる。」という条件があります。「コンテンツ番号がＤＢサーバに存在しない場合、又はSQLが構文エラーになる場合は、”コンテンツがありません”というメッセージを返す。」という条件が無い前提で答えてください。
↓
↓
解答例

sql文は、数値型なので、SQL文には、シングルクォーテーションなどがなく、
たとえば、select * from data where article=$article　などになっていると思われる
a：エ（内部エラー）
b：エ（内部エラー）
c：エ（内部エラー）
d：ア（コンテンツがありません）
e：イ（2025年4月1日のキャンペーンのコンテンツ）
・Q2.この問題ですが、「クエリパラメータarticleの値はSQLでの検索では数値型として扱われる。」という条件が無い前提で答えてください。つまり、文字型です。
↓
↓
↓
↓
↓
↓
↓
↓
解答例：
文字列型の場合、WHERE article = '<入力値>'のように、シングルクォーテーションが入ることになります。

項番	入力値（URLデコード後）	実際のSQL文	結果
1	article=20250401	SELECT … FROM articles WHERE article = '20250401';	コンテンツあり（2025年4月1日の記事が返る）
2（空欄a）	article=20250401'	SELECT … FROM articles WHERE article = '20250401'';	構文エラー（クォート不整合）（選択肢エ）
3（空欄b）	article=20250401' and 'a'='a	SELECT … FROM articles WHERE article = '20250401' and 'a'='a';	常に真 → コンテンツあり（4/1の記事が返る）（選択肢イ）
4（空欄c）	article=20250401' and 'a'='b	SELECT … FROM articles WHERE article = '20250401' and 'a'='b';	常に偽 → コンテンツなし（選択肢ア）
5（空欄d）	article=20250401 and 1=0	SELECT … FROM articles WHERE article = '20250401 and 1=0';	文字列一致せず → コンテンツなし（選択肢ア）
6（空欄e）	article=20250401 and 1=1	SELECT … FROM articles WHERE article = '20250401 and 1=1';	文字列一致せず → コンテンツなし（選択肢ア）

6.3 OSコマンドインジェクション

・概要はこちら
（・参考：セキュリティの教科書 p113～）
・実際に試してみましょう。実際にサーバに接続し、2つのパターンで、攻撃コードを入れてみましょう。
攻撃１：whoコマンドを実行する
攻撃２：/etc/passwdファイルを表示する
・サーバ１は、http://54.95.x.y/page/ping.php に接続してください。

exec("ping -c 1 $ipaddress", $output, $retval);

・サーバ２：http://54.95.x.y/page/ping2.php に接続してください。

exec("ping -c 1 '$ipaddress'", $output, $retval);

★主催者メモ
https://memo.seeeko.com/entry/2024/01/30/141427

6.4 HTTPヘッダインジェクション

・概要はこちら
・Q.インジェクションをするのは、HTTPリクエストのヘッダ？それともHTTPレスポンスのヘッダ？　→解説は上記のURLに記載
・Q.どんな攻撃ができそう？　→解説は上記のURLに記載

6.5 メールヘッダインジェクション

・セキュリティの教科書 p116をみましょう。もう、おおむね理解はできたと思います。
・Q.では、どんな攻撃が考えられますか？
https://sc.seeeko.com/entry/mail_injection

6.6 SSRF

・サーバーサイドリクエストフォージェリの概要はこちら
・R6春SC午後問3を見てみましょう。

・Q1.図7のGETメソッドの行は何をしていますか？

A.ブラウザ（クライアント）が Web サーバに対して「/top というパスのリソースを page というクエリ文字列付きで取得したい（GET）」と要求している。pageのパラメータはhttps://△△△.jp/topic/202404.html
Webサーバ側は、pageのパラメータを活用した上で、なんらかのページを表示する。
・Q2.これにより、どんな攻撃のリスクが考えられるか

A.解答は3つほど準備しました。
・オープンリダイレクト：攻撃者が悪意あるURLを指定して、利用者を外部サイトへ誘導できる。
・SSRF（Server-Side Request Forgery）：サーバが内部のURLへアクセスしてしまう。
・XSS：読み込んだページの内容がそのまま出力される場合、スクリプトが混入する可能性。
・実際、以下のような攻撃が成立したようです。

・（攻撃ではない）本来の動作
　利用者は，サイトPの新着情報を取得するために，商品企画サイトY（サイトY）にアクセスします（次ページ図❶）。このときのHTTPリクエストは，図7にあるとおりです。「page=」として，サイトP（https://△△△.jp）のURLが記載されています。HTTPリクエストを受け取ったWebサーバYは，情報交換サイト（サイトP）のコンテンツを取得し（❷），利用者にレスポンスを返します。

・攻撃者の動作
　攻撃者はこの仕組みを悪用して，IMDSから情報を搾取します。先の図7のGETにおいて，page=の部分を，IMDSのURLに変更してサイトYにアクセスします（上図❸）。その結果，IMDSの情報を攻撃者が入手してしまいます（上図❹）

7.攻撃と対策のまとめ

攻撃と対策の復習です。

攻撃経路	典型的な手口	主な対策
セッション固定 (Fixation)	攻撃者が用意したSIDを被害者に使わせる	ログイン成功時のセッションID再発行
盗聴	通信の盗聴、Cookieを傍受	CookieのSecure属性 HSTS (Strict-Transport-Security)
XSS経由の奪取	悪意あるJavaScriptでCookieを盗む	エスケープ処理（無害化） CookieにHttpOnly属性 CSP(Content Security Policy)
CSRF	偽ページから利用者のセッションでリクエストを送信	CSRFトークン実装 CookieにSameSite属性 Refererのチェック
クリックジャッキング	iframeに埋め込む	HTTPレスポンスヘッダにてContent-Security-PolicyとX-Frame-Optionsを適切に指定する

8.FIDO

https://sc.seeeko.com/entry/auth#8FIDO
上記の中の以下を解いてみましょう。
❶R6年SC午前2問7
❸R5SC秋問3　→オリジンという言葉

9.認証連携

9.1 SAML

・情報セキュリティの教科書　p170～
・SAML
・やり取りする主な内容として、
　a)SPがSAML Requestを作成し、ブラウザを経由してIdPに送信
　b)IdPは、認証結果を含めたSAML Response をSPに返す。
・問題として、(6)SAMLのフロー③を解く。登場人物がどれかを理解する

9.2 OAuth

・情報セキュリティの教科書　p170～
・ポイントは、認証ではなく認可の仕組みであること、トークンを発行して、リソースへのアクセスを許可すること
・認可サーバが認可コードを発行し、それをもとに、トークンを要求する。※認可コード→トークンの2段階で実施
・SAMLとOAuthの共通点を確認

9.3 OIDC

・内容が難しいので、概要だけを説明します。

10.メールセキュリティ

10.1 メールの基本

・メールサーバの構成に関してはこちら
・Q.メールの送受信プロトコルと、それに対する暗号化通信のプロトコルを答えよ。
A.正解はこちら
・メールのエンベロープとヘッダについてはこちら
・電子メールのヘッダはこちら
Q.過去問３（H25SC春午前2問20）を解きましょう。
Q.一番新しいサーバはどこに記載される？

・メールを開いて、メールヘッダを見てみよう。

Return-Path: <alice@example.com>
Received: from mail.example.com (localhost [127.0.0.1])
    by mail.example.com (8.16.1/8.16.1) with ESMTP id 57J25tAK014389
    for <bob@sample.net>; Tue, 19 Aug 2025 11:05:55 +0900 (JST)
    (envelope-from alice@example.com)
Received: ・・・
Received: ・・・
ARC-Authentication-Results: i=1; sample.net;
        spf=pass smtp.mailfrom=alice@example.com smtp.helo=mail-io1-f52.google.com;
        dkim=pass (good signature) header.d=gmail.com header.s=20230601;
        arc=none;
Received: by mail-io1-f52.google.com with SMTP id d2e1a72fcca58-76e2eb9ae80so3661866b3a.3
        for <bob@sample.net>; Mon, 18 Aug 2025 19:05:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1755569152; x=1756173952; darn=sample.net;
        h=subject:from:to:content-language:user-agent:mime-version:date
         :message-id:from:to:cc:subject:date:message-id:reply-to;
        bh=3OT/5Fd7hrjUIkjIi/lDSbBwKYcSWyGhZKxrQHg0gfI=;
        b=JXSsUpUGkjjHcmmDyZJ/sbGBuVRo62h6aJcyWNnBcKuVI/OoIOGh90M/igMOpVwYg/
         3iF2XMAhf37SVJdWv/y5R8HQeZuLFM8icIJ...(snip)...M4F5dImibnw==
Date: Tue, 19 Aug 2025 11:05:39 +0900
To: Bob <bob@sample.net>
From: Alice <alice@example.com>
Subject: Test message

・主なメールヘッダ解説

項目	例	解説
Return-Path:	＜bad@fake.dom＞	MAIL FROMコマンドで送られたEnvelope-FROMの値がここに転記される。
Reply-To:	＜mailing-list@fake.dom＞	送信者が、異なるメールアドレスに返信させたいときに使う。たとえば、メーリングリスト宛にメールを送っていて、受信した人が「返信」ボタンを押すと、送信者ではなくメーリングリストを宛先にしたい場合など。この場合の設定は、メーリングリスト側でReply-Toを設定可能
Authentication-Results:	mta7022.mail.djm.ynwp.yahoo.co.jp from=orange.plala.or.jp; domainkeys=neutral (no sig); dkim=pass (ok); header.i=@plala.or.jp; dmarc=pass (p=NONE,sp=NONE,pct=100, domain=plala.or.jp); header.from=red.plala.or.jp	送信ドメイン認証の結果
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=plala.or.jp; q=dns/txt; s=p20240201; t=1717042923; x=1748578923;（中略） bh=sjDXyHL6vgVVG4LC759NA=; b=Iz9cpav56POlN0（省略）=;	DKIM署名
Received:	from [192.168.1.110] (really [153.239.234.128]) by msc11.plala.or.jp with ESMTP	経由したメールサーバ
ARC-Authentication-Results:	i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=example.jp; dmarc=pass action=none header.from=example.jp; dkim=pass header.d=example.jp; arc=none	ARC（Authenticated Received Chain）は、メールの転送経由の認証結果を保持したもの。Receivedヘッダは改ざんされる可能性があるが、ARC-Message-Signature（AMS）という署名をつけて、改ざんされていないかの検証ができる。
Date:	Thu, 30 May 2024 22:21:59 +0900	送信日時
To:	user1@example.co.jp	宛先メールアドレス
From:	=?UTF-8?B?5234d7KV5?= ＜bad@fake.dom＞	送信元の　表示名＜送信元メールアドレス=Header from＞

・R6SC秋午後問2では、Reply-Toには、メーリングリストのメールアドレスを設定すると記載がある。→つまり、返信する場合は、送信者ではなく、メーリングリストのアドレスになる
・R6SC秋午後問2では、ARCには対応していない、とある。対応していると、送信ドメイン認証の成功率が上がるのですが、そうすると設問で問いづらくなるからです。

10.2 メールのセキュリティ

(1)メールセキュリティの全体像

Q.メールに関する脅威と、それに対する対策を整理。
A.まとめはこちら

(2)OP25B

くわしくはこちら

(3)オープンリレーの防止

くわしくはこちら

(4)メールの送信ドメイン認証

・送信ドメイン認証認証とは？
・実現する技術などは送信ドメイン認証
・復習を兼ねて、R6秋PM2の表3を見ましょう。

Q1.項番1ですが、エンベロープFROMとヘッダーFROMの情報は、どこを見ればわかりますか？
Q2.項番2のアクションにはどんな内容がありますか？
Q3.↑のアクションは、どのタグで指定されますか？
Q4.項番3のDMARCレコードは、どこに（送信者か受信者も含めて）、何のレコードとして記載されますか？
Q5.項番4のDKIM署名は、どのサーバが、どの鍵で署名しますか？
Q6.項番5のDMARCレポートですが、どこに記載されたメールアドレスに送付されますか？

正解は、支援士R6のp211に記載。
・DMARCに関しては、確認問題を実施

11.脆弱性管理

・R7春の特徴として、「脆弱性管理」の話が多かった。

問1　SBOMを利用した脆弱性管理が出題
問2　タイトルが「脆弱性管理」とあり、脆弱性管理がメインの出題だが、脆弱性診断含む。CVE、CVSSにも言及有
問3　脆弱性はでてくるが、あくまでも脆弱性への対策なので、よくある話。
問4　タイトルに「脆弱性管理」とあり、CVE、CVSSにも言及有

・セキュリティ技術およびその導入だけでなく、セキュリティの運用も重要というメッセージであろう。
・脆弱性管理の内容については以下に記載。
https://sc.seeeko.com/entry/vuln
・ASMに関してはこちら

12. DDoS攻撃と対策

12.1 DDoS攻撃とは

・DoS（Denial of Services）攻撃は、Services（サービス）のDenial（拒否）という意味で、サーバなどを攻撃してサービスを提供できないようにすることです。
・DDoS攻撃のDはDistributed（分布させた）という意味です。よって、言葉のとおり、複数に分布された攻撃マシンから一斉にDoS攻撃を行います。
・原始的なDoS攻撃の方法として、キーボードのF5キーを連打するF5アタックがあります。F5キーは、Webページをリロードします。このF5キー連打を大人数でやれば、立派なDoS攻撃になります。実際、F5アタックによる大規模なDDoS攻撃も行われました。
・DDoS攻撃の方法ですが、多くの場合は、攻撃者のコントロール配下にあるボットネットを使います。攻撃者がC＆Cサーバを通じて攻撃命令を出すと、ボット端末が攻撃対象のサーバに対して、一斉にDDoS攻撃を仕掛けます。

12.2 DDoS攻撃の種類

・具体的な攻撃名称

攻撃名	対象	概要
UDPフラッド	サーバーやネットワーク機器	公開Webサーバ，DNSサーバを攻撃対象に，偽の送信元IPアドレスとランダムな宛先UDPデータグラムを大量に送りつける。（情報処理安全確保支援士試験R6春問2より）
SYNフラッド	サーバーの接続リソース	TCP接続のSYNリクエストを大量に送信し、接続リソースを枯渇させる攻撃。
ICMPフラッド	ネットワーク機器やサーバー	ICMPエコーリクエスト（ping）を大量に送信し、帯域や処理能力を圧迫する攻撃。
DNSリフレクション	サーバー	偽DNSアンプやDNSリフレクタ攻撃と呼ぶこともあります。送信元IPアドレスを偽装した問合せをDNSサーバに送り，DNSサーバからの応答を攻撃対象のサーバに送信させる手法です。名前のとおり，踏み台DNSサーバを反射板（リフレクタ）のように使って，攻撃対象のサーバに宛ててパケットを反射させます。
HTTP GETフラッド	Webサーバー	大量のHTTP GETリクエストを送信し、Webサーバーのリソース（CPUやメモリ）を消耗させる攻撃
Slow系のDoS攻撃	Webサーバ	たとえば、Slowlorisと呼ばれるツールを使い、HTTPリクエストを小規模に送り続け、Webサーバのリソースを枯渇させる。パケットの量はそれほど多くないので、DDoS攻撃として検知されにくいことがある。ただ、Webサーバの種類や対策状況によっては、うまく攻撃が成り立たないこともある
DNS水責め攻撃	DNSサーバー	ランダムサブドメイン攻撃とも言われる。 https://jprs.jp/glossary/index.php?ID=0137 DNSの問い合わせで、ランダムなサブドメインを付加します。ランダムなので、キャッシュが効きません。よって、毎回、キャッシュDNSサーバおよびコンテンツDNSサーバに問合せるので、大量に問合せれば、サーバのリソースが無くなります。ランダムサブドメイン攻撃は、攻撃と通常の問い合わせの判断が難しく、対策がやや困難です。

・DNSリフレクション攻撃の概要については、支援士R6のp67～

・DNSリフレクションに関して、何点か質問

Q1.応答パケットのサイズが大きいレコードなんて、存在するのか？

↓
↓
↓
↓
解答例：ある。ドメインに関連するすべてのレコードを要求したり、SPF情報などのTXTレコード、または、DNSキャッシュポイズニングなどで大きなレコードを埋め込むこともある。

Q2.こんなことをしなくても、最初からドメインに関連するすべてのレコードを要求と同じサイズのパケットを送り付ければいいのでは？なぜそうしなのか

↓
↓
↓
↓
解答例：増幅効果：自分が送ったリクエストの数十〜数百倍の増幅が狙えるから効率的な攻撃ができる
送信元IPアドレスの詐称ができる。

Q3.DNSリフレクション攻撃の踏み台にされないようにするにはどうしたらいいか

↓
↓
↓
↓
解答例：DNSサーバを，権威DNSサーバとフルサービスリゾルバの機能に分離します。そして，インターネットからは，フルサービスリゾルバの機能が利用できないようにします。つまり，DNS-KはH社ドメインに対するDNS要求パケットだけに応答します。

・Q.過去問（H29春SC午前Ⅱ）を解け。また、アとイは名称も答えよ

問6　DNS水責め攻撃（ランダムサブドメイン攻撃）の手口と目的に関する記述のうち、適切なものはどれか。
ア　ISPが管理するDNSキャッシュサーバに対して、送信元を攻撃対象のサーバのIPアドレスに詐称してランダムかつ大量に生成したサブドメイン名の問合せを送り、その応答が攻撃対象のサーバに送信されるようにする。
イ　オープンリゾルバとなっているDNSキャッシュサーバに対して、攻撃対象のドメインのサブドメイン名をランダムかつ大量に生成して問い合わせ、攻撃対象の権威DNSサーバを過負荷にさせる。
ウ　攻撃対象のDNSサーバに対して、攻撃者が管理するドメインのサブドメイン名をランダムかつ大量に生成してキャッシュさせ、正規のDNSリソースレコードを強制的に上書きする。
エ　攻撃対象のWebサイトに対して、当該ドメインのサブドメイン名をランダムかつ大量に生成してアクセスし、非公開のWebページの参照を試みる。

↓
↓
↓
↓
解答例：ア：DNS AMP攻撃
イ：正解選択肢：DNS水責め攻撃（ランダムサブドメイン攻撃）です。

Q2.過去問（R6SC春PM問2）

↓
↓
↓
↓
解答例：公開Webサーバ，取引先向けWebサーバを攻撃対象に，HTTP GETリクエストを繰返し送る。

12.3 DDoSの対策について

(1）概要

Q.DDoS攻撃への対策には、何があると思いますか？

↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
DDoS攻撃への対策は、以下があると思います。
（⓪）サーバやネットワーク機器、回線帯域のスペックを増強する。→さらに大きなDDoS攻撃が来る可能性があります。
❶インターネット回線に接続しているUTMやルータの前段に、DDoS対策のアプライアンス製品を設置する
❸ISPが提供するDDoS防御サービス
❺DDoS対策を有するCDNサービスを利用する
❻クラウド型ファイアウォールサービス　→
クラウドWAF等のサービスとして提供されている場合もあります。
（❼）同時接続数などのパラメータを調整する。
（➒）何もしない（リスク受容）→攻撃者もコストと稼働がかかるので、ずっと攻撃することは不可能です。

(2)CDNサービス

・CDN（Contents Delivery Network：コンテンツ配信ネットワーク）は、その名のとおりコンテンツを配信するための仕組みです。代表的な提供事業者としてアカマイがあります。世界中にニュースや動画を配信するWebサイトを考えてください。世界中から通信がきた場合，特にサーバのネットワークトラフィックは莫大になると思いませんか？そこで，世界中にコンテンツのコピーを置くのです。そうすれば，負荷が分散されます。

・この仕組みがDDoS対策になります。上記に置いて、アメリカのエッジサーバにDDoS攻撃が来たとします。CDNのサービスがDDoS対策の機能を持っていれば、攻撃の入り口で防御することができます。こうすれば、オリジンサーバもそうですし、他のエッジサーバは無傷でサービスを提供できます。
・AWSの場合、CloudFrontというCDNサービスではある。CDNサービスでは、先のAmazon Shieldが有効になっているはずで、DDoS対策になる。
たとえば、IPA（情報処理推進機構）のDNS情報（www.ipa.go.jp）を問合せると、以下のようにCloudfrontのFQDN（d2aiu9f88m0xez.cloudfront.net）が返ってくる。

Q.過去問（R4春SC午後Ⅱ問2）を解きましょう。

空欄a、bに入る適切な字句を答えよ

↓
↓
↓
↓
↓
A.解答例：a:キャッシュ
b:DDoS

Q.過去問（R6春SC午後Ⅱ問2）を解きましょう。

↓
↓
↓
↓
↓
A.解答例：・DDoS対策機能を有するCDNサービス
・クラウド型ファイアウォールサービス
ISPが提供するDDoS防御サービス

13.TLSのシーケンス

・概要
https://sc.seeeko.com/entry/ssl#3SSLTLS
・❹TLSはOSI参照モデルの第何層か
・SSL/TLSを利用する目的を3つ答えよ
・(7)SSL/TLS通信とデジタル証明書　※CertificateVerifyの理解
・(8)SSL/TLS通信の流れ、通信シーケンス
・プロキシによる復号（CONNECTメソッドを使う）場合の流れは、こちらで確認しましょう。
・では、R7春SC午後問3を答えましょう。https://www.ipa.go.jp/shiken/mondai-kaiotu/nl10bi0000009lh8-att/2025r07h_sc_pm_qs.pdf

↓
↓
↓
↓
解答例：
前段にTCPの3ウェイハンドシェイク（→SYN、←SYN＋ACK、→ACK）
a:オ：CONNECT www.a-sha.co.jp:443 HTTP/1.1（★正解したい）
b:ケ：200 OK　（★正解したい）
c:ウ：Client Hello　（★正解したい）
d:コ：Server Hello　（★正解したい）
e:ア：Certificate　（★正解したい）
f:イ：Certificate Verify
g:カ：Finished
h:キ：GET /campaign/　　HTTP/1.1

13.2 暗号化スイート

(1)TLSのネゴシエーションにおける暗号化スイート

https://sc.seeeko.com/entry/ssl#8SSLTLS%E9%80%9A%E4%BF%A1%E3%81%AE%E6%B5%81%E3%82%8C%E9%80%9A%E4%BF%A1%E3%82%B7%E3%83%BC%E3%82%B1%E3%83%B3%E3%82%B9

(2)TLS1.3の変化

・AEAD(Authenticated Encryption with Associated Data：認証付きの暗号）が導入された
・認証と鍵交換の情報が不要になり、TLS_AES_256_GCM_SHA384のように、暗号（主にAES）とハッシュ関数だけを指定するようになりました。

(3)鍵交換におけるDHとDHE、ECDHE

・こちらに記載

14.ネットワークセキュリティ

14.1 DNSセキュリティ

・DNSはネットワークスペシャリスト試験の範囲とも考えられますが、テーマはDNSで、内容は支援士（セキュリティ）の出題が過去にありました。
たとえば、R3春SC午後Ⅰ問2です。内容は、DNSの基本的なリソースレコードから問われています。
・DNSセキュリティに関してはこちら
・サブドメインテイクオーバーは、言葉とその仕組みを理解しておきましょう。詳しくはこちら。

15.Linuxのコマンド等

時間の関係で、解説はしませんが、さらっと見ておいてもらうといいと思います。
https://sc.seeeko.com/entry/log_management#4Linux%E3%82%B5%E3%83%BC%E3%83%90

16.説明し忘れ

・JWTによるセッション管理