Webセキュリティ 情報工学専攻　1年　赤木里騎 P226~241.

Presentation on theme: "Webセキュリティ 情報工学専攻　1年　赤木里騎 P226~241."— Presentation transcript:

1 Webセキュリティ 情報工学専攻　1年　赤木里騎 P226~241

2 Webサーバー(Apacheやnginx)
8.4 SQLインジェクションとその対策 8.4.1 SQLインジェクションとは ②RDBMSとやりとり [SQL] select * from tableName; DBからデータを取得する DB PHP実行モジュール PHPプログラム ①検索を入力する 検索 Webサーバー(Apacheやnginx) OS

3 Webサーバー(Apacheやnginx)
8.4 SQLインジェクションとその対策 8.4.1 SQLインジェクションとは Formから送られて来るデータについてセキュリティ対策を行わないとすると， SQLを直接操作する文字列を入力することでデータを取得できる →SQLインジェクション ②RDBMSとやりとり [SQL] select * from tableName; DBからデータを取得する DB PHP実行モジュール PHPプログラム ①検索を入力する 検索 Webサーバー(Apacheやnginx) OS

4 8.4.1 SQLインジェクションとは SQLインジェクション3つの脅威 8.4 SQLインジェクションとその対策 機密情報の漏洩
DBのデータ全て抜き取られる危険性 重要情報の改竄 Webページを攻撃者の意図通りに書き換えることができる 認証処理のバイパス（不正な迂回） DBのIDとパスワードによる認証を回避することができる

5 8.4.2 SQLインジェクションの仕組み 8.4 SQLインジェクションとその対策 RDBMS taro 検索 Webサーバー ユーザー名
① taro 検索 ユーザー名

6 8.4.2 SQLインジェクションの仕組み 8.4 SQLインジェクションとその対策 RDBMS taro 検索 Webサーバー ユーザー名
Webサーバーは「taro」を取り出し，SQL文を発行し，RDBMSへ RDBMS ① taro 検索 ②SELECT * FROM users WHERE id=‘taro’; ユーザー名

7 8.4.2 SQLインジェクションの仕組み 8.4 SQLインジェクションとその対策 RDBMS taro 検索 Webサーバー ユーザー名
Webサーバーは「taro」を取り出し，SQL文を発行し，RDBMSへ RDBMSは受け取ったSQL文を実行して，結果をWebサーバーに返す RDBMS ① taro 検索 ②SELECT * FROM users WHERE id=‘taro’; ユーザー名 ③

8 8.4.2 SQLインジェクションの仕組み 8.4 SQLインジェクションとその対策 RDBMS taro 検索 Webサーバー ユーザー名
Webサーバーは「taro」を取り出し，SQL文を発行し，RDBMSへ RDBMSは受け取ったSQL文を実行して，結果をWebサーバーに返す 受け取った結果からWebサーバーはHTMLページを構成し，Webブラウザで表示する RDBMS ① taro 検索 ②SELECT * FROM users WHERE id=‘taro’; ユーザー名 ③ ④

9 8.4.2 SQLインジェクションの仕組み 8.4 SQLインジェクションとその対策 RDBMS SQLインジェクション攻撃の場合 検索
Webサーバー SQLインジェクション攻撃の場合 利用者はユーザー名(taro’ or ‘A’ = ‘A’)を入力すると，Webサーバーへと送信される Webサーバーは「taro‘ or ‘A’ = ‘A’」を取り出し，SQL文を発行し，RDBMSへ RDBMSは受け取ったSQL文を実行して，結果をWebサーバーに返す 受け取った結果からWebサーバーはHTMLページを構成し，Webブラウザで表示する ※ただし，SQL文の実行結果は，「or ‘A’ = ‘A’」があるため，usersテーブから全てのデータを取得することができる． →結果的に全ユーザー情報がブラウザに表示されてしまう． RDBMS ① or ‘A’ = ‘A’ ②SELECT * FROM users WHERE id=‘taro’ or ‘A’ = ‘A’; 検索 ユーザー名 ③ Taro ‘ or ‘A’ = ’A’ ④

