1. 序論
~UAは，無数の作者により作成された内容とヤリトリする。 それらのほとんどは善意によるものだが、中には悪意的なものもあるかもしれない。 ~UAの実装者は、~UAが処理する内容に基づいて動作を請負うまでの範囲内で，悪意的な作者が他の内容の, あるいは~serverの, 機密性（ `confidentiality^en ）や完全性（ `integrity^en 【`完全性^_】 ）を侵害する能を，制約したいと望むであろう。 ◎ User agents interact with content created by a large number of authors. Although many of those authors are well-meaning, some authors might be malicious. To the extent that user agents undertake actions based on content they process, user agent implementors might wish to restrict the ability of malicious authors to disrupt the confidentiality or integrity of other content or servers.
例として、様々な~serverから検索取得される~HTML内容を具現化する，~HTTP~UAを考える。 ~UAの実装者は、~UAがそれらの文書に包含されている~scriptを実行する際に、悪意的な~serverから検索取得された~scriptが，（例えば~firewallの背後にある）正直な~serverに格納されている文書を読取れないようにしたいと望むであろう。 ◎ As an example, consider an HTTP user agent that renders HTML content retrieved from various servers. If the user agent executes scripts contained in those documents, the user agent implementor might wish to prevent scripts retrieved from a malicious server from reading documents stored on an honest server, which might, for example, be behind a firewall.
伝統的に，~UAは内容をその “生成元” に則って分け隔ててきた。 より特定的には、~UAは，同じ生成元から検索取得された 2 つの内容がヤリトリするのは自由に許容する一方で、異なる生成元から検索取得された 2 つの内容がヤリトリする方法については制約する。 ◎ Traditionally, user agents have divided content according to its "origin". More specifically, user agents allow content retrieved from one origin to interact freely with other content retrieved from that origin, but user agents restrict how that content can interact with content from another origin.
この文書は、いわゆる同一-生成元~施策の背後にある原理について，および生成元を比較する／直列化するための “基礎部品” について述べる。 この文書は、同一-生成元~施策のすべての側面fを述べるものではない。 そういった詳細は，~appに特有なことが多く、~HTML `HTML$r や WebSockets `RFC6455$r などの，他の仕様に委ねられる。 ◎ This document describes the principles behind the so-called same- origin policy as well as the "nuts and bolts" of comparing and serializing origins. This document does not describe all the facets of the same-origin policy, the details of which are left to other specifications, such as HTML [HTML] and WebSockets [RFC6455], because the details are often application-specific.
2. 表記規約
【この訳に特有な表記規約】
◎表記記号2.1. 適合性の判定基準
この文書~内の~keyword "MUST" … 【以下、この段落の内容は~IETF日本語訳 共通~pageに移譲。】 ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
【 以下、この節の他の内容は ~IETF日本語訳 共通~pageに移譲。 】
2.2. 構文の表記法
この仕様は `RFC5234$r による ABNF （ `Augmented Backus Naur Form^en ）記法を利用する。 ◎ This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].
中核~規則［ `SP^P（ `space^en ）, `HTAB^P, `CRLF^P ］は、 RFC 5234, Appendix B.1 による定義を参照する。 ◎ The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US- ASCII character), VCHAR (any visible US-ASCII character), and WSP (whitespace).
`OWS^P 規則は、0 個以上の空白~octetが~~連続して現れ得る所に利用される。 【以下、この段落の内容は，次の一文に集約する：】 `OWS^P は、 ~HTTPの規約に則って取扱うとする。 ◎ The OWS rule is used where zero or more linear whitespace octets might appear. OWS SHOULD either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content SHOULD either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting the field value or forwarding the message downstream. ◎
OWS = *( SP / HTAB / obs-fold ) ; "optional" whitespace obs-fold = CRLF ( SP / HTAB ) ; obsolete line folding
2.3. 各種用語
語 “~UA”, “~server” は、 ~HTTP仕様によるそれと同じ意味を表すとする。 【！ 未利用：~client／~proxy／生成元~server】 ◎ The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification ([RFC2616], Section 1.3).
`~GUID@ （ `globally unique identifier^en, “大域的に一意な識別子” ）は、他のどの既存の値とも異なる値である。 十分長い~randomな文字列は，ほぼ確実に~GUIDになる。 `If the origin value never leaves the user agent,^en 【~UAが生成元の値を決して忘れないのであれば？】、 ~UAに局所的な単調増加する~counterでも，~GUIDとして~~働ける。 ◎ A globally unique identifier is a value that is different from all other previously existing values. For example, a sufficiently long random string is likely to be a globally unique identifier. If the origin value never leaves the user agent, a monotonically increasing counter local to the user agent can also serve as a globally unique identifier.
3. 同一-生成元~施策の原理
多くの~UAは、~remote主体に成り代わって動作を請負う。 例えば、~HTTP~UAは，~remote~serverから~~指示される~redirectに追従し、 ~HTML~UAは，~remote~serverから検索取得された~scriptに, 文書~obj~model（ DOM ）~interfaceを公開する。 ◎ Many user agents undertake actions on behalf of remote parties. For example, HTTP user agents follow redirects, which are instructions from remote servers, and HTML user agents expose rich Document Object Model (DOM) interfaces to scripts retrieved from remote servers.
~security~modelがなければ、~UAは，利用者その他の主体にとって有害な動作も請負うかもしれない。 年月と伴に，~webに関係する多くの技術は、通称 “同一-生成元~施策” として知られている，共通な~security~modelに収束してきた。 この 同一-生成元~施策による~security~modelは、広く組織的に発展してきたものだが，一握りの~~主要な概念から理解できる。 この節では、その概念を示し，それを~secureに利用する方法についての助言を提示する。 ◎ Without any security model, user agents might undertake actions detrimental to the user or to other parties. Over time, many web- related technologies have converged towards a common security model, known colloquially as the "same-origin policy". Although this security model evolved largely organically, the same-origin policy can be understood in terms of a handful of key concepts. This section presents those concepts and provides advice about how to use these concepts securely.
3.1. 信頼関係
同一-生成元~施策は~URIにより，信頼関係を指定する。 例えば~HTML文書は、どの~scriptを走らすかを~URIで指名する： ◎ The same-origin policy specifies trust by URI. For example, HTML documents designate which script to run with a URI:
<script src="https://example.com/library.js"></script>
【 指名- — designate ： “~~指定” の対訳が普通だが、 “選定して~~役割をあてがう” 含みも込めて。 この和訳では（この段落に限らず — やや見慣れない表現になる箇所もあるが）、 “`specify^en” を~~意味する~~指定との区別を優先させる。 】
~UAがこの~protocol要素を処理する際には、~UAは指名された~URIの~scriptを検索取得し，文書が有する特権の下で~scriptを実行することになる。 このようにして，文書は、自身が有するすべての特権を~URIにより指名された資源に是認する。 本質的には、文書は，その~URIから検索取得された情報の完全性を信用することを宣言している。 ◎ When a user agent processes this element, the user agent will fetch the script at the designated URI and execute the script with the privileges of the document. In this way, the document grants all the privileges it has to the resource designated by the URI. In essence, the document declares that it trusts the integrity of information retrieved from that URI.
~URIからの【~scriptなどの】~libraryを取込むことに加えて、~UAはまた，~URIにより指名された~remote主体へ向けて情報を送信する。 例えば~HTMLの `form^e 要素を考える： ◎ In addition to importing libraries from URIs, user agents also send information to remote parties designated by URI. For example, consider the HTML form element:
<form method="POST" action="https://example.com/login"> ... <input type="password"> ... </form>
利用者が自身の~passwordを手入力して~formを提出するとき、~UAは，その~URIにより指名された~network端点へ向けて~passwordを送信する。 このようにして、文書は，自身の秘匿~dataをその~URIに開示する。 すなわち、その~URIへ向けて送信される情報の機密性を信用することを宣言する。 ◎ When the user enters his or her password and submits the form, the user agent sends the password to the network endpoint designated by the URI. In this way, the document exports its secret data to that URI, in essence declaring that it trusts the confidentiality of information sent to that URI.
3.1.1. 陥穽
同一-生成元~施策を利用する新たな~protocolを設計する際には、重要な信用の区別が~URIにおいて必ず可視になるようにする必要がある。 例えば，~TLS（ `Transport Layer Security^en ）で保護される資源とそうでない資源がともに "`http^sc" ~URI~schemeを利用した場合（ `RFC2817$r のように）、文書は，［ ~TLS越しに限り，~scriptを検索取得したいと望む ］ことを指定できなくなる。 "`https^sc" ~URI~schemeを利用することにより、文書は，~network攻撃者から保護された資源とヤリトリしたいと望むことを指示できるようになる。 ◎ When designing new protocols that use the same-origin policy, make sure that important trust distinctions are visible in URIs. For example, if both Transport Layer Security (TLS) and non-TLS protected resources use the "http" URI scheme (as in [RFC2817]), a document would be unable to specify that it wishes to retrieve a script only over TLS. By using the "https" URI scheme, documents are able to indicate that they wish to interact with resources that are protected from active network attackers.
3.2. 生成元（ `origin^en ）
原理的には、~UAがどの~URIも別々な保護~domainとして扱って，ある~URIから検索取得された内容と 別の~URIとのヤリトリに，明示的な同意を要するようにすることもできる。 あいにく、~web~appは，~~協同して動作するいくつもの資源からなることが多いので、この設計は開発者には厄介なものになる。 ◎ In principle, user agents could treat every URI as a separate protection domain and require explicit consent for content retrieved from one URI to interact with another URI. Unfortunately, this design is cumbersome for developers because web applications often consist of a number of resources acting in concert.
代案として，~UAは、~URIたちを， “生成元” と呼ばれる保護~domainにひとまとめにする。 大雑把に言えば、 2 つの~URIは，それらが同じ［~scheme, ~host, ~port］を持つならば，同じ生成元に属する（すなわち，同じ首体を表現する）。 （全部的な詳細は § 4 を見よ。） ◎ Instead, user agents group URIs together into protection domains called "origins". Roughly speaking, two URIs are part of the same origin (i.e., represent the same principal) if they have the same scheme, host, and port. (See Section 4 for full details.)
Q： 単に~host名だけで十分ではありませんか？ ◎ Q: Why not just use the host?
A： 生成元に~schemeも含めることは、~securityにとって本質的です。 ~UAが~schemeを含めなかったなら、 `http://example.com^s と `https://example.com^s は同じ~hostを持つことになり，隔離されなくなります。 しかしながら，この隔離がなければ、能動的な~network攻撃者は， 【 ~TLSなどにより保護されない，】 `http://example.com^s から検索取得される内容に細工を施すことにより，その内容から `https://example.com^s から検索取得される内容の機密性と完全性を弱体化させる~~指示を~UAに出せてしまいます。 その結果、~TLS `RFC5246$r に備わる保護は迂回されてしまいます。 ◎ A: Including the scheme in the origin tuple is essential for security. If user agents did not include the scheme, there would be no isolation between http://example.com and https://example.com because the two have the same host. However, without this isolation, an active network attacker could corrupt content retrieved from http://example.com and have that content instruct the user agent to compromise the confidentiality and integrity of content retrieved from https://example.com, bypassing the protections afforded by TLS [RFC5246].
Q： なぜ、単に “~top-levelの” ~domainではなく，完全修飾~host名を利用するのですか？ ◎ Q: Why use the fully qualified host name instead of just the "top-level" domain?
A： ~DNSは階層的な委任を備えていますが、~host名の間の信頼関係は、配備状況により様々です。 例えば，多くの教育機関では、学生たちは `https://example.edu/~student/^s の下に内容を~hostできますが、一学生が作成した文書と `https://grades.example.edu/^s の下に~hostされている成績管理用の~web~appとが，同じ生成元に属する（すなわち，同じ保護~domain下にある）ことになるべきではないでしょう。 ◎ A: Although the DNS has hierarchical delegation, the trust relationships between host names vary by deployment. For example, at many educational institutions, students can host content at https://example.edu/~student/, but that does not mean a document authored by a student should be part of the same origin (i.e., inhabit the same protection domain) as a web application for managing grades hosted at https://grades.example.edu/.
`example.edu^s の配備~例は、生成元による資源の仕分けが，どの配備状況にも常に完璧に沿えるわけでないことを示してもいます。 この配備の場合，どの学生の~web~siteも同じ生成元に属しており、望ましくないかもしれません。 あるイミ、生成元の粒度は，~security~modelが発展する~~過程で生じた歴史的な歪みです。 ◎ The example.edu deployment illustrates that grouping resources by origin does not always align perfectly with every deployment scenario. In this deployment, every student's web site inhabits the same origin, which might not be desirable. In some sense, the origin granularity is a historical artifact of how the security model evolved.
3.2.1. 例
次の資源の生成元はどれも同じである： ◎ All of the following resources have the same origin:
http://example.com/ http://example.com:80/ http://example.com/path/file
各~URIの［ ~scheme, ~host, ~port ］各~成分とも，互いに同じである。 【 `http^sc ~schemeの既定の~port番号は 80 と定められている。】 ◎ Each of the URIs has the same scheme, host, and port components.
次に挙げる各~資源の生成元は、どれも互いに異なる： ◎ Each of the following resources has a different origin from the others.
http://example.com/ http://example.com:8080/ http://www.example.com/ https://example.com:80/ https://example.com/ http://example.org/ http://ietf.org/
どれも、少なくとも［ ~scheme, ~host, ~port ］いずれかの成分は、他のものと異なっている。 ◎ In each case, at least one of the scheme, host, and port component will differ from the others in the list.
3.3. 権限
~UAは~URIを生成元により仕分けるが、同じ生成元に属するどの資源も同じ権限（ “authority” — `RFC3986$r によるイミの “`authority^en”† ではなく，~securityのイミで）を有するとは限らない。 例えば，画像は受動的な内容なので、何ら権限を有さない††。 すなわち，画像は、その生成元にて可用な~objや資源へ~accessすることはない。 対して、~HTML文書は，その生成元に対する全-権限を有し、その文書~内の（またはその中に取込まれた）~scriptは，その生成元に属するどの資源にも~accessし得る。 ◎ Although user agents group URIs into origins, not every resource in an origin carries the same authority (in the security sense of the word "authority", not in the [RFC3986] sense). For example, an image is passive content and, therefore, carries no authority, meaning the image has no access to the objects and resources available to its origin. By contrast, an HTML document carries the full authority of its origin, and scripts within (or imported into) the document can access every resource in its origin.
【† ~URI構文の一部を成す `authority^P 】【†† 同じ画像でも， SVG のような~HTMLと同程度に高機能になり得る画像は、通常の画像と同程度に低~riskなものと見なすためには，その能動的な部分の機能を制約する必要があることになる。 】
~UAは，資源の~MIME型（ `Internet media type^en ）を精査することにより、資源に是認する権限の度合いを決定する。 例えば、~MIME型 `image/png^s の資源は画像として扱われ，~MIME型 `text/html^s の資源は~HTML文書として扱われる。 ◎ User agents determine how much authority to grant a resource by examining its media type. For example, resources with a media type of image/png are treated as images, and resources with a media type of text/html are treated as HTML documents.
~web~appは、信用できない内容（利用者により生成された内容など）を~hostする際に、その~MIME型を制約することにより，内容の権限を制限できる。 例えば、利用者により生成された内容を `image/png^s として~serveする~riskは， `text/html^s として~serveするより小さい。 無論、多くの~web~appは，信用できない内容を自身の~HTML文書に組入れるが、注意深く行わなければ，~appは 自身の生成元の権限を信用できない内容に漏洩する~riskにさらすことになる。 これは、~XSS（ `cross-site scripting^en ）として共通的に知られている脆弱性である。 ◎ When hosting untrusted content (such as user-generated content), web applications can limit that content's authority by restricting its media type. For example, serving user-generated content as image/png is less risky than serving user-generated content as text/html. Of course, many web applications incorporate untrusted content in their HTML documents. If not done carefully, these applications risk leaking their origin's authority to the untrusted content, a vulnerability commonly known as cross-site scripting.
3.3.1. 陥穽
~web~platformの新たな部品を設計する際には、その~MIME型が何であれ，その部品を~serveする資源に権限を是認しないよう気を付けるべきである。 多くの~web~appは、信用できない内容を，限られた~MIME型に制約して~serveする。 これらの内容の部品に権限を是認するような，~web~platformの新たな特能は、既存の~appに脆弱性を導入する~riskがある。 代わりに、［ すでに生成元に対する全-権限を有する~MIME型か，または 新たな権限を有するように特定的に設計された 新たな~MIME型 ］に是認する方を選好すること。 ◎ When designing new pieces of the web platform, be careful not to grant authority to resources irrespective of media type. Many web applications serve untrusted content with restricted media types. A new web platform feature that grants authority to these pieces of content risks introducing vulnerabilities into existing applications. Instead, prefer to grant authority to media types that already possess the origin's full authority or to new media types designed specifically to carry the new authority.
一部の~UAは、【~HTTP~headerを通して】不正な~MIME型を~serveする~serverと互換であり続けるために， “`content sniffing^en （~~内容型の~~推定）” `SNIFF$r を使役し、その内容を，~serverから給される~MIME型と異なる~MIME型を持つかのように扱うことがある。 `content sniffing^en は、注意深く行われなければ，~securityの脆弱性が導かれ得る。 なぜなら、~UAは画像などの低~権限の~MIME型に，~HTML文書などの高~権限の~MIME型の特権を是認することにもなりかねないからである。 ◎ In order to remain compatible with servers that supply incorrect media types, some user agents employ "content sniffing" and treat content as if it had a different media type than the media type supplied by the server. If not done carefully, content sniffing can lead to security vulnerabilities because user agents might grant low-authority media types, such as images, the privileges of high-authority media types, such as HTML documents [SNIFF].
3.4. 施策
一般に、~UAは異なる生成元を隔離しつつ，生成元どうしの通信は制御された形で許可する。 ~UAが隔離と通信をどのような形で供するかについての詳細は、いくつかの要因に依存して様々になる。 ◎ Generally speaking, user agents isolate different origins and permit controlled communication between origins. The details of how user agents provide isolation and communication vary depending on several factors.
3.4.1. ~obj~access
~UAから公開されるほとんどの~obj（ `application programming interfaces^en，略して~APIとも呼ばれる）は、同じ生成元に属する場合に限り可用になる。 特定的には、［ ある~URIから検索取得された内容 ］が［ 別の~URIから検索取得された内容に結付けられた~obj ］に~accessし得るのは， 2 つの~URIが同じ生成元に属するとき — すなわち，互いの［ ~scheme, ~host, ~port ］がどれも同じとき — そのときに限られる。 ◎ Most objects (also known as application programming interfaces or APIs) exposed by the user agent are available only to the same origin. Specifically, content retrieved from one URI can access objects associated with content retrieved from another URI if, and only if, the two URIs belong to the same origin, e.g., have the same scheme, host, and port.
この一般~規則には一部~例外がある。 例えば、~HTMLの `Location^c ~interfaceの一部は、生成元を超えて可用になる（例えば、他の閲覧~文脈（ `browsing context^en ）を~navigateするのを許容するため）。 別の例として、~HTMLの `postMessage^c ~interfaceは、異なる生成元 間（ `cross-origin^en ）の通信を手助けするために，生成元を超えて明示的に可視にされている。 外来な生成元に~objを公開するのは、攻撃者がそこに居れば彼らにも~objを公開するので危険であり，細心な注意の下で行われるべきである。 ◎ There are some exceptions to this general rule. For example, some parts of HTML's Location interface are available across origins (e.g., to allow for navigating other browsing contexts). As another example, HTML's postMessage interface is visible across origins explicitly to facilitate cross-origin communication. Exposing objects to foreign origins is dangerous and should be done only with great care because doing so exposes these objects to potential attackers.
3.4.2. ~network~access
~network資源への~accessの可否は、［ その資源は、~accessを試みている内容と同じ生成元に属しているかどうか ］に依存する。 ◎ Access to network resources varies depending on whether the resources are in the same origin as the content attempting to access them.
一般に、別の生成元から情報を読取ることは禁止される。 しかしながら，一部の種類の資源を利用することは、他の生成元から検索取得する場合でも許可される。 例えば生成元には、どの生成元からの［ ~scriptを実行する／画像を描画する／~stylesheetを適用する ］ことも許可されている 【この文書が書かれた頃までは — 現在はもっと制約されている】 。 同様に生成元は、~HTMLの~frame内の~HTML文書など，別の生成元からの内容を表示できる。 ~network資源には、他の生成元に自身の情報を読取らせる~opt-inを備えるものもある — 例えば `Cross-Origin Resource Sharing^en `CORS$r を利用して。 これらの事例で~accessが是認されるかどうかは、概して生成元ごとに基づく。 ◎ Generally, reading information from another origin is forbidden. However, an origin is permitted to use some kinds of resources retrieved from other origins. For example, an origin is permitted to execute script, render images, and apply style sheets from any origin. Likewise, an origin can display content from another origin, such as an HTML document in an HTML frame. Network resources can also opt into letting other origins read their information, for example, using Cross-Origin Resource Sharing [CORS]. In these cases, access is typically granted on a per-origin basis.
別の生成元へ情報を送信することは許可されている。 しかしながら、任意な形式による，~network越しの情報の送信は危険である。 この理由から，~UAは、文書による情報の送信を，特定0の~protocol — ~custom~headerが無い~HTTP要請など — の利用-時に限るように制約している。 許容される~protocolの集合を拡大することは — 例えば、 WebSockets `RFC6455$r 用の~supportを追加するなど — 脆弱性が導入されないよう，注意深く行われなければならない。 ◎ Sending information to another origin is permitted. However, sending information over the network in arbitrary formats is dangerous. For this reason, user agents restrict documents to sending information using particular protocols, such as in an HTTP request without custom headers. Expanding the set of allowed protocols, for example, by adding support for WebSockets, must be done carefully to avoid introducing vulnerabilities [RFC6455].
3.4.3. 陥穽
~UAが，異なる生成元に属する資源~間でヤリトリを許容することは、~securityの課題を招く。 例えば、別の生成元からの画像を表示する能は，その縦幅や横幅を漏洩する。 同様に、別の生成元へ~network要請を送信する能は， CSRF `CSRF$r （ `cross-site request forgery^en — ~site（生成元）をまたがる要請の偽造）の脆弱性をもたらし得る。 しかしながら、~UAの実装者は，これらの~riskと, 異なる生成元~間（ `cross-origin^en ）のヤリトリを許容することで得られる便益との兼合いをとることが多い。 例えば，~HTML~UAが 異なる生成元 間の~network要請を阻止すれば、利用者は，~webの中核を成す特能である~hyperlinkを追えなくなってしまう。 ◎ Whenever user agents allow one origin to interact with resources from another origin, they invite security issues. For example, the ability to display images from another origin leaks their height and width. Similarly, the ability to send network requests to another origin gives rise to cross-site request forgery vulnerabilities [CSRF]. However, user agent implementors often balance these risks against the benefits of allowing the cross-origin interaction. For example, an HTML user agent that blocked cross-origin network requests would prevent its users from following hyperlinks, a core feature of the web.
~web~platformに新たな機能性を付け加える際には、一方の資源に特権を是認しつつ，同じ生成元に属する別の資源に対してはその特権を差止めれば良さそうに見える。 しかしながら、このような方法で特権を差止めても，~UAは 同じ生成元に属する資源を隔離しないので、特権のない資源も 結局は通例的に特権を得ることになり，効果的でない。 代わりに，特権は、（生成元に属する個々の資源ごとに~~区分するのでなく）一つの生成元に総体として是認するか差止めるべきである `BOFGO$r 。 ◎ When adding new functionality to the web platform, it can be tempting to grant a privilege to one resource but to withhold that privilege from another resource in the same origin. However, withholding privileges in this way is ineffective because the resource without the privilege can usually obtain the privilege anyway because user agents do not isolate resources within an origin. Instead, privileges should be granted or withheld from origins as a whole (rather than discriminating between individual resources within an origin) [BOFGO].
3.5. ~~要約
同一-生成元~施策は、~URIを利用して信頼関係を指名する。 各~URIは生成元ごとにまとめられ，保護~domainを表現する。 生成元に属する一部の資源（例えば，能動的な内容）には，その生成元の全-権限が是認される一方で、生成元に属する他の資源（例えば，受動的な内容）には，生成元の権限は是認されない。 その生成元の権限を有する内容は、自身の生成元に属する［ ~obj／~network資源 ］への~accessが是認される。 この内容には，他の生成元に属する［ ~obj／~network資源 ］への制限された~accessも是認されるが、そのような非同一-生成元 特権は，~security脆弱性を避けるように注意深く設計されなければならない。 ◎ The same-origin policy uses URIs to designate trust relationships. URIs are grouped together into origins, which represent protection domains. Some resources in an origin (e.g., active content) are granted the origin's full authority, whereas other resources in the origin (e.g., passive content) are not granted the origin's authority. Content that carries its origin's authority is granted access to objects and network resources within its own origin. This content is also granted limited access to objects and network resources of other origins, but these cross-origin privileges must be designed carefully to avoid security vulnerabilities.
4. ~URIの生成元
所与の~URI %~URI の生成元は、次の~algoにより算出される： ◎ The origin of a URI is the value computed by the following algorithm:
-
~IF［ %~URI は命名機関（ `naming authority^en ）として階層的な~protocol要素を利用していない（ RFC3986 § 3.2 を見よ） ］~OR［ %~URI は絶対~URIでない ］ ⇒ ~RET 新規に生成される`~GUID$ ◎ 1. If the URI does not use a hierarchical element as a naming authority (see [RFC3986], Section 3.2) or if the URI is not an absolute URI, then generate a fresh globally unique identifier and return that value.
注記： この~algoは、同じ~URIに対し複数回~走らせた場合，回ごとに異なる値を生成し得る。 概して，~UAは、例えば~HTML文書の生成元をそれぞれの~security検査ごとに算出し直すのでなく，一度だけ算出して、後続な~security検査にその生成元を利用する。 ◎ NOTE: Running this algorithm multiple times for the same URI can produce different values each time. Typically, user agents compute the origin of, for example, an HTML document once and use that origin for subsequent security checks rather than recomputing the origin for each security check.
- %uri-scheme ~LET %~URI の~scheme成分を小文字~化した結果 ◎ 2. Let uri-scheme be the scheme component of the URI, converted to lowercase.
- ~IF［ 実装は %uri-scheme で与えられる~protocolを~supportしない ］ ⇒ ~RET 新規に生成される`~GUID$ ◎ 3. If the implementation doesn't support the protocol given by uri- scheme, then generate a fresh globally unique identifier and return that value.
-
~IF［ %uri-scheme ~EQ "`file^sc" ］ ⇒ 実装は自身が定義する値を返してヨイ ◎ 4. If uri-scheme is "file", the implementation MAY return an implementation-defined value.
注記： 歴史的に、~UAは `file^sc ~schemeからの内容に過大な特権を是認してきた。 しかしながら、すべての局所~fileにそのような広範な特権を是認することは、段階的な特権の拡大~攻撃につながるおそれがある。 局所~file~directoryに基づいて特権を是認することにより成功を得た~UAも中にはあるが、この~approachは広く採用されてはいない。 別の~UAは各 "`file^sc" ~URIごとに`~GUID$をあてがう。 これは、最も~secureな選択肢である。 ◎ NOTE: Historically, user agents have granted content from the file scheme a tremendous amount of privilege. However, granting all local files such wide privileges can lead to privilege escalation attacks. Some user agents have had success granting local files directory-based privileges, but this approach has not been widely adopted. Other user agents use globally unique identifiers for each file URI, which is the most secure option.
-
%uri-host ~LET %~URI の~host成分を（ `RFC4790$r にて定義される i;ascii-casemap 照合を利用して）小文字~化した結果 ◎ 5. Let uri-host be the host component of the URI, converted to lower case (using the i;ascii-casemap collation defined in [RFC4790]).
注記： この文書は、~UAが~URIを構築するにあたり，~IDNA（ `Internationalized Domain Names in Applications^en — ~appにおける国際-化~domain名）の処理と妥当性検証を遂行するものと見做している。 特に，この文書は、 %uri-host が LDH ~labelのみを包含するものと見做している — ~UAはどの非~ASCII~labelも，対応する A-label に変換-済みにすることになるので（ `RFC5890$r を見よ）。 この理由から、生成元に基づく~security施策は， ~UAに使役されている~IDNA~algoに敏感である。 更なる論点は § 8.4 に。 ◎ NOTE: This document assumes that the user agent performs Internationalizing Domain Names in Applications (IDNA) processing and validation when constructing the URI. In particular, this document assumes the uri-host will contain only LDH labels because the user agent will have already converted any non-ASCII labels to their corresponding A-labels (see [RFC5890]). For this reason, origin-based security policies are sensitive to the IDNA algorithm employed by the user agent. See Section 8.4 for further discussion.
- %uri-port ~LET %~URI に~port成分が［ 在るならば それ【が表現する整数】 ／ 無いならば［ %uri-scheme で与えられる~protocol ］の既定~port ］ ◎ 6. If there is no port component of the URI: • 1. Let uri-port be the default port for the protocol given by uri-scheme. Otherwise: • Let uri-port be the port component of the URI.
- ~RET ( %uri-scheme, %uri-host, %uri-port ) ◎ 7. Return the triple (uri-scheme, uri-host, uri-port).
5. 生成元の比較-法
2 つの生成元が “同じ” であるとは、それらが一致することを言う。 特に： ◎ Two origins are "the same" if, and only if, they are identical. In particular:
- 2 つの生成元とも ~scheme/~host/~port の~tripleであるならば、 2 つの生成元の［ ~scheme, ~host, ~port ］がそれぞれ一致するとき, そのときに限り，同じとされる。 ◎ If the two origins are scheme/host/port triples, the two origins are the same if, and only if, they have identical schemes, hosts, and ports.
- `~GUID$である生成元は、~scheme/~host/~port の~tripleと同じ生成元にはなり得ない。 ◎ An origin that is a globally unique identifier cannot be the same as an origin that is a scheme/host/port triple.
2 つの~URIは、互いの生成元が同じであるとき， “同一-生成元（ `same origin^en ）” と呼ばれる。 ◎ Two URIs are same-origin if their origins are the same.
注記： ~URIは、自身と同じ生成元になるとは限らない。 例えば， `data^sc ~URI `RFC2397$r は、~serverに基づく命名機関を利用しないので，`~GUID$を生成元として持ち、その生成元は自身と同じにならない。 【~URIから生成元を算出する度に，異なる~GUIDが返される。】 ◎ NOTE: A URI is not necessarily same-origin with itself. For example, a data URI [RFC2397] is not same-origin with itself because data URIs do not use a server-based naming authority and therefore have globally unique identifiers as origins.
【 ~HTMLが定義する~triple生成元 には， “~domain” 成分も追加されているが、それは，~HTMLに特有な処理~modelに起因するものでもある。 】
6. 生成元の直列化-法
この節では、生成元を~Unicode `Unicode6$r 文字列に直列化する方法, および~ASCII `RFC20$r 文字列に直列化する方法を定義する。 ◎ This section defines how to serialize an origin to a unicode [Unicode6] string and to an ASCII [RFC20] string.
6.1. 生成元の~Unicode直列化
所与の生成元 %生成元 の~Unicode直列化とは、次の~algoが返す値である： ◎ The unicode-serialization of an origin is the value returned by the following algorithm:
-
~IF［ %生成元 は ~scheme/~host/~port の~tripleである ］：
- %生成元 ~LET 生成元の複製；
- %生成元 の~host部位 ~SET %生成元 の~host部位を［ それを成す各~成分のうち， A-label を与えるもの ］を対応する U-label に~~置換した結果
- ~RET %生成元 の~ASCII直列化（次節） 【この訳では、~ASCII直列化を利用して，原文の記述を簡略化する】 ◎ 1. If the origin is not a scheme/host/port triple, then return the string null (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps. ◎ 2. Otherwise, let result be the scheme part of the origin triple. ◎ 3. Append the string "://" to result. ◎ 4. Append each component of the host part of the origin triple (converted as follows) to the result, separated by U+002E FULL STOP code points ("."): • 1. If the component is an A-label, use the corresponding U-label instead (see [RFC5890] and [RFC5891]). • 2. Otherwise, use the component verbatim. ◎ 5. If the port part of the origin triple is different from the default port for the protocol given by the scheme part of the origin triple: • 1. Append a U+003A COLON code point (":") and the given port, in base ten, to result. ◎ 6. Return result.
6.2. 生成元の~ASCII直列化
所与の生成元 %生成元 の~ASCII直列化とは、次の~algoが返す値である： ◎ The ascii-serialization of an origin is the value returned by the following algorithm:
- ~IF［ %生成元 は ~scheme/~host/~port の~tripleでない ］ ⇒ ~RET 文字列 `null^c （すなわち，符号位置~並び `006E^U, `0075^U, `006C^U, `006C^U ） ◎ 1. If the origin is not a scheme/host/port triple, then return the string null (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.
- ( %~scheme, %~host, %~port ) ~LET %生成元 の ( ~scheme, ~host, ~port ) 部位 ◎ ↓
- %結果 ~LET %~scheme ◎ 2. Otherwise, let result be the scheme part of the origin triple.
- %結果 に［ 文字列 "`://^c" ］を付加する ◎ 3. Append the string "://" to result.
- %結果 に %~host を付加する ◎ 4. Append the host part of the origin triple to result.
- ~IF［ %~port は %~scheme で与えられる~protocol用の既定~portでない ］ ⇒ %結果 に次を順に付加する ⇒＃ 符号位置 `003A^U COLON（ "`:^c" ）, %~port の十進表記 ◎ 5. If the port part of the origin triple is different from the default port for the protocol given by the scheme part of the origin triple: • 1. Append a U+003A COLON code point (":") and the given port, in base ten, to result.
- ~RET %結果 ◎ 2. Return result.
7. ~HTTP `Origin^h ~header
この節では、 ~HTTP `Origin^h ~headerを定義する。 ◎ This section defines the HTTP Origin header field.
7.1. 構文
`Origin^h ~headerの構文は、次で与えられる： ◎ The Origin header field has the following syntax:
origin = "Origin:" OWS origin-list-or-null OWS origin-list-or-null = `%x6E %x75 %x6C %x6C^_ / origin-list origin-list = serialized-origin *( SP serialized-origin ) serialized-origin = scheme "://" host [ ":" port ]
`scheme^P, `host^P, `port^P は `RFC3986$r に定義される。 ◎ ; <scheme>, <host>, <port> from RFC 3986
【 この構文では，~header値は複数個の生成元を含み得るが、現在の~web~platformでは，1 個に限るように制約されている。 したがって、以下の § 7.2, § 7.3 の記述も，実質的には もっと単純になるであろう。 】
7.2. 意味論
~HTTP要請に含められる `Origin^h ~headerは、~UAに要請を発行- “させる” よう（~UAが~~供する~APIの定義に従って）誘発した生成元（たち）を指示する。 ◎ When included in an HTTP request, the Origin header field indicates the origin(s) that "caused" the user agent to issue the request, as defined by the API that triggered the user agent to issue the request.
例えば、ある生成元（たち）に利する~scriptを実行する~UAを考える。 そのような~scriptが，~UAに~HTTP要請を発行させたときは、~UAは `Origin^h ~headerを利用して，~scriptを実行している~security文脈を~serverに伝えてもヨイ。 ◎ For example, consider a user agent that executes scripts on behalf of origins. If one of those scripts causes the user agent to issue an HTTP request, the user agent MAY use the Origin header field to inform the server of the security context in which the script was executing when it caused the user agent to issue the request.
事例によっては、複数の生成元が寄与して，~UAに~HTTP要請を発行させることもある。 そのような事例では、~UAは `Origin^h ~header内にそれらの生成元すべてを~listしてもヨイ†。 例えば、初期~時は ある生成元により~HTTP要請が発行されていて，後で別の生成元により~redirectされた場合、~UAは，自身に要請を発行させた生成元が 2 つ孕まれていることを~serverに伝えてもヨイ。 【† 次節最後の要件も考慮するなら，寄与した順序も有意とされるかもしれない。】 ◎ In some cases, a number of origins contribute to causing the user agents to issue an HTTP request. In those cases, the user agent MAY list all the origins in the Origin header field. For example, if the HTTP request was initially issued by one origin but then later redirected by another origin, the user agent MAY inform the server that two origins were involved in causing the user agent to issue the request.
7.3. ~UAに課される要件
~UAはどの~HTTP要請にも， `Origin^h ~headerを含めてもヨイ。 ◎ The user agent MAY include an Origin header field in any HTTP request.
~UAはどの~HTTP要請にも，複数個の `Origin^h ~headerを含めてはナラナイ。 ◎ The user agent MUST NOT include more than one Origin header field in any HTTP request.
~UAが “~privacyに敏感な” 文脈の下から~HTTP要請を発行するときは，常に、 `Origin^h ~headerに値 “`null^c” を送信しなければナラナイ。 ◎ Whenever a user agent issues an HTTP request from a "privacy- sensitive" context, the user agent MUST send the value "null" in the Origin header field.
注記： この文書は、どのような観念（ `notion^en ）をもって “~privacyに敏感な文脈” とされるかは，定義しない。 ~HTTP要請を生成する~appは、文脈を~privacyに敏感であるものと指名して，~UAが `Origin^h ~headerを生成する方法に制約を課すことができる。 ◎ NOTE: This document does not define the notion of a privacy- sensitive context. Applications that generate HTTP requests can designate contexts as privacy-sensitive to impose restrictions on how user agents generate Origin header fields.
`Origin^h ~headerを生成するときには、~UAは次の要件に従わなければナラナイ。 ◎ When generating an Origin header field, the user agent MUST meet the following requirements:
- その文法~内の `serialized-origin^P 生成規則は、生成元の~ASCII直列化を成していなければナラナイ。 ◎ Each of the serialized-origin productions in the grammar MUST be the ascii-serialization of an origin.
- 連続するどの 2 つの生成結果も，一致することはない。 特に、~UAが【同じ？】生成結果を連続して生成することになる場合、 2 個目を生成してはナラナイ。 ◎ No two consecutive serialized-origin productions in the grammar can be identical. In particular, if the user agent would generate two consecutive serialized-origins, the user agent MUST NOT generate the second one.
8. ~security上の考慮点
同一-生成元~施策は、~web~browserを含む多くの~UAにとり，~securityの根幹を成す一つである。 歴史的に、一部の~UAは `taint tracking^en †や `exfiltration^en ††の防止を含む他の~security~modelを試してきたが、それらの~modelは当時においては，実装が困難であることが判明した（最近になって、これらのうちの一部の~ideaの復活に関心が呼ばれつつあるが）。 ◎ The same-origin policy is one of the cornerstones of security for many user agents, including web browsers. Historically, some user agents tried other security models, including taint tracking and exfiltration prevention, but those models proved difficult to implement at the time (although there has been recent interest in reviving some of these ideas).
【† 外からの（安全でないかもしれない）入力には、何かに “染まっている（ `tainted^en ）” ことを指示する “標識” を付け，追跡する（ `tracking^en ）。 】【†† 内部から外部へ “裏口” から~dataを転送する。 】
同一-生成元~施策の~securityについての~~評価は、生成元の概念~自体が~security~~全般における中心的な役割を占めているため，【他との比較は】困難である。 生成元は、観念としては，単なる隔離単位でしかなく，万能ではない。 それには、以下に論じられる，ある種の体系的な弱点がある。 ◎ Evaluating the security of the same-origin policy is difficult because the origin concept itself plays such a central role in the security landscape. The notional origin itself is just a unit of isolation, imperfect as are most one-size-fits-all notions. That said, there are some systemic weaknesses, discussed below.
8.1. ~DNSへの依拠
実施においては、 `http^sc などの共通的に利用される~URI~schemeの多くは， ~DNS（ `Domain Name System^en ）に基づく命名機関を利用しているので、同一-生成元~施策の~securityは~DNSに依拠することになる。 ~DNSが部分的にでも弱体化された場合、同一-生成元~施策は，~appが要求する~securityの特質を満たせなくなるであろう。 ◎ In practice, the same-origin policy relies upon the Domain Name System (DNS) for security because many commonly used URI schemes, such as http, use DNS-based naming authorities. If the DNS is partially or fully compromised, the same-origin policy might fail to provide the security properties required by applications.
`https^sc など一部の~URI~schemeは、~UAがこれらの~URIから検索取得された内容の~sourceを検証yするために，証明書のような他の仕組みを使役しているので、~DNS汚染に対し，より抵抗力がある。 `chrome-extension^sc ~URI~scheme（ `CRX$r § 4.3 を見よ）などの他の~URI~schemeは、公開鍵に基づく命名機関を利用するものであり，~DNS汚染に対し全部的に~secureである。 ◎ Some URI schemes, such as https, are more resistant to DNS compromise because user agents employ other mechanisms, such as certificates, to verify the source of content retrieved from these URIs. Other URI schemes, such as the chrome-extension URI scheme (see Section 4.3 of [CRX]), use a public-key-based naming authority and are fully secure against DNS compromise.
~web生成元の概念は、異なる~URI~schemeから検索取得された内容を隔離する。 これは、~DNS汚染による効果を一定範囲に封じ込めることに本質的である。 ◎ The web origin concept isolates content retrieved from different URI schemes; this is essential to containing the effects of DNS compromise.
8.2. 隔離単位の分岐
これまで，いくつもの技術が、簡便な隔離単位として，~web生成元の概念に収束してきた。 しかしながら，~cookie `RFC6265$r などの今日用いられる多くの技術が、現代の~web生成元の概念に先行して利用-中にある。 これらの技術における隔離単位は、生成元と異なることが多いため，脆弱性を導いている。 ◎ Over time, a number of technologies have converged on the web origin concept as a convenient unit of isolation. However, many technologies in use today, such as cookies [RFC6265], pre-date the modern web origin concept. These technologies often have different isolation units, leading to vulnerabilities.
代替案として、隔離単位に FQDN（ `fully qualified domain name^en, 完全修飾~domain名 ）ではなく， “登録制（ `registry-controlled^en ）” による~domainのみを利用することも~~考えられるが（例えば "`www.example.com^s" の代わりに "`example.com^s" ）、この実施にはいくつもの理由から問題になり得るため，推奨されない： ◎ One alternative is to use only the "registry-controlled" domain rather than the fully qualified domain name as the unit of isolation (e.g., "example.com" instead of "www.example.com"). This practice is problematic for a number of reasons and is NOT RECOMMENDED:
- “登録制” ~domainは，観念としては、~DNS自身の特質ではなく，~DNSを取り巻く ヒトによる実施として~~機能する ］になる。 例えば、日本における多数の地方自治体の公共~registryは，極めて深い~DNS階層で~~運用されている。 広く利用されている “`public suffix lists^en” があるが、これらの~listを各 実装が揃って最新状態に保つことは困難である。 ◎ 1. The notion of a "registry-controlled" domain is a function of human practice surrounding the DNS rather than a property of the DNS itself. For example, many municipalities in Japan run public registries quite deep in the DNS hierarchy. There are widely used "public suffix lists", but these lists are difficult to keep up to date and vary between implementations.
- この実施は、~DNSに基づく命名機関を利用しない~URI~schemeと互換でない。 例えば，命名機関として公開鍵を利用する~URI~schemeの場合、 “登録制” 公開鍵の観念は，どこかに不整合を~~孕む。 加えて、 `nntp^sc などの一部の~URI~schemeは，委任関係に~DNSとは逆順の~dot区切りを利用しており（例えば `alt.usenet.kooks^s ）、また，~DNSを利用しつつ, 通例とは逆順に~labelを提示するものもある（例えば `com.example.www^s ）。 ◎ 2. This practice is incompatible with URI schemes that do not use a DNS-based naming authority. For example, if a given URI scheme uses public keys as naming authorities, the notion of a "registry-controlled" public key is somewhat incoherent. Worse, some URI schemes, such as nntp, use dotted delegation in the opposite direction from DNS (e.g., alt.usenet.kooks), and others use the DNS but present the labels in the reverse of the usual order (e.g., com.example.www).
“登録制” ~domainを利用することは、良くても~URI~schemeと実装に特有である。 最悪の場合、~URI~schemeと実装との相違点から脆弱性が導かれ得る。 ◎ At best, using "registry-controlled" domains is URI-scheme- and implementation-specific. At worst, differences between URI schemes and implementations can lead to vulnerabilities.
8.3. ~ambient権限
同一-生成元~施策が利用される下では、~UAは内容に対し、その内容がどの~objを指名し得るか ではなく，内容の~URIに基づいて権限を是認する。 この，指名を権限から~~分離することは、~ambient権限の一例であり，脆弱性が導かれ得る。 ◎ When using the same-origin policy, user agents grant authority to content based on its URI rather than based on which objects the content can designate. This disentangling of designation from authority is an example of ambient authority and can lead to vulnerabilities.
【 ~ambient権限 ：環境から暗黙的に与えられる権限 — 参考 】
例えば~HTML文書における~XSSを考える。 もし攻撃者が~HTML文書~内に~script内容を注入できたなら、これらの~scriptは，文書の生成元の権限を有する下で走ることになり、利用者の医療記録など，敏感な情報への~script~accessが許容されてしまうことになる。 しかしながら、~scriptの権限が，~scriptが指名し得る~objに制限されるのであれば、攻撃者が，第三者-主体に~hostされている~HTML文書に~scriptを注入することで優位を得ることもなくなるであろう。 ◎ Consider, for example, cross-site scripting in HTML documents. If an attacker can inject script content into an HTML document, those scripts will run with the authority of the document's origin, perhaps allowing the script access to sensitive information, such as the user's medical records. If, however, the script's authority were limited to those objects that the script could designate, the attacker would not gain any advantage by injecting the script into an HTML document hosted by a third party.
8.4. ~IDNAへの依存とその移行
同一-生成元~施策の~securityの特質は、~UAに使役されている~IDNA~algoの詳細~に不可欠に依存し得る。 特に，一部の国際-化~domain名（例えば `00DF^U 文字を含むもの ）については、~UAが［ IDNA2003 `RFC3490$r, IDNA2008 `RFC5890$r ］のどちらを利用しているかに依存して，異なる~ASCII表現に対応付けられ得る。 ◎ The security properties of the same-origin policy can depend crucially on details of the IDNA algorithm employed by the user agent. In particular, a user agent might map some international domain names (for example, those involving the U+00DF character) to different ASCII representations depending on whether the user agent uses IDNA2003 [RFC3490] or IDNA2008 [RFC5890].
~IDNA~algoを別のものへ移行させることは、いくつかの~security境界を描直すことになり得る： 新たな~security境界を敷いたり，より望ましくない方では，互いに信用できない複数の実体~間の~security境界を取り払ってしまうなど。 特に後者の場合，一方が他方を攻撃することが許容されるので、~security境界を変更することには~riskを伴う。 ◎ Migrating from one IDNA algorithm to another might redraw a number of security boundaries, potentially erecting new security boundaries or, worse, tearing down security boundaries between two mutually distrusting entities. Changing security boundaries is risky because combining two mutually distrusting entities into the same origin might allow one to attack the other.
9. IANA Considerations
恒久的~message~header~registry（ `RFC3864$r を見よ）は、次の登録で更新された： ◎ The permanent message header field registry (see [RFC3864]) has been updated with the following registration:
| ~header名 ◎ Header field name | `Origin^h |
|---|---|
| 適用-可能な~protocol ◎ Applicable protocol | http |
| 位置付け ◎ Status | standard |
| 著作者／変更~制御者 ◎ Author/Change controller | IETF |
| 仕様~文書 ◎ Specification document(s) | この仕様（§ 7） |
Appendix A. 謝辞
この文書への貴重な~feedbackを寄せられた次の方々に： ◎ We would like to thank
Lucas Adamski, Stephen Farrell, Miguel A. Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Jeff Hodges, Collin Jackson, Larry Masinter, Alexey Melnikov, Mark Nottingham, Julian Reschke, Peter Saint-Andre, Jonas Sicking, Sid Stamm, Daniel Veditz, and Chris Weber for their valuable feedback on this document.