Slide 1
Slide 1 text
Bengo4.com, Inc.
弁護士ドットコム 新卒研修2025
Webアプリケーション
セキュリティ
2025.04.08
弁護士ドットコム 開発本部 技術戦略室 太田 良典
Slide 2
Slide 2 text
前置き
2
Slide 3
Slide 3 text
Bengo4.com, Inc.
これは何?
新卒エンジニア向けの
Webアプリケーションセキュリティの研修です
(そうでない人の受講を禁止するものではありません)
2時間の講座です
エンジニアとして現場に配属された際にスムーズに実践できるようWebア
プリケーションセキュリティの基礎的な知識・スキルを
習得することが目的です
3
Slide 4
Slide 4 text
Bengo4.com, Inc.
諸注意
まとまった質疑応答の時間は予定していません
疑問・質問などがあるときは、その場で挙手してください
話の途中で遮っていただいても構いません
4
Slide 5
Slide 5 text
参考書
5
Slide 6
Slide 6 text
Bengo4.com, Inc.
体系的に学ぶ
安全なWebアプリケーションの作り方
第2版
通称「徳丸本」
Webアプリケーションの
セキュリティを学ぶ人の定番
初版は2011年発行
第2版が2018年発行
やや古いが、
内容は現在でも十分に通用する
6
Slide 7
Slide 7 text
Bengo4.com, Inc.
7
徳丸本の謝辞
弁護士ドットコムの
エンジニアも
協力しています!
Slide 8
Slide 8 text
今日のお話
8
Slide 9
Slide 9 text
Bengo4.com, Inc.
今日のお話
9
● 1. セキュリティとは何か
● 2. HTTPとHTTPS
● 3. Cookie
● 4. Same Origin policy
● 5. Webアプリケーションの脆弱性
● 6. おわりに
Slide 10
Slide 10 text
1. セキュリティ とは何か
10
Slide 11
Slide 11 text
Bengo4.com, Inc.
セキュリティ とは
何か説明できますか ?
11
Slide 12
Slide 12 text
情報セキュリティの 3大要素
12
1. セキュリティとは何か
Slide 13
Slide 13 text
Bengo4.com, Inc.
情報セキュリティの 3大要素
13
以下の3つを情報セキュリティの3大要素という
● 機密性 (Confidentiality)
● 完全性 (Integrity)
● 可用性 (Availability)
さらに、真正性 (Authenticity) 、責任追跡性 (Accountability) 、
否認防止 (Non-repudiation) を加えて6大要素とすることもある
Slide 14
Slide 14 text
Bengo4.com, Inc.
機密性 (Confidentiality)
● 機密情報が漏れると問題が生じる
○ 個人情報、顧客情報、パスワード等
● 漏れ方はさまざま
○ データベースからの漏えい
○ 通信経路上での傍受
○ 社内ネットワークへの侵入
○ 内部犯行による外部流出
14
Slide 15
Slide 15 text
Bengo4.com, Inc.
完全性 (Integrity)
● データが改ざんされると問題が生じる
○ データの改ざん、Webページの改ざん
● 改ざんで起きる現象はさまざま、
一見してわからないもの も
○ 政治的主張に書き換え?
○ Webページでウィルスを配布
○ 他人のサーバーでひそかに暗号通貨のマイニング
15
Slide 16
Slide 16 text
Bengo4.com, Inc.
可用性 (Availability)
● サービスが使えなくなる と問題が生じる
○ Webサイトのダウン、サービスの停止
● 使えなくなる理由は様々
○ アクセスの殺到
○ DoS攻撃
○ ランサムウェア
これを考えないと、
「サービスが停まっていれば事故は起きない」 となりかねない
16
Slide 17
Slide 17 text
脅威
17
Slide 18
Slide 18 text
Bengo4.com, Inc.
脅威と脅威分析
18
情報セキュリティを侵害したり、脅かしたりする可能性のある
潜在的な危険 を脅威という
単にリスクと呼ぶこともある
たとえば、情報流出、マルウェア感染、不正アクセス、etc…
起きてしまったら困る、情報セキュリティに関する出来事
リスクを低減したり事前対応するために、
組織やシステムにどのような脅威が存在するか洗い出すことを
「脅威分析」と呼ぶ
Slide 19
Slide 19 text
Bengo4.com, Inc.
IPA 情報セキュリティ 10大脅威
19
IPA (独立行政法人 情報処理推進機構) が
毎年発行している文書
日本国内の世間一般で良くみられた脅威を
集計、専門家の投票で順位づけして
上位10件を公表するもの
よく順位が一人歩きするが、
順位に深い意味はない
Slide 20
Slide 20 text
事故はなぜ起きる ?
20
1. セキュリティとは何か
Slide 21
Slide 21 text
人為的なミス
21
Slide 22
Slide 22 text
Bengo4.com, Inc.
多くは人為的なミスが原因
22
とても多い事故はメール送信時の宛先誤り
そのほか、設定ミスによる情報漏洩も多い
メール添付ファイルを開く 、
悪意あるサイトで指示に従ってしまう など
不用意な行動 が事故につながることもある
Slide 23
Slide 23 text
Bengo4.com, Inc.
メールの宛先誤りについて（2022年4月1日）
https://www.digital.go.jp/press/a9874a8b-c99e-495f-8117-2f342403153b
23
Slide 24
Slide 24 text
Bengo4.com, Inc.
個人情報の流出について | 重要なお知らせ | 近畿大学
https://www.kindai.ac.jp/news-pr/important/2024/12/044707.html
24
Slide 25
Slide 25 text
Bengo4.com, Inc.
IPA 情報セキュリティ10大脅威 2025 組織編10位
25
Slide 26
Slide 26 text
Bengo4.com, Inc.
Phishing campaign impersonates Booking .com, delivers a suite of credential-stealing malware
https://www.microsoft.com/en-us/security/blog/2025/03/13/phishing-campaign-impersonates-bo
oking-com-delivers-a-suite-of-credential-stealing-malware/
26
Slide 27
Slide 27 text
余談:
人為ミスはエンジニアと無関係 ?
27
Slide 28
Slide 28 text
Bengo4.com, Inc.
ミスを誘発するサービスというものもある
人為ミスによる事故の中には、人の問題というよりも
アプリケーションやサービス側の問題 と言えるものもある
● 操作がわかりにくく、ミスを誘発 する
● 設定項目や動作原理がまぎらわしく、予想外の結果 になる
● 安全ではないのに、安全と誤解されるような説明 がされている
これらはどちらかというとユーザビリティの問題に近いが、
セキュリティエンジニアの責任範囲 であると考えている
使いにくさ や、不適切な説明 を無視してはならない
28
Slide 29
Slide 29 text
29
脆弱性
Slide 30
Slide 30 text
Bengo4.com, Inc.
脆弱性とは
30
セキュリティ上の問題 につながるソフトウェアやシステムの欠陥
● 種類や原因はさまざま
○ プログラムのバグ によるもの
○ 仕様・設計上の不具合 (設計ミス)
● 有名なソフトウェアにもしばしば存在する
● Webアプリケーションにもしばしば脆弱性がある
Slide 31
Slide 31 text
Bengo4.com, Inc.
2025 年 3 月のセキュリティ更新プログラム (月例)
https://msrc.microsoft.com/blog/2025/03/202503-security-update/
31
Slide 32
Slide 32 text
Bengo4.com, Inc.
Webアプリケーションの脆弱性
Webアプリケーションのほとんどは情報を取り扱い、
個人データやパスワードといった機密性のあるものが含まれる
その機密性が侵害されると、情報漏洩事故 となる
Webページを書き換えられてしまったり、
ウイルスがダウンロードされるような改ざんがなされることもある
攻撃によってサービスがダウンし、利用できなくなる こともある
32
Slide 33
Slide 33 text
Bengo4.com, Inc.
脆弱性とは、
悪用できるバグである
33
Slide 34
Slide 34 text
Bengo4.com, Inc.
悪用の例
● 個人情報などの秘密情報を勝手に閲覧 する
● Web サイトの内容を書き換える
● サイトを閲覧した利用者の PC をウイルスに感染させる
● 別の利用者になりすまし 、秘密情報の閲覧、買い物、送金など
● コンピュータ資源を勝手に使う (暗号通貨のマイニングなど)
● Web サイトを利用不能にする
● オンラインゲームで無敵になる、アイテムを好きなだけとる
34
Slide 35
Slide 35 text
ここまでのまとめ
35
1. セキュリティとは何か
Slide 36
Slide 36 text
Bengo4.com, Inc.
セキュリティとは何か
● 情報セキュリティの 3大要素
○ 機密性、完全性、可用性
● 脅威と脅威分析
○ 潜在的な危険・リスクを脅威と呼ぶ
○ 組織やシステムの脅威分析をしてリスクに備えることがある
● 事故はなぜ起きるか
○ 人為的なミスが多い
○ システムのバグや欠陥、脆弱性が原因となることも多い
36
Slide 37
Slide 37 text
2. HTTP とHTTPS
37
Slide 38
Slide 38 text
HTTPとは
38
2. HTTPとHTTPS
Slide 39
Slide 39 text
Bengo4.com, Inc.
HTTPとは
HTTP = Hypertext Transfer Protocol
ハイパーテキストを転送するための通信プロトコル
ユーザーエージェントがサーバーに接続し、
「メッセージ（message）」をやりとりする
39
Slide 40
Slide 40 text
HTTPリクエスト
40
Slide 41
Slide 41 text
Bengo4.com, Inc.
HTTPリクエスト
ユーザーエージェントがサーバーに送るメッセージを
HTTPリクエスト（HTTP request）と呼ぶ
リクエストは以下の3つで構成される
● リクエスト行 (request line)
● リクエストヘッダ
● リクエストボディ
41
Slide 42
Slide 42 text
Bengo4.com, Inc.
HTTPリクエストの例
POST /form.php HTTP/1.1
Host: www.example.com
Cookie: dlid=form01-83
User-Agent: curl/7.16.3
name=john&age=12
42
Slide 43
Slide 43 text
Bengo4.com, Inc.
リクエスト行
POST /form.php HTTP/1.1
Host: www.example.com
Cookie: dlid=form01-83
User-Agent: curl/7.16.3
name=john&age=12
43
先頭はリクエスト行と呼び、
以下の情報を含む
● メソッド
● ターゲット
● HTTPバージョン
Slide 44
Slide 44 text
Bengo4.com, Inc.
リクエストメソッド
POST /form.php HTTP/1.1
Host: www.example.com
Cookie: dlid=form01-83
User-Agent: curl/7.16.3
name=john&age=12
44
リクエストの種類をあらわす
もっともよく使われるのは
単にリソースを取得する GET
サーバーにデータを送信する
ときはPOSTを使う
このほか、HEAD や OPTIONS
などのメソッドが利用される
Slide 45
Slide 45 text
Bengo4.com, Inc.
リクエストターゲット
POST /form.php HTTP/1.1
Host: www.example.com
Cookie: dlid=form01-83
User-Agent: curl/7.16.3
name=john&age=12
45
リクエストの対象をあらわす
省略はできない
http://www.bengo4.com
にアクセスすると、ブラウザ側で
http://www.bengo4.com/
に補正され、
リクエストターゲットは / となる
Slide 46
Slide 46 text
Bengo4.com, Inc.
GETとPOST
GETメソッドでもサーバーにデータを送ることは可能
この場合、URLのクエリ文字列として値を指定する
HTTPでは、リクエストターゲットにペイロードが乗ることになる
ただし長い値は切れてしまうかもしれない (実装依存)。
リクエストされたURLはブラウザのアドレスバーや履歴に現れる他、Web
サーバーのログにも残る
大きなデータ や秘匿性の高い情報 を送る場合はPOST
検索など、ブラウザの履歴に残したい 場合はGETを使う
46
Slide 47
Slide 47 text
Bengo4.com, Inc.
リクエストヘッダ
POST /form.php HTTP/1.1
Host: www.example.com
Cookie: dlid=form01-83
User-Agent: curl/7.16.3
name=john&age=12
47
リクエスト行の後に、
CR+LF 1つで区切って
リクエストヘッダが続く
Slide 48
Slide 48 text
Bengo4.com, Inc.
ヘッダフィールド
POST /form.php HTTP/1.1
Host: www.example.com
Cookie: dlid=form01-83
User-Agent: curl/7.16.3
name=john&age=12
48
リクエストヘッダ内の個々の行は
ヘッダフィールドと呼ばれる
フィールド名: フィールド値の形
それぞれのヘッダフィールドは
CR+LF 1つで区切られる
Slide 49
Slide 49 text
Bengo4.com, Inc.
よくあるリクエストヘッダ
● Host
○ 接続先のホスト名とポート番号を指定、HTTP/1.1以降では必須
● Content-Length
○ メッセージボディの長さをオクテット単位で指定
● User-Agent
○ ユーザーエージェント名を指定
● Accept
○ 受入可能なMIMEタイプを指定
● Cookie
○ 過去に受け取った Cookie の値を送信。詳しくは後ほど
49
Slide 50
Slide 50 text
Bengo4.com, Inc.
リクエストボディ
POST /form.php HTTP/1.1
Host: www.example.com
Cookie: dlid=form01-83
User-Agent: curl/7.16.3
name=john&age=12
50
リクエストヘッダの後、
CR+LFを2つ続けて書くと
ヘッダの終了を意味する
その後ろはリクエストボディ
リクエストメッセージ本体となる
メソッドの種類によっては、
ヘッダのみでボディがないことも
GETなどはボディがない
Slide 51
Slide 51 text
HTTPレスポンス
51
Slide 52
Slide 52 text
Bengo4.com, Inc.
HTTPレスポンス
サーバーから返されてくるメッセージを
HTTPレスポンス（HTTP response）と呼ぶ
レスポンスは以下の3つで構成される
● ステータス行
● レスポンスヘッダ
● レスポンスボディ
52
Slide 53
Slide 53 text
Bengo4.com, Inc.
HTTPレスポンスの例
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 7887
Date: Thu, 19 Aug 2021 10:00:02 GMT
Last-Modified: Tue, 17 Aug 2021 14:00:11 GMT
Set-Cookie: dlid=form01-83;Path=/;
expires=Mon, 05-May-2025 08:50:20 GMT;
…
53
Slide 54
Slide 54 text
Bengo4.com, Inc.
ステータス行
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 7887
Date: Thu, 19 Aug 2021 10:00:02 GMT
Last-Modified: Tue, 17 Aug 2021 14:00:11 GMT
Set-Cookie: dlid=form01-83;Path=/;
expires=Mon, 05-May-2025 08:50:20 GMT;
…
54
先頭行は「ステータス行」
以下を含む
● HTTPバージョン
● ステータスコード
● リーズンフレーズ
Slide 55
Slide 55 text
Bengo4.com, Inc.
ステータスコード
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 7887
Date: Thu, 19 Aug 2021 10:00:02 GMT
Last-Modified: Tue, 17 Aug 2021 14:00:11 GMT
Set-Cookie: dlid=form01-83;Path=/;
expires=Mon, 05-May-2025 08:50:20 GMT;
…
55
3桁の整数値
意味はおおよそ以下の通り
100番台: 情報提供
200番台: 成功
300番台: リダイレクト
400番台: クライアント側エラー
500番台: サーバー側エラー
Slide 56
Slide 56 text
Bengo4.com, Inc.
リーズンフレーズ
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 7887
Date: Thu, 19 Aug 2021 10:00:02 GMT
Last-Modified: Tue, 17 Aug 2021 14:00:11 GMT
Set-Cookie: dlid=form01-83;Path=/;
expires=Mon, 05-May-2025 08:50:20 GMT;
…
56
何らかのテキスト
仕様的には特に意味はない
レスポンスを人間が見た時に
わかりやすくするためのもの
(今のHTTPを人間が直接見る
ことがあるだろうか……?)
仕様的には特に意味はない
ユーザーエージェントは
これを無視するべき
Slide 57
Slide 57 text
Bengo4.com, Inc.
レスポンスヘッダ
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 7887
Date: Thu, 19 Aug 2021 10:00:02 GMT
Last-Modified: Tue, 17 Aug 2021 14:00:11 GMT
Set-Cookie: dlid=form01-83;Path=/;
expires=Mon, 05-May-2025 08:50:20 GMT;
…
57
ステータス行の後に、
CR+LF 1つで区切って
レスポンスヘッダが続く
Slide 58
Slide 58 text
Bengo4.com, Inc.
よくあるレスポンスヘッダ
● Date
○ レスポンスを生成した日時を示す
● Last-Modified
○ リソースの最終更新日時を示す
● Content-Length
○ メッセージボディの長さをオクテット単位で指定
● Content-Type
○ リソースの種類を示すMIMEタイプを指定
● Set-Cookie
○ Cookie の値を送る。詳しくは後ほど
58
Slide 59
Slide 59 text
HTTPを見る
59
Slide 60
Slide 60 text
Bengo4.com, Inc.
HTTPを見る
60
HTTPの通信内容は、昔は telnet で簡単に見ることができた
現在はHTTPSが普及したため面倒なことになっており、
初学者の学習の妨げになっているのが誠に遺憾である
プロキシや専用のツールを使えば見ることができる
そのほか、ブラウザの開発者ツールでもある程度見られる
ただし生ではなく、ある程度正規化された表示になる
Slide 61
Slide 61 text
Bengo4.com, Inc.
ツールの例 (OWASP ZAP)
61
Slide 62
Slide 62 text
Bengo4.com, Inc.
ブラウザの開発者ツールでもある程度確認可能
62
Slide 63
Slide 63 text
HTTPはステートレス
63
Slide 64
Slide 64 text
Bengo4.com, Inc.
HTTPはステートレス
64
HTTPのやり取りは基本的にその場限りで、状態を保持しない
(昔は本当に1回のリクエスト・レスポンスで接続が切れていた)
今はTCP接続は使いまわされることが多いが、
それでも複数のリクエスト間で状態が保持されることはない
同じ接続で2回リクエストを送っても、前後の文脈は考慮されない
「このユーザーはさっきページAを見ていて、その後ここに来た」
のような情報はサーバー側にはわからない
Slide 65
Slide 65 text
Bengo4.com, Inc.
基本認証
65
基本認証という
仕組みもある
これは毎回
パスワードを
送っている
Slide 66
Slide 66 text
HTTPS
66
2. HTTPとHTTPS
Slide 67
Slide 67 text
Bengo4.com, Inc.
インターネット通信のリスク
インターネットは、複数のネットワークを接続したもの
インターネット上の通信は、不特定の経路を経由することがある
第三者が管理するネットワークを経由することもあるし、
その管理者には悪意があるかもしれない
あるいは、悪意を持った偽のWi-Fiアクセスポイントを
経由しているかもしれない
第三者による通信の傍受・改ざんのリスクが常にある
67
Slide 68
Slide 68 text
Bengo4.com, Inc.
TLS
TLS = Transport Layer Security
トランスポート層で通信を暗号化するプロトコル
昔使われていたSSLというプロトコルの後継
現在SSLは使われていない が、あわせてSSL/TLSと呼ぶこともある
TLSの上にアプリケーション層のプロトコルを載せることができる
もっともよく使われるのはHTTPで、HTTP over TLS と呼ばれる
このほか、SMTP over TLS、FTP over TLSなどいろいろある
68
Slide 69
Slide 69 text
Bengo4.com, Inc.
TLSの機能
TLSは以下のような機能を提供する
● 通信内容の暗号化
● 通信内容の改ざん防止
● 通信相手の認証 (なりすまし 防止)
単に「暗号化」と説明されることが多いが、
暗号化は機能の一部に過ぎない
むしろ通信相手を認証することが重要
69
Slide 70
Slide 70 text
Bengo4.com, Inc.
70
保護されていない通信
Slide 71
Slide 71 text
Bengo4.com, Inc.
保護されている通信
71
Slide 72
Slide 72 text
サーバー証明書
72
Slide 73
Slide 73 text
Bengo4.com, Inc.
サーバー証明書
73
SSL/TLS証明書と呼ばれることも
TLSの通信相手のサーバーが真正なものであることを証明
サーバー内に秘密鍵を持っておき、鍵に対応する証明書を公開 する
証明書には対象となるサイトのドメインの情報 が書かれており、
別のドメインに使いまわすことはできない
証明書には認証局の署名 がついていて、偽造困難
その認証局の署名にもさらに別の認証局の署名がついている
最終的にルート証明書まで遡る (Trust Chain)
Slide 74
Slide 74 text
Bengo4.com, Inc.
サーバー証明書の例
74
Slide 75
Slide 75 text
Bengo4.com, Inc.
開発者ツールで確認することも
75
Slide 76
Slide 76 text
TLSの注意点
76
Slide 77
Slide 77 text
Bengo4.com, Inc.
TLS = 安全、ではない
77
悪い人も自身のドメインでサーバー証明書を取得可能
TLSが使われていることは、サイトが安全であることを意味しない
あくまで、そのドメインのオーナーのサイトであるという意味
昔はEV証明書というものが使われていた時期があり、
悪い人はこれを簡単には使えないとされていたが、
実はあまり意味がないとわかって、廃れてしまった
(今でも取得することは可能)
Slide 78
Slide 78 text
Bengo4.com, Inc.
https://www.cybertrust.co.jp/pressrelease/cybertrust-old/130624.html
78
Slide 79
Slide 79 text
ここまでのまとめ
79
2. HTTPとHTTPS
Slide 80
Slide 80 text
Bengo4.com, Inc.
HTTPとHTTPS
● HTTP = Hypertext Transfer Protocol
○ リクエストとレスポンスがあり、それぞれにヘッダがある
○ HTTPの内容は開発者ツールでもある程度は見られる
○ 状態を持たない、ステートレスなプロトコルである
● HTTPS
○ インターネット通信にはリスクがある
○ TLSで通信を暗号化する
○ サーバー証明書でなりすましの防止をする
○ TLSだからといって安全というわけではない
80
Slide 81
Slide 81 text
3. Cookie
81
Slide 82
Slide 82 text
Cookie とは
82
3. Cookie
Slide 83
Slide 83 text
Bengo4.com, Inc.
83
RFC 6265 HTTP State Management Mechanism
https://www.rfc-editor.org/rfc/rfc6265.html
Slide 84
Slide 84 text
Bengo4.com, Inc.
RFC 6265 の概要
84
ブラウザからアクセスがあった時、サーバー側は
HTTPレスポンスヘッダに Set-Cookie: フィールド を出力して
name / value のペアを渡す
ブラウザはその name / value を記憶しておく
以後、同じサイトにアクセスする時に
HTTPリクエストヘッダに Cookie: フィールド を出力して
name / value のペアを渡す
ブラウザが自動で送る ので、ユーザーが意識することはない
Slide 85
Slide 85 text
Bengo4.com, Inc.
さきほどの例
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 7887
Date: Thu, 19 Aug 2021 10:00:02 GMT
Last-Modified: Tue, 17 Aug 2021
14:00:11 GMT
Set-Cookie: dlid=form01-83;Path=/;
expires=Mon, 05-May-2025 08:50:20
GMT;
85
POST /form.php HTTP/1.1
Host: www.example.com
Cookie: dlid=form01-83
User-Agent: curl/7.16.3
name=john&age=12
Slide 86
Slide 86 text
Bengo4.com, Inc.
Cookieによるセッション管理
ユーザーがログインした際、サーバー側でセッション IDを発行
ユーザーIDとセットにして内部で記憶 しておき、
同時に、Set-Cookie でその値を渡す
ブラウザはその値を受け取り、以後は Cookie でその値を渡す
サーバー側は Cookie の値を受け取り、内部の記憶と照合して
過去に発行したセッション IDに同一のものがあるか判定 する
同一のものがあれば、そのセッションIDとセットのユーザーIDから
セッション情報を復元、そのユーザーのセッションとみなす
86
Slide 87
Slide 87 text
Cookie による
ログインセッションの実装
87
3. Cookie
Slide 88
Slide 88 text
Bengo4.com, Inc.
HTTPの仕組み自体はシンプル
クライアントからサーバーに対してリクエストを送る
サーバーからレスポンスが返る
88
Slide 89
Slide 89 text
Bengo4.com, Inc.
ログイン画面の表示
ユーザーがログイン画面のURLにアクセスすると、
サーバーからログイン画面のHTMLが返る
89
Slide 90
Slide 90 text
Bengo4.com, Inc.
パスワードの送信
ユーザーはログイン画面にIDとパスワードを入力し、POSTする
サーバーにパスワードが送信される
90
俺や!
マイページ見せて!
パスワード送るよ!
Slide 91
Slide 91 text
Bengo4.com, Inc.
認証の成功
認証に成功したら、ログイン後画面を表示する
同時に、サーバーからセッションIDのCookieを送る
91
Set-Cookie:
9466ir8fgmmk1gnr6raeo7ne71
パスワードあってるの
で見てよし!
あと、次から
この番号送ってくれ
Slide 92
Slide 92 text
Bengo4.com, Inc.
以降はセッションを継続
次回以降のアクセスではサーバーにCookieを送る
92
Cookie:
9466ir8fgmmk1gnr6raeo7ne71
パスワードは
送られてきてないけど
番号はさっきのやつやな !
マイページ見てよし!
俺やで!
さっきの番号送るで!
Slide 93
Slide 93 text
重要なポイント 1:
「サイト」ごとに管理される
93
Slide 94
Slide 94 text
Bengo4.com, Inc.
Cookieは「サイト」ごとに管理される
94
あるサイトで発行されたCookieは、
原則としてその「サイト」 でしか送られない
「サイト」はドメインと思ってもらって良い
(厳密な議論を必要とする時は「eTLD+1」などと呼ぶ)
Cookieのサイトの概念ではスキームは考慮されない
http://www.bengo4.com/ と https://www.bengo4.com/ は
同一サイトとみなされ、前者で発行したCookieは後者にも送られる
Slide 95
Slide 95 text
Bengo4.com, Inc.
別サイトのリソースを参照すると ?
サイトAからサイトBにページ遷移したときは、
サイトBが表示され、サイトBで発行されたCookieが送られる
サイトAに、サイト Bの画像を埋め込んで表示 したらどうなるか?
サイトAへのリクエストではサイトAのCookieが、
サイトBへのリクエストではサイトBのCookieが送られる
このようなとき、サイトBのCookieを
「サードパーティ Cookie」と呼ぶ
画像に限らず、JavaScriptからのリクエストなども同様
95
Slide 96
Slide 96 text
Bengo4.com, Inc.
サードパーティ Cookieとプライバシー
今アクセスしているサイトにCookieが送られ、
行動が追跡されることはユーザーにもわかりやすい
サードパーティCookieは、
今アクセスしているサイトとは異なるサイトに送られ、
行動が追跡されることはユーザーにはわからない
そのため、サードパーティCookieにはプライバシーの問題がある
各国で規制が行われたり、ブラウザ側でもいろいろな動きがある
96
Slide 97
Slide 97 text
Bengo4.com, Inc.
外部送信規律について
https://www.soumu.go.jp/main_content/000862755.pdf
97
Slide 98
Slide 98 text
Bengo4.com, Inc.
別サイトへ POSTすると?
サイトAのフォームから、
サイトBに対してデータをPOSTすることもできる
この場合も同様で、
サイトBへのPOSTリクエスト時には
サイトBで発行されたCookieが送られる
この性質はCSRFという脆弱性に関連する (後述)
CookieのSameSite属性の値によって送信がブロックされることも
98
Slide 99
Slide 99 text
重要なポイント 2:
ユーザーは Cookieを読み書き可能
99
Slide 100
Slide 100 text
Bengo4.com, Inc.
ユーザー自身は読み取り・書き換え可能
ユーザーは自身のブラウザのCookieを自由に読み書きできる
ブラウザの開発者ツールを使えばCookieを表示したり、
自由に書き換えたりすることが可能
その他、コンソールからJavaScriptで読み書きしたり、
プロキシツールを利用して、
HTTPヘッダのCookie:フィールドを書き換える方法もある
100
Slide 101
Slide 101 text
Bengo4.com, Inc.
101
開発者ツールの Applicationタブから
Slide 102
Slide 102 text
Cookieによるセッション管理の
セキュリティ要件
102
Slide 103
Slide 103 text
Bengo4.com, Inc.
Cookieによるセッション管理の要件
Cookieによるセッション管理をする場合は、
以下の条件を全て満たさなければならない
● セッションIDが第三者に漏洩しない
● セッションIDを第三者に推測されない
● セッションIDを第三者から強制されない
満たせていない場合、セキュリティ上の問題が生じる
103
Slide 104
Slide 104 text
Bengo4.com, Inc.
セッション IDの漏洩
ユーザーは自身のブラウザに任意のCookieを設定できる
あるユーザーのセッションIDが第三者に漏洩した場合、
第三者がその値を自身のブラウザにセットすることで
そのユーザーのセッションを乗っ取る ことができる
ログイン済みの状態でアクセスし、あらゆる操作が可能
このような脅威をセッションハイジャック と呼ぶ
セッションIDは漏洩しないように保護しなければならない
104
Slide 105
Slide 105 text
Bengo4.com, Inc.
セッション IDが漏れると ……
105
番号送るで!
Cookie:
9466ir8fgmmk1gnr6raeo7ne71
パスワードは
送られてきてないけど
番号はさっきのやつやな !
マイページ見てよし
Slide 106
Slide 106 text
Bengo4.com, Inc.
セッション IDの推測
セッションIDの生成規則が単純だと推測できてしまう
たとえば、2回のアクセスで以下のCookieが発行されたとする
Set-Cookie: dlid=form01-83;
Set-Cookie: dlid=form01-84;
過去どんなIDが生成されたか、次どんなIDが生成されるか一目瞭然
一見ランダムなようで実は推測できてしまうというケースもある
基本的に、セッションIDの生成処理を自前で書くべきではない
106
Slide 107
Slide 107 text
Bengo4.com, Inc.
セッション IDの強制
ここまでは正規ユーザーのセッションIDを第三者が盗む話だった
実はまれに逆のパターンが成立することもある
攻撃者がサービスにログインして自身のセッションIDを取得し、
これを何らかの方法で第三者のブラウザにセットする
その第三者が自身のパスワードでサービスにログインすると、
そのセッションIDが第三者のセッションとなることがある
このような攻撃を session fixation (セッション固定攻撃 ) と呼ぶ
107
Slide 108
Slide 108 text
Cookie の属性
108
3. Cookie
Slide 109
Slide 109 text
Bengo4.com, Inc.
RFCで定義されている Cookieの属性
Cookieには属性 (attribute) と呼ばれるオプションを指定可能
RFC 6265 では以下の 6 つが定義されている
● Expires
● Max-Age
● Domain
● Path
● Secure
● HttpOnly
109
Slide 110
Slide 110 text
Bengo4.com, Inc.
Expires
Cookie 値の期限が切れる日時を指定する
RFC 1123形式で時刻を指定
例: Set-Cookie: a=b; Expires=Mon, 05-May-2025 08:50:20 GMT;
● 過去日が指定されているとブラウザは即座に Cookie を削除
Cookieを削除させたい時にあえて使うことがある
110
Slide 111
Slide 111 text
Bengo4.com, Inc.
Max-Age
Cookie 値の有効期限を秒数で指定する
Expiresと似ているが、現在時刻からの相対的な長さとなる
例: Set-Cookie: a=b; max-age=86400;
● 0 が指定されているとブラウザは即座に Cookie を削除
● ExpiresとMax-Ageの両方があるときはMax-Ageが優先
● どちらの指定もない場合、ブラウザセッションの終了まで有効
○ 昔のRFCではこれを “session cookie” と呼んでいたが
「セッション管理用のCookie」と紛らわしいので注意
111
Slide 112
Slide 112 text
Bengo4.com, Inc.
Domain
Cookieが送信される対象ドメインを指定
例: Set-Cookie: a=b; Domain=bengo4.com;
デフォルトでは、たとえば
www.bengo4.comのCookieはbbs.bengo4.comには送られない
が、上記の設定をするとサブドメイン全てに送られるようになる
かなり危険な設定 なので、よほどのことがない限り使用しないこと
これがあるだけで、サブドメインを増やすことがリスクになる
112
Slide 113
Slide 113 text
Bengo4.com, Inc.
Path
Cookieが送信される対象パスを指定
例: Set-Cookie: a=b; Path=/corporate/;
デフォルトでは同一ドメイン上のどこでもCookieは読める
この属性があると、指定したパスの外ではCookieが送られない
一見、指定した方が安全そう だが、実はセキュリティ上は無意味
この指定がなくても問題がないようにしておく必要がある
安全であるかのような誤解を招くので、使用しないこと
113
Slide 114
Slide 114 text
Bengo4.com, Inc.
Secure
この属性があると、HTTPSの場合のみCookieが送られる
TLSが使われていない、平文のHTTPではCookieが送られない
例: Set-Cookie: a=b; Secure;
常時HTTPSが常識になった現在では常に指定するべき
この属性がついていないと、脆弱性として指摘される
なお、平文のHTTPでもSet-Cookieでセットすることはでき、
セットされたCookieはHTTPSでも送られる
114
Slide 115
Slide 115 text
Bengo4.com, Inc.
HttpOnly
Cookieにこの属性があると、JavaScriptから読み取れない
例: Set-Cookie: a=b; HttpOnly;
Webサーバーには送られるので、サーバー側ではCookieを読める
XSS脆弱性に対する保険的な対策として利用される
セッションIDはJavaScriptから読む必要があるケースが少なく、
保護の必要性も大きいので、原則としてつけておく こと
115
Slide 116
Slide 116 text
最近のCookie
116
3. Cookie
Slide 117
Slide 117 text
Bengo4.com, Inc.
117
Cookies: HTTP State Management Mechanism
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis
Slide 118
Slide 118 text
Bengo4.com, Inc.
Cookieに追加されたセキュリティ機能
118
Cookieは攻撃の的になりやすく、
歴史的経緯もあってセキュリティ的にいろいろと問題があった
近年、問題点を補う追加機能が出てきている
2016年ごろ登場、2020年ごろにはモダンブラウザ全てが対応
● SameSite属性
○ 「クロスサイト」アクセス時のCookie送信の挙動を抑制
● Cookie Prefix
○ 特定の名前をつけたCookieの挙動を抑制
Slide 119
Slide 119 text
Bengo4.com, Inc.
SameSite属性
「クロスサイト」アクセス時のCookie送信の挙動を制御
例: Set-Cookie: a=b; SameSite=strict;
● none: 送る
● strict: 送らない
● Lax: トップレベルナビゲーション (ページ遷移) の時だけ送る
未指定時は、Lax に近いが微妙にゆるい Lax-allowing-unsafe
というモードで動作することがある
119
Slide 120
Slide 120 text
Bengo4.com, Inc.
Cookie Prefix
Cookieに特別な名前がついている場合、発行を抑制する
● Cookieの名前の先頭に __Secure- とつけると
○ CookieにSecure属性がついていない場合、拒否される
○ 平文HTTPで発行された場合、拒否される
● Cookieの名前の先頭に __Host- とつけると、上記に加えて
○ CookieにDomain属性がついている場合、拒否される
○ CookieにPath属性がついている場合、拒否される
開発者の設定ミスや、攻撃者によるCookieの発行を防ぐ
120
Slide 121
Slide 121 text
ここまでのまとめ
121
3. Cookie
Slide 122
Slide 122 text
Bengo4.com, Inc.
Cookie
● ステートレスなHTTPにセッション管理機能を追加するもの
○ RFC 6265に仕様が書かれている
○ Cookieはサイトごとに記憶され、他サイトには送られない
○ ユーザーは自身のCookieを書き換えられる
● セッションIDの漏洩、推測、強制が問題になる
● Cookieにはさまざまな属性がある
● 最近、セキュリティ関連の機能が追加されている
122
Slide 123
Slide 123 text
4. Same Origin policy
123
Slide 124
Slide 124 text
他サイトのコンテンツの
埋め込みと読み取り
124
4. Same Origin policy
Slide 125
Slide 125 text
Bengo4.com, Inc.
他サイトのコンテンツを埋め込む
あるサイト内に、他サイトのコンテンツを埋め込むことがある
YouTubeの動画、Google Slidesなどはよく見られる
iframe要素を配置して
他サイトのコンテンツを
表示している
125
Slide 126
Slide 126 text
Bengo4.com, Inc.
iframeの内側の世界は認証されている
iframeの中身を最後まで視聴すると
おすすめが出るが、
これはYouTubeアカウントごとに
カスタマイズされている
(ログアウトすると内容が変わる)
iframe内のコンテンツを取得する際、
YouTubeにCookieが送信されており、
ログイン後のページが表示されている
126
Slide 127
Slide 127 text
Bengo4.com, Inc.
iframeの内容は外から読むことができる
自サイトのコンテンツをiframeで埋め込んだ場合、
iframeの外側からiframe内のコンテンツにアクセス、読み取り可能
127
Slide 128
Slide 128 text
Bengo4.com, Inc.
ということは ……?
サイトにYouTubeのコンテンツを埋め込んでおき、
JavaScriptからiframeの内容を読みとることによって、
訪問者のYouTubeアカウントを特定できるのではないか?
もっといえば、
任意のサイトの内容をiframeに埋め込むことで、
訪問者のそのサイトにおけるマイページの情報などを
読み出すことができるのではないか?
128
Slide 129
Slide 129 text
Bengo4.com, Inc.
攻撃者は他サイトの秘密情報を読み取れるか ?
129
Slide 130
Slide 130 text
Bengo4.com, Inc.
結果、だめでした
130
Slide 131
Slide 131 text
Bengo4.com, Inc.
結果のまとめ
iframeを利用すると、
他サイトの認証済みコンテンツを表示させることができる
しかし、その内容をJavaScriptで読み取ることはできない
iframe内の認証済みコンテンツは、
ユーザーには見える が、
サイト運営者は読み取ることができない ということ
131
Slide 132
Slide 132 text
Same Origin policy の制約
132
4. Same Origin policy
Slide 133
Slide 133 text
Bengo4.com, Inc.
他サイトの情報が読み取れない理由
iframe内の自サイトのコンテンツは読み取れるのに、
他サイトのコンテンツは読めなかった
これは、Same Origin policy (同一生成元ポリシー、 SOP)
と呼ばれる制約によってブラウザ側の挙動が制限されているため
攻撃者が他サイトの認証後画面の情報を読めないように、
このような制約が設けられている
133
Slide 134
Slide 134 text
オリジン
134
Slide 135
Slide 135 text
Bengo4.com, Inc.
https://html.spec.whatwg.org/multipage/browsers.html
#loading-web-pages-supporting-concepts
135
Slide 136
Slide 136 text
Bengo4.com, Inc.
オリジンの条件
以下の全てを満たす場合、「オリジン」が同一とみなす
● URLのホスト(FQDN; Fully Qualified Domain Name)が一致
● スキームが一致
● ポート番号が一致
Cookieのサイト・ドメインの判定とは異なり、
スキームの一致も求められる
また、パス (ディレクトリ) は考慮されない
136
Slide 137
Slide 137 text
Bengo4.com, Inc.
オリジン比較の例
https://www.bengo4.com/ から見た時、以下は別オリジン
● https://bbs.bengo4.com/
● http://www.bengo4.com/
● https://www.bengo4.com:8080/
以下は同一オリジン
● https://www.bengo4.com/corporate/
● https://www.bengo4.com:443/
137
Slide 138
Slide 138 text
Bengo4.com, Inc.
ドメイン設計時の注意
サイト群のドメインを決める時は、
同一オリジンポリシーを強く意識すること
https://www.bengo4.com/corporate/ に置かれたコンテンツは、
https://www.bengo4.com/ のユーザーログイン後のコンテンツを
自由に読み取ることができる
同一オリジンにコンテンツを置くと、強い権限を与えることになる
138
Slide 139
Slide 139 text
CORS
139
4. Same Origin policy
Slide 140
Slide 140 text
Bengo4.com, Inc.
Cross-Origin Resource Sharing ( CORS )
140
正規の理由で他オリジンのコンテンツにアクセスしたいこともある
そのために Cross-Origin Resource Sharing ( CORS )
という仕組みがある
クロスオリジンでアクセスしようとしたとき、
アクセスを受ける側がHTTPヘッダに
適切な Access-Control-Allow-Origin: を出力していると、
ブラウザ側は読み取りを許す
Slide 141
Slide 141 text
Bengo4.com, Inc.
プリフライトリクエスト
CORSのリクエストがシンプルなもの (HTMLのformから送れるもの) の
場合、ブラウザはいきなりリクエストを出す
レスポンスを見てからブロックする・しないを決定する
リクエストがシンプルでない場合、本番アクセスの前に
OPTIONSリクエストでご機嫌伺いをする
これをプリフライトリクエスト と呼ぶ
ブラウザ拡張でHTTPヘッダをいじっている場合など、
リクエストがシンプルでなくなり動作が変わることがある
141
Slide 142
Slide 142 text
ここまでのまとめ
142
4. Same Origin policy
Slide 143
Slide 143 text
Bengo4.com, Inc.
Same Origin policy
● 同一生成元ポリシー、SOPとも呼ばれる
● オリジンという単位で制御される
○ スキーム、ホスト、ポートの全てが一致すると同一オリジン
○ パスが異なっていても同一オリジン
○ 他オリジンのコンテンツはユーザーには表示されるが、
サイト側では読み取れない
○ 同一オリジン上にコンテンツを置くと、強い権限を与えることに
● CORSという仕組みでこの制限を突破することもできる
143
Slide 144
Slide 144 text
5. Web アプリケーションの
脆弱性
144
Slide 145
Slide 145 text
クロスサイトスクリプティング
145
5. Webアプリケーションの脆弱性
Slide 146
Slide 146 text
Bengo4.com, Inc.
クロスサイトスクリプティングとは
Cross-Site Scripting
XSS と略される (CSSと略すとCSSと紛らわしいため)
脆弱性の王
ほとんどのWebアプリケーションには、
外部からの入力に応じて表示が変化する箇所がある
入力を工夫することで、この部分の構造を破壊して
攻撃者が意図したHTMLを出力させられる場合がある
146
Slide 147
Slide 147 text
Bengo4.com, Inc.
XSSの攻撃
基本的には受動的攻撃 であり、被害者に罠を踏ませる 必要がある
被害者が、攻撃者の用意した罠サイトにアクセスすると、
攻撃者によって攻撃対象のサイトに誘導される
脆弱性により、攻撃対象のサイト上で
攻撃者の用意したHTMLが表示され、JavaScriptが実行される
このJavaScriptは同一オリジン上のコンテンツに対して
任意の操作が可能
147
Slide 148
Slide 148 text
HTML基礎で話したこと
148
Slide 149
Slide 149 text
Bengo4.com, Inc.
属性でリンク先を表現
詳しくはHTML Living Standardをご覧ください。
hrefが「属性名」 https://html.spec.whatwg.org/ が「属性値」 属性名 = 属性値 の形で書き、属性値は引用符で括る 括らなくて良い場合もあるのだが、必ず引用符で括るべき これはセキュリティの観点からも非常に重要 149Slide 150
Slide 150 text
DOM Based XSS
150
5. Webアプリケーションの脆弱性
Slide 151
Slide 151 text
Bengo4.com, Inc.
DOM based XSS とは
XSSの一種。
通常のXSSはサーバー側でHTMLを生成する際の問題だが、
HTMLをJavaScriptで書き換える際に問題が生じることもある
JavaScriptによるDOM操作によって使用じることが多いため、
これを DOM based XSS と呼んでいる
151
Slide 152
Slide 152 text
Bengo4.com, Inc.
JavaScriptフレームワークによる XSS
JavaScriptフレームワークは
セキュリティに配慮されていることが多い
が、XSSの危険がある操作をあえて残している こともある
そのような操作は大抵「危険」とはっきり書いてある
書いてあるのに、使って脆弱性を発生させる 人が後をたたない
危険と書いてあるものは、よほどのことがない限り使わない ように
レビューでも「使うな」と指摘すること
152
Slide 153
Slide 153 text
Bengo4.com, Inc.
ビルトインのディレクティブ | Vue.js
https://ja.vuejs.org/api/built-in-directives
153
Slide 154
Slide 154 text
Bengo4.com, Inc.
などの一般的なコンポーネント – React
https://ja.react.dev/reference/react-dom/components/common#common-props
154
Slide 155
Slide 155 text
SQLインジェクション
155
5. Webアプリケーションの脆弱性
Slide 156
Slide 156 text
Bengo4.com, Inc.
SQLインジェクションとは
XSSが脆弱性の王なら、SQLインジェクションは女王
XSSでは外部入力がHTMLを破壊していたが、
SQLインジェクションではSQL文を破壊する
データベースに対して、攻撃者の意図した操作が行われる
データベース上の情報が全て漏洩したり、全て破壊されたり、
改ざんされたりすることがある
データベースの値をHTMLに出力している場合、XSS攻撃も可能
156
Slide 157
Slide 157 text
Bengo4.com, Inc.
SQLインジェクションの攻撃
能動的攻撃 であり、罠を踏ませたりする必要はない
攻撃者が直接、攻撃を実行する
入力値がデータベースに渡る箇所に対し、
SQL文を破壊するような文字列を入力する
攻撃が成功すると不正なSQL文が実行されてしまい、
データベースの読み出し、書き換えなどが行われる
157
Slide 158
Slide 158 text
よく知られている事件
158
Slide 159
Slide 159 text
Bengo4.com, Inc.
価格比較サイト「価格.com」が
不正アクセスを受けた事件
サイトが改竄され、
ウイルスがダウンロードされた
原因の詳細は公開されていないが、
SQLインジェクションと言われている
159
カカクコム事件
Slide 160
Slide 160 text
ディレクトリトラバーサル
160
5. Webアプリケーションの脆弱性
Slide 161
Slide 161 text
Bengo4.com, Inc.
ディレクトリトラバーサルとは
パストラバーサル とも呼ばれる
システム内部のファイルを読み書きする処理に
ユーザー入力が反映されるケースがある
悪意ある入力があると、本来とは異なるファイルが読まれ、
情報漏洩などにつながることがある
特に ../ が入力されると、データファイルが格納されている
ディレクトリの外にあるファイルにアクセスされることがある
161
Slide 162
Slide 162 text
Bengo4.com, Inc.
典型的なディレクトリトラバーサルの例
たとえばこのようなURLがあったとする
https://example.com/foo.php?template=normal
内部的には normal.html というファイルを読み取って処理する
このとき、以下のようなURLにアクセスすると、
https://example.com/foo.php?template=../../../../../etc/passwd%00
/etc/passwd の内容が見えてしまうことがある
(実際にはそんなにうまくいくことは少ない)
162
Slide 163
Slide 163 text
Bengo4.com, Inc.
参考: UTF-8の冗長符号化
UTF-8は各文字を1〜4バイトの可変長で表現する
「/」( U＋002F) は0x2Fというバイト列になるが、
昔は2〜4バイトで表現することも可能だった (今の仕様では禁止)
● 0xC0 0xAF
● 0xE0 0x80 0xAF
● 0xF0 0x80 0x80 0xAF
このようなバイト列は、/ と解釈されたりされなかったりした
かつて IIS にこの脆弱性があり、Nimdaウイルスに悪用された
163
Slide 164
Slide 164 text
Bengo4.com, Inc.
ディレクトリトラバーサルとファイル名予測
ディレクトリトラバーサルの攻撃では、多くの場合、
攻撃者はターゲットとなるファイル名・パス名を知る必要がある
/etc/passwd はたいていのLinuxシステムに存在し、
多くのユーザー権限で読み取り可能なのでデモには使いやすい
ただ、実際にはこれが見えても大きな実害はない
本当に問題があるのはスクリプトファイルや、
ユーザーの情報を保存したデータファイル、ログファイルなど
164
Slide 165
Slide 165 text
有名な事例
165
Slide 166
Slide 166 text
Bengo4.com, Inc.
ACCS事件
166
コンピュータソフトウェア著作権協会
(ACCS)は、F社のレンタルサーバーで
ASK ACCSというサイトを運用
F社が提供するPerlスクリプト
csvmail.cgi を設置・使用していた
これに脆弱性があり、
ユーザーの質問やタレコミが漏洩
Slide 167
Slide 167 text
CSRF
167
5. Webアプリケーションの脆弱性
Slide 168
Slide 168 text
Bengo4.com, Inc.
CSRFとは?
Cross-Site Request Forgeryの略
XSSにならってXSRFと略されることもある
HTMLの仕様上、サイトをまたがったフォーム送信は許されている
攻撃者は自身のサイトにフォームを置いて、
攻撃対象のユーザーを誘導し、対象サイトにPOSTさせる
168
Slide 169
Slide 169 text
Bengo4.com, Inc.
POSTで深刻な結果になる場合、問題が起きる
CSRFの攻撃では、
攻撃者はPOSTの結果として表示されるページを読み取れない
しかし、POSTさせること自体は可能
被害者がログインしていれば、
ログインセッションのCookieつきでPOSTされる
POSTで深刻な結果が起きる場合には問題が起きる
購入処理、送金処理、パスワード変更、etc.
169
Slide 170
Slide 170 text
有名な事例
170
Slide 171
Slide 171 text
Bengo4.com, Inc.
171
ネットなりすまし事件の怖さ、誰もが「容疑者」に 犯行の手口と自衛策とは
https://www.nikkei.com/article/DGXZZO48415000U2A111C1000000/
Slide 172
Slide 172 text
Bengo4.com, Inc.
172
日経新聞に CSRFの話
Slide 173
Slide 173 text
Bengo4.com, Inc.
日経新聞の CSRFの話
横浜市の小学校襲撃予告で犯人が使ったのは、CSRF（クロスサイト・リクエスト・
フォージェリ）といわれる手法。不正プログラムを仕込んだウェブサイトのリンクを
クリックしただけで、意図せず別のサイトに書き込みをさせられるものだ。書き込ま
れるサイト側で防ぐ手段もあるが、襲撃予告が送られた横浜市の「市民からの
提案」投稿用フォーム には、当時対策が施されていなかった（10月17日に対応
ずみ）。
(中略)
このリンクを反射的にクリックしたと思われる杉並区の男性のパソコンから、自動
で横浜市ホームページに脅迫文が送られた。
173
Slide 174
Slide 174 text
Bengo4.com, Inc.
これはCSRFなのか?
「市民からの提案」投稿用フォームは誰でも投稿できるもので、
ログインの機能はなかった
通常、CSRFはログイン済みのユーザーを狙うもの
認証がない場合、攻撃者が直接その操作をすればよいため
しかしこのケースでは、
警察が投稿者のIPアドレスを調査し、逮捕した
つまり、IPアドレスを偽装するためだけに攻撃が行われた
174
Slide 175
Slide 175 text
Bengo4.com, Inc.
175
2秒間で300文字を一心不乱に打ち込んだ
Slide 176
Slide 176 text
アップロードファイルによる
サーバー側スクリプト実行
5. Webアプリケーションの脆弱性
176
Slide 177
Slide 177 text
Bengo4.com, Inc.
アップロードファイルとは
Webアプリケーションの中には、
ユーザーがファイルをアップロードする機能を提供するものがある
受け取ったファイルの処理が甘いと、
PHPスクリプトなどをアップロードされ、
サーバー側で実行されてしまうことがある
攻撃者はまず、WebShell と呼ばれる
任意コマンドを実行できるツールをアップロードする
そのあとは好きなことをする
177
Slide 178
Slide 178 text
Bengo4.com, Inc.
WordPress 用プラグイン File Manager の脆弱性について
https://www.jpcert.or.jp/newsflash/2020090301.html
178
Slide 179
Slide 179 text
認可制御の不備
179
5. Webアプリケーションの脆弱性
Slide 180
Slide 180 text
Bengo4.com, Inc.
認可制御の不備
ユーザーが本人かどうか特定することを「認証」といい、
ユーザーの権限に基づいて操作を許可することを「認可」という
認可制御の不備とは、
ユーザーの本来の権限ではできないはずの操作を
許してしまっているという問題のこと
かなり広い言葉であり、実際にはさまざまな脆弱性を含む
180
Slide 181
Slide 181 text
Bengo4.com, Inc.
権限昇格
認可制御の不備の中でも特に、
ログインユーザーの権限が複数のレベルに分かれており、
低レベルのユーザーが上位レベルの操作をできてしまう場合、
「権限昇格」と呼ぶ
例: 一般ユーザーが管理者ユーザーの権限で操作できた
181
Slide 182
Slide 182 text
キャッシュからの情報漏洩
182
5. Webアプリケーションの脆弱性
Slide 183
Slide 183 text
Bengo4.com, Inc.
キャッシュからの情報漏洩とは
Webでは表示の高速化のために「キャッシュ」という技術を使う
一度表示した内容を保持しておき、
次回のリクエストではそれを使いまわす
ユーザーごとに異なる情報が出るログイン後の画面などは、
不用意にキャッシュすると、あるユーザーの画面が
キャッシュされて別のユーザーに見える場合がある
他人の個人情報等が見える状態になるので非常にまずい
キャッシュを禁止するHTTPヘッダを出すなどして対応すること
183
Slide 184
Slide 184 text
Bengo4.com, Inc.
別人問題
他のユーザーの情報や画面が見えてしまう、という現象は
広く「別人問題」 と呼ばれることがある
別人と取り違えられているように見えることから
キャッシュが原因となっている場合が多いが、
認証関連の不具合や、
内部ファイルの競合状態 (レースコンディション )
が原因で発生することもある
184
Slide 185
Slide 185 text
有名な事例
185
Slide 186
Slide 186 text
Bengo4.com, Inc.
186
CDN切り替え作業における、 Web版メルカリの個人情報流出の原因につきまして
https://engineering.mercari.com/blog/entry/2017-06-22-204500/
Slide 187
Slide 187 text
セッション IDの推測
187
5. Webアプリケーションの脆弱性
Slide 188
Slide 188 text
Bengo4.com, Inc.
セッション ID発行アルゴリズムの脆弱性
Cookieのセッション管理のところで説明したように、
セッションIDが推測されると
他人のセッションを乗っ取ることができてしまう
セッションID発行アルゴリズムが脆弱だとそういうことが起きる
最低なのは、セッションIDを連番の数字にしてしまうこと
Web黎明期にはそのような大変まずい実装もしばしば見られた
188
Slide 189
Slide 189 text
ここまでのまとめ
189
5. Webアプリケーションの脆弱性
Slide 190
Slide 190 text
Bengo4.com, Inc.
Webアプリケーションの脆弱性
実事例も含め、さまざまな脆弱性を紹介した
● クロスサイトスクリプティング
○ DOM Based XSS
● SQLインジェクション
● CSRF
● アップロードファイルによるサーバー側スクリプト実行
● 認可制御の不備
● キャッシュからの情報漏洩
● セッションIDの推測
190
Slide 191
Slide 191 text
191
おわりに
Slide 192
Slide 192 text
エンジニアとして
セキュリティと向き合う
192
Slide 193
Slide 193 text
Bengo4.com, Inc.
常にセキュリティを意識する
193
システム開発においてセキュリティは非機能要件
機能としては明確に要求されない ことが多い
誰も意識していないと、セキュリティが完全に欠落 してしまう
常に頭の片隅には置いておく必要がある
セキュリティ事故の多くは人為ミスや、組織の問題で起きる
実際のところエンジニアの責務ではないことが多いが、
エンジニアでなければフォローできないことも多い
エンジニアは、セキュリティについて常に意識しておくべき
Slide 194
Slide 194 text
疑問を持ち、学び続けること
194
Slide 195
Slide 195 text
Bengo4.com, Inc.
セキュリティの「常識」を常に疑う
195
Webでは周囲の状況が常に変化している
新しい機能ができたり、古い機能が廃れていったりする
昔の常識が通用しなくなることもある
周りの人は古い知識を「常識」として語ったりもする
常識を疑い、常に最新の情報を学び続ける こと
人の噂に耳を傾けるのではなく、仕様を調べる こと
Slide 196
Slide 196 text
Bengo4.com, Inc.
AIに聞く時の注意
AIは、セキュリティ分野ではハルシネーションが多い
AIの回答を鵜呑みにせず、常に最新の情報を確認すること
セキュリティに関する議論は複雑であり、
世間では誤った説明や古くなった説明などが多いためと思われる
仕様文書が存在する技術仕様 に関しては、正確に答えることが多い
AIに聞いてみるときは「最新の仕様」 について聞くと良い
196
Slide 197
Slide 197 text
197
おつかれさまでした
Slide 198
Slide 198 text
会社紹介
198
Slide 199
Slide 199 text
Bengo4.com,Inc.
VISION
まだないやり方で、世界を前へ。
Drive a paradigm shift for the better world.
MISSION
｢プロフェッショナル・テック ｣で、次の常識をつくる。
Be the Professional-Tech Company.
プロフェッショナルだからできること。専門知とテクノロジーで、社会に貢献する。
Slide 200
Slide 200 text
Bengo4.com, Inc.
OUR SERVICE
税理士に無料で相談・検索できる日本最大級の
税務相談ポータルサイト
最新の法改正や実務について分かりやすく解説する
日本最大級の企業法務ポータルサイト
日本最大級の無料法律相談ポータルサイト
時事問題の弁護士解説を中心としたメディア
弁護士事務所、企業法務職向け人材紹介事業
AI基盤技術「 LegalBrain 1.0」を組み込んだ
リーガル特化型 AIエージェント
契約の締結から管理までデジタルで完結させる
契約マネジメントプラットフォーム
Slide 201
Slide 201 text
Bengo4.com, Inc.
We are Hiring