10 8.4.3 SQLインジェクションの対策 SQLインジェクション脆弱性の原因 SQLインジェクション脆弱性の対策
Webサーバー作成者の意図せぬ値であること SQLインジェクション脆弱性の対策 プレースホルダによるSQL文を組み立てる方法（バインドメカニズム の利用） Webサーバー側でSQL文を組み立てる際にエスケープ処理を実施する

11 8.4.3 SQLインジェクションの対策 バインドメカニズムの利用 8.4 SQLインジェクションとその対策 文字列として認識される．
検索 ユーザー名 taro ‘ or ‘A’ = ’A’ 対策なし： SELECT * FROM users WHERE id=‘taro’ or ‘A’ = ‘A’; バインドメカニズム利用： SELECT * FROM users WHERE id=‘taro’ or ‘A’ = ‘A’’; 文字列として認識される． プリアドステートメント（SQL文の雛形）に バインド（割り当て）することからバインド メカニズムと呼ばれている．

12 8.4.3 SQLインジェクションの対策 エスケープ処理の実施 8.4 SQLインジェクションとその対策
検索 ユーザー名 taro ‘ or ‘A’ = ’A’ 対策なし： SELECT * FROM users WHERE id=‘taro’ or ‘A’ = ‘A’; エスケープ処理： SELECT * FROM users WHERE id=‘taro’’ or ‘’A’’ = ‘’A’’; 変数中の特殊文字を普通の文字列として認識させる． WebサーバーからDBにSQL文を作成する直前に言語レベルで エスケープさせられる． 例：PHPの場合はhtmlspecialchar関数などがある →「”」は「"」となる．

13 8.5.1 CSRF攻撃とは Cross Site Request Forgeries攻撃とは 8.5 CSRF攻撃とその対策
攻撃者が用意したサイトの閲覧中に利用者の意図関係なく，別のサイ ト上で何らかの操作を行わせる攻撃のこと [例] 会員制サイトの退会処理 会員制サイトへの意図しない書き込み Webインターフェースを持つ機器の設定変更 ※XSSやSQLインジェクションのように直接的に機密情報を盗み出す訳 ではないことに注意．意図せぬ処理がなされることが問題．

14 8.5.2 CSRF攻撃の仕組み 正常な動作 8.5 CSRF攻撃とその対策 https://会員制サイト/ 検索 ID: Pass:
①会員制サイトへのログイン ②Webページのデータ送信 ③会員制サイトからのログアウト

15 8.5.2 CSRF攻撃の仕組み CSRF攻撃 8.5 CSRF攻撃とその対策 罠サイト https://会員制サイト/ 検索 ID:
Pass: ①会員制サイトへのログイン ②クッキーの送信 ③罠サイトへの誘導 ④悪意あるアクションを伴うWebページ ④で会員制サイトへの退会処理のFormを作成し，ユーザーのそのサイトのクッキーのセッションIDを保持したまま罠サイトで入力を行うと退会処理が実行されてしまう． ⑤クッキー付きで意図せぬ操作が伴うアクセス

16 8.5.3 CSRFの対策 対策１ 8.5 CSRF攻撃とその対策 罠サイト https://会員制サイト/ 検索 ※秘密情報がないので
ID: Pass: ①会員制サイトへのログイン ②各ページに埋め込むための秘密情報を渡す ③罠サイトへの誘導 ※秘密情報がないので 正規の入力としない ※通信はSSL/TLSによ る暗号化が施されてい るとする ④悪意あるアクションを伴うWebページ ⑤悪意あるアクション（秘密情報なし）

17 8.5.3 CSRFの対策 対策２ 8.5 CSRF攻撃とその対策 罠サイト https://会員制サイト/ 検索 ※意図せぬ処理が
ID: Pass: ①会員制サイトへのログイン ②クッキーの送信 ③罠サイトへの誘導 ④悪意あるアクションを伴うWebページ ⑤悪意あるアクション ※意図せぬ処理が なされることを防ぐ． ⑥操作の確認とパスワードの入力を求めるページ

