コラム

CTC教育サービス・ホーム　＞　コラム　＞　ウェブ・セキュリティ学習のため徳丸本を読んでみた　＞　第5回　同一オリジンポリシーを理解しよう

ウェブ・セキュリティ学習のため徳丸本を読んでみた

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第5回　同一オリジンポリシーを理解しよう (三雲勇二) 2023年7月

みなさん、こんにちは。エンジニアをしております、三雲と申します。

普段は初心者エンジニアに Web セキュリティについて教えることがあります。
ウェブセキュリティの分野は徳丸本（安全なWebアプリケーションの作り方第2版）をオススメしております。
今回も初心者の気持ちで徳丸本を読んで、気になった部分について確認していきたいと思います。

この徳丸本を読みすすめるに当たり、過去の第1回～第3回で実習環境を準備しております。
実習環境を重視しているのは、手を動かして動作を確認しながら読み進めると、圧倒的に理解が進むからです。
まだ実習環境を準備していない方は、ぜひ実習環境をご準備のうえでいっしょに試していきましょう！
私は M1 MacBook & Docker 環境で実習しております。

さて今回は、紙書籍版 p.73 ～ p.84 の部分の内容になります。
テーマは「同一オリジンポリシーを理解しよう」です。

同一オリジンポリシーという言葉は初心者にはなかなか聞き慣れない言葉かと思いますが、セキュリティ上でとても大事な概念です。
Web アプリケーションが正しく動作しないときに、同一オリジンポリシーを深く理解せず、とにかく動かそうと制約を外すような実装をしていることが見られます。
これはセキュリティ上、非常によくありません。
基本的なところをきちんと原理原則のもと理解しておくと、新しい分野の知識を理解する上で重要となりますので、しっかり学習しておきたいところです。

せっかくですので私も初心に戻り、新人エンジニアやこれからエンジニアを目指している方の「Webセキュリティは大事なので改めて勉強してみよう！」という視点で、分かりやすい記事になればと思います。どうぞよろしくお願いいたします。

まずは攻撃の分類をおさらい

まずはこの節で書かれている攻撃の分類をまとめてみました。

「受動的攻撃」はいわゆる罠を仕掛けるような攻撃のことのようです。
対となる「能動的攻撃」については今回は掘り下げないので、徳丸本 p.73 を確認しておいてください。

fig01

罠を仕掛ける「受動的攻撃」は見ての通り、3パターンあるようです。
これらは、ユーザーはブラウザで Web サイトを閲覧すると、なんらかの攻撃を受けてしまうものとなるようです。
これらは徳丸本にかかれている図を見ると大変わかりやすいので、まずは p.74～75 ページの図を確認しましょう！

一般的に Web サイトをブラウザで閲覧し攻撃された（ウィルスに感染など）というと、怪しい Web サイトにアクセスしたからというイメージでした。
これは「単純な受動的攻撃」に分類されるようです。

あれ？ちょっと分類を見直してみてください。
他にも「正規サイトを悪用する受動的攻撃」と「サイトをまたがった受動的攻撃」というものがあるようです。
つまり、次の2つの点が考えられます。

正規サイトとして安心して Web サイトを閲覧するときも注意が必要そう。
自分が管理している Web サイトが攻撃に利用される可能性がありそう。

怪しい Web サイトにアクセスしていないから大丈夫、というのはセキュリティとして危ない考え方となりそうです。
具体的な攻撃方法は、徳丸本で別の章で実例を出しながら解説があるようです。
まずは、3パターンある図を見て、攻撃の種類を覚えておきましょう！

サンドボックスを試してみよう

ここから実習環境で徳丸本の内容を試してみましょう。
OWASP ZAP を忘れずに起動しておきましょう。

これから 2 つのページをアクセスするのですが、どちらも iframe を使って下記のページを読み込んでいるようです。 http://example.jp/32/32-002.html

fig02

まずは、下記のページを開きます。
http://example.jp/32/32-001.html 徳丸本 p.78 を参考に、今回はパスワード kakushi_pass という文字を入力して試してみました。

fig03

確かに iframe 内部のパスワードが取得できました。
これは、Web サイトを作っている人からすると便利ですね！と思いたいところですが。。。
パスワードを入力するユーザー側の気持ちになると、パスワードを他のサイトから取得できてしまう恐ろしさを感じると思います。

仮に iframe 内部の URL をツイッターなどのページにしたら、ツイッターのパスワードが取られてしまうのでしょうか？

その疑問を解決するために、次のページにアクセスしましょう。
http://trap.example.com/32/32-900.html
徳丸本 p.79 を参考に、同じくパスワード kakushi_pass という文字を入力して試してみました。

fig04

今度は警告が表示されてパスワードが取得できませんでした。
これはパスワードが取得されないので、ユーザーとしては安心できますね。

違いを確認する

先程の違いは、何が違ったのでしょうか？
上記の 3 つの URL を改めて確認してみます。

	URL	FQDN
iframe 内部のページ	http://example.jp/32/32-002.html	example.jp
パスワード読み込みができた	http://example.jp/32/32-001.html	example.jp
パスワード読み込みが拒否された	http://trap.example.com/32/32-900.html	trap.example.com

FQDN に着目すると、ここが異なるために結果が変わったようです。
これは、徳丸本の p.80 に書いてある「同一オリジンである条件」に該当します。
厳密にはスキーマとポート番号の一致も必要ですので、よく読んでおいてください。
SSL 対応をしている改修をしているときに、http と https は同一オリジンとはならないという点は、割と引っかかりがちです。

つまり、ツイッターのパスワードを iframe 経由で取得しようとするなら、FQDN をあわせないと原則できなさそうです。
これがブラウザのサンドボックスのセキュリティ機能となります。

これだと Web サイトの使い勝手が悪くなってしまうので、サンドボックスを超えて許可をする方法があるのですが今回は触れません。
次回のコラムで詳しく試してみたいと思います。

実習環境で試してみると、同一オリジンによってアクセスが許可されている範囲が絞られていることがわかりました。
普段から原理原則に乗っ取り、それぞれのリソースの URL が同一オリジンであることを考慮しながらプログラミングしてみてください。