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/ が「属性値」 属性名 = 属性値 の形で書き、属性値は引用符で括る 括らなくて良い場合もあるのだが、必ず引用符で括るべき これはセキュリティの観点からも非常に重要 149

Slide 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