18 8.5.3 CSRFの対策 対策３ 8.5 CSRF攻撃とその対策 罠サイト https://会員制サイト/ 検索
ID: Pass: ①会員制サイトへのログイン ②クッキーの送信 ③罠サイトへの誘導 退会処理には同会員制サイトからしかたどり着かないはずなので，直前にどのサイトにいたのかをチェックすれば良い． ※Refererヘッダを送り出さないWebブラウザを利用していたり，Refererヘッダを取り除くプロキシを利用していることがあるため注意 ④悪意あるアクションを伴うWebページ ⑤悪意あるアクション ※Refererヘッダを用いて，直前のページを確認

19 8.6.1 Web2.0のセキュリティ Web2.0はAjaxに代表されるような行動な技術の集合体 オライリーが提唱
[従来] [Web2.0] Webページは静的で単純だったため， セキュリティへの対処はWebサーバや そのOSなどの，限定的な範囲だった． サーバ側だけの開発から，クライアント側のWebブラウザ上のコードと合わせた開発が当たり前になっている． 結果的には，サーバ側だけでなく，Webブラウザ側にも脆弱性が入り込みやすくなっている．

20 8.6.2 DOM Based XSS DOMを通じたHTML操作の結果として，意図せぬスクリプトの 実行やそれを許す脆弱性を指す [原因]
8.6 Web2.0技術のセキュリティ 8.6.2 DOM Based XSS DOMを通じたHTML操作の結果として，意図せぬスクリプトの 実行やそれを許す脆弱性を指す [原因] JavaScriptによるWebページへの出力処理に不備 →意図しないスクリプトの埋め込みやHTMLタグの挿入を防ぐ JavaScriptライブラリに起因するケース →JavaScriptライブラリの更新

21 8.6.2 DOM Based XSS DOMによる動的なブラウザの表示情報更新
8.6 Web2.0技術のセキュリティ 8.6.2 DOM Based XSS DOMによる動的なブラウザの表示情報更新 document.write(data)はwebページにリロードなしで動的 に追加 攻撃のためのスクリプトを含むデータが悪意あるwebサイト からdataに格納 DOMを用いた攻撃が成立する可能性 [例] data=“<script>alert(document.cookie);</script>” ※ユーザのクッキーをアラートにより表示させる

22 8.6.2 DOM Based XSS eval()を用いた動的なスクリプトの実行 [例]
8.6 Web2.0技術のセキュリティ 8.6.2 DOM Based XSS eval()を用いた動的なスクリプトの実行 [例] http.onreadystatechange = function () { if (http.readyState == 4){ var response = http.responseText; eval(data); } ※data=delete_files()で，data変数に対してエスケープ処理を行なってい ない場合，文字列を実行し，重要なファイルが削除される可能性がある．

23 8.6.3 同一生成元ポリシー 8.6 Web2.0技術のセキュリティ http://a.example.com/ ケースA
①メインコンテンツのロード ②XHRリクエスト ③レスポンス ②’XHRリクエスト ③’レスポンス ケースB

24 8.6.3 同一生成元ポリシー http://www.example.com/dir/page.htmlと同一オリジンと みなすかどうか
8.6 Web2.0技術のセキュリティ 8.6.3 同一生成元ポリシー みなすかどうか 対象となるドメイン 説明 理由 判定 全く同じ 同じプロトコル・ホスト ◯ ディレクトリが違う ポートが違う × SSL通信 プロトコルが違う URIが違う ドメインが違う

25 8.6.3 同一生成元ポリシー 8.6 Web2.0技術のセキュリティ http://a.example.com/
クロスオリジンでも一定の条件で通信を可能とするXHR2という技術が利用されている ①メインコンテンツのロード ②XHRリクエスト ③レスポンス レスポンスに含まれるヘッダ Access-Control-Allow-Origin:

26 セキュリティーニュース Google Chromeの不正な拡張機能、大手組織を含む50万 ユーザーが利用