SOP(同一オリジンポリシー)&Origin

同一オリジンポリシーについてまとめてみました。
自分が分かるように引用してまとめたので間違いなどがあれば指摘してください。

# Same-Origin Policy（SOP）とは
**Same-Origin Policy（同一オリジンポリシー）** : JavaScriptなどのクライアントスクリプト（ブラウザなどのクライアント側のシステムで動作するスクリプトのこと）からサイトをまたがったアクセスを禁止するセキュリティ上の制限でありブラウザのサンドボックスに用意された**制限の一つ。**
「同一生成元ポリシー」や「同一源泉ポリシー」とも呼ばれる。

ウェブコンテンツにアクセスするために使われるURLのスキーム（プロトコル）、ホスト、ポートの3つの組み合わせをオリジンと呼び、これらが同じ場合は同一のオリジンとみなし、同じ保護範囲のリソースとして取り扱うというもの。
**つまり、異なるオリジン（クロスオリジン）からのリソースへのアクセスを制限するという仕組みになる。**


## Origin（オリジン）
スキーム（プロトコル）、ホスト（インターネット上に公開している場合はドメイン名）、ポートから構成されるもので、それぞれはURLの一部分を指す。
`http://store.example.com:80`
上記のURLを例に挙げた場合は以下のようになる。
- スキーム（プロトコル） = http
- ホスト = store.example.com
- ポート = 80
これらが1つでも異なる場合は異なるオリジンとして判断される。

**オリジンの例**
・以下はスキーム (http) とホスト名 (example.com) が同じなので同一オリジンであり、ファイルパスが異なるのは関係がありません。
`http://example.com/app1/index.html`
`http://example.com/app2/index.html`

・以下のサーバーはHTTPコンテンツを配信するのに既定で 80 番ポートを使うため、これらは同一オリジン。
`http://example.com:80`
`http://example.com`

・以下は、異なるスキームを使用しているため、異なるオリジン。
`http://example.com/app1`
`https://example.com/app2`

・以下は、異なるホスト名を使用しているため、異なるオリジン。
`http://example.com`
`http://www.example.com`
`http://myapp.example.com`

・以下は異なるポートを使用するため、異なるオリジン。
`http://example.com`
`http://example.com:8080` 

ここで注意が必要なのがオリジンはURLやドメイン名とは別物ということ。
URLはリソースの位置を表すため、該当ファイルのパス名までを含むが、オリジンはスキームとホスト名とポート番号までの組み合わせをオリジンとする。
**URL**
`scheme://host:port/path/file`
**オリジン**
`scheme://host:port`




## 同一オリジンポリシーがなぜ必要か
⚫︎クロスサイトスクリプティング（XSS）やクロスサイトリクエストフォージェリ（CSRF）等のサイバー攻撃を防ぐため。
⚫︎ログイン後のみ表示される情報を他のサイトから参照されることを防ぐため。

例えばユーザーがECサイトにログインしている状態で別の悪意あるサイトを閲覧した場合、ECサイトに登録された個人情報を悪意あるサイトから取得できてしまう。

悪意のあるサイトのオリジンを http：//akui.com（B罠サイト）とし、欲しい情報があるECサイトのオリジンを https：//jouhou.com（Aサイト） とする。

Aサイトというログインが必要なサイトにユーザーがログインしていたとする。
その状態で、B罠サイトという攻撃者が作成した罠サイトにアクセスをする。
この時に、B罠サイトにAサイトを参照してログイン情報や個人情報を抜き取るというJavaScriptのプログラムが仕掛けられていたら、ただサイトを閲覧しただけなのに情報が抜き取られてしまう可能性がある

**このようにサイトをまたがった攻撃は「受動的攻撃」と呼ばれ、代表的なものにクロスサイト・スクリプティング（XSS）やクロスサイト・リクエストフォージェリ（CSRF）がある。**

ここで、活躍するのが同一オリジンポリシー。
同一オリジンポリシーによって、異なるオリジンであるB罠サイトからAサイトのコンテンツにアクセスすることは出来ない。これで、情報が抜き取られることはなくなる。

