2025新卒研修・Webアプリケーションセキュリティ #弁護士ドットコム

2025年入社の新卒エンジニア向けに実施した研修「Webアプリケーションセキュリティ」の資料です。弁護士ドットコム株式会社 開発本部 技術戦略室の太田良典が講師として登壇しました。

セッションタイトル：2025年入社の新卒エンジニア向け研修「Webアプリケーションセキュリティ」

■ 弁護士ドットコム株式会社プロダクト組織について
https://speakerdeck.com/bengo4com/introduction-for-creators

■ 採用情報はこちら
https://hrmos.co/pages/bengo4/jobs

■ テックブログ：弁護士ドットコム Creators’ blog
https://creators.bengo4.com/

■ X(Twitter)：弁護士ドットコム CREATOR'S
https://x.com/bengo4_creators

Transcript

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