同一オリジンポリシーにより、攻撃者の罠サイトにアクセスした際にあるサイトの個人情報を盗み取られるなどの「受動的攻撃」を防ぐことができる。

## 制限の対象となるもの・ならないもの
「異なるオリジンからのリソースへのアクセスを制限する」と説明したが、同一オリジンポリシーによって制限されるもの・されないものが存在する。

### 制限の対象となるもの
**⚫︎JavaScriptでの非同期通信（Ajax、いわゆるXMLHttpRequest や FetchAPIを使った通信）**
厳密には「リクエストはできるがレスポンスを取得できない」という制限で、クロスオリジンでは「CORS」により許可された場合にしかレスポンスを取得することはできない。

**⚫︎許可されていないcanvasタグによる別オリジンの画像の読み込み**
「CORS」による許可なしに異なるオリジンから読み込まれた画像・データをcanvasタグ内に描画するとcanvasタグは汚染（taint）される。 汚染されたcanvasタグは安全とみなされなくなり、データへのアクセス（getImageData()、toBlob()、toDataURL()）が制限される。

**⚫︎Web Storage**
HTML5で導入されたブラウザ上にデータを保存する機構であるWeb Storageなどのブラウザー内部に保存されるデータへのアクセスはオリジン単位で権限が分かれているため、異なるオリジンに属するストレージを読み書きすることはできない。

**⚫︎X-Frame-Options**
X-Frame-Optionsとは、HTTPヘッダのフィールド（項目）の一つで、Webページを別のページ中のiframeタグやembedタグ、objectタグから参照して埋め込み表示するのを許可するか指定するもの。
レスポンスヘッダーにSAMEORIGINが設定されている場合、異なるオリジンではiframeタグなどを使った別サイトコンテンツの埋め込みができない。

### 制限の対象とならないもの
⚫︎`<scrip>`で読み込まれたJavaScript
⚫︎`<link>`で読み込まれたCSS
⚫︎`@font-face`で読み込まれたWebフォント
注）クロスオリジンでは許可されないブラウザもある。
⚫︎`<img>`で読み込まれた画像（PNG、JPEG、GIF、BMP、SVGがサポート対象）
⚫︎`<video>`、`<audio>` タグで読み込まれたメディアファイル
⚫︎`<object>`、`<embed>` タグで埋め込まれたリソース
⚫︎`<iframe>`、`<frame>`での別サイトコンテンツの読み込み
注）コンテンツの読み込みは許可されるが、コンテンツ内のドキュメントにはアクセス出来ない。

### オリジン以外をベースに制限を設けているもの
⚫︎Cookie
Cookieに関してはスキーム、ポートは関係ない。
⚫︎HTTP認証

### クロスオリジンのアクセスを許可するには
異なるオリジンへのアクセスを許可するにはオリジン間リソース共有（CORS）を使用する。
CORSを使用することで特定のオリジンからのリクエストに対してはリソースへのアクセスを許可する、といったルールの制定が可能になる。

# 結論
1.攻撃者はJavaScriptによりブラウザを強制的に操作することができる。
2.それにより攻撃者のではなく、ブラウザの権限で攻撃者の意図する操作が行われる。
3.そのため同一オリジンポリシーがない場合、本来権限がないため攻撃者がアクセスできないはずの別オリジンのデータを盗み出すことができる。

というのが同一オリジンポリシーがWebセキュリティにおいて必要な理由です。

# 参考記事
https://qiita.com/ymbn/items/cc69dc3eccf5a13bbeed

https://qiita.com/HAYASHI-Masayuki/items/5f0c1ed2137250acecf1

https://shukapin.com/infographicIT/origin-policy

https://zenn.dev/syo_yamamoto/articles/445ce152f05b02

https://developer.mozilla.org/ja/docs/Web/Security/Same-origin_policy

https://tech-tech.blog/security/same_origin_policy/