Re: [cors] Additional Comments on 17 March 2009 cors draft

One additional question regarding a cross-site get (using browser here  
for simplicity of terms) (for example, see [1])

Is it true that

1. the GET results in the content being returned on the wire with a   
Access-Control-Allow-Origin header
2. the browser then checks this header and enforces policy
3. if policy disallows then the browser does not allow the content to  
be used.

In any case, doesn't this open an attack to get the content by  
sniffing the wire for the response content, regardless of the header?

regards, Frederick

Frederick Hirsch
Nokia

[1] http://arunranga.com/examples/access-control/SimpleXSInvocation.txt

On Jun 30, 2009, at 11:11 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote:

> I have some basic comments and questions on "Cross-Origin Resource
> Sharing", W3C Working Draft 17 March 2009
> http://www.w3.org/TR/2009/WD-cors-20090317/
>
> Perhaps some of these have been answered already and there are
> probably others I did not list.
>
> 1. GET can have side effects, so can we assume it is safe? Thus does
> it not also always require pre-flight check?
>
> 2. How is Origin set, is it always correct, how is it set for widgets?
> Perhaps the document should discuss this.
>
> 3. Is there a race condition between preflight request and subsequent
> request? What if server changes policy, e.g. allowed methods in this
> time.
> Is there a requirement on the maximum time between both these actions?
>
> 4. Shouldn't the specification require header integrity protection so
> they cannot be rewritten during transit? This could require TLS or
> secure channel or header signing so the mechanism may not be defined
> in the specification, but shouldn't integrity protection be a MUST?
>
> 5. Will Access-Control-Allow-Origin header scale if all possible URLs
> must be listed (I'm thinking of airline example) .
>
> 6. Security sections should be normative and have normative  
> statements.
>
> Section 3
> - remove statement that section is non-normative
> - Replace "Authors of client-side Web applications are strongly
> encouraged to validate content retrieved from a cross-origin resource
> as it might be harmful." with "Authors of client-side Web applications
> SHOULD validate content retrieved from a cross-origin resource as it
> might be harmful."
>
> editorial, replace "This section lists advice that did not fit
> anywhere else." with "This is general security considerations, more
> detailed are provided in specific sections."
>
> Section 5.3
> - remove statement that section is non-normative
> - Replace “are strongly encouraged to” with SHOULD in paragraph 1
> - Replace “are strongly encouraged to” with SHOULD in paragraph 2
> - Replace "To provide integrity protection of resource sharing policy
> statements usage of SSL/TLS is encouraged." with statement that
> "Integrity protection for headers MUST be provided. This MAY take the
> form of TLS, header signing, or other mechanisms, as appropriate."
>
> Section 6.3
> - remove statement that section is non-normative
>
> - Why is the statement "User agents are to carefully follow the rules
> set forth in the preceding sections to prevent introducing new attack
> vectors." needed? Remove it, since the normative rules  in this
> specification must be followed for compliance,  and if important
> should be normative.
>
> - Replace “are allowed to” with SHOULD in paragraph 2
>
> - Replace “are encouraged to” with SHOULD in paragraph 3
>
> - Replace "User agents are encouraged to apply security decisions on a
> generic level and not just to the resource sharing policy." with
> "These  MUST apply equally to access through APIs (e.g.
> XMLHttpRequest) or through inlined content (e.g. iframe, script,
> img)." (taking from WARP)
> It might be that I do not understand this statement, some
> clarification would be helpful.
>
> - Replace “is encouraged” with MUST in last sentence.
>
> 7. Is there a resolution to Mark Nottingham's concerns  expressed in http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0226.html
>  ? Aren't these reasonable concerns?
>
> 8 Is the party of permissions the site (origin) requesting the
> content? What about per-identity permissions? How will this work with
> OAuth etc? Will this be a general issue?
>
> 9. What is the resolution to the "confused deputy" concern? Should the
> specification note the concern? I'm not sure if the WG has discussed/
> resolved this issue.
>
> 10  requirements section: Requirement #1 - What is the implied
> alternative for additional protection than firewall?
>
> 11  requirements section: Is Requirement #2 accurate given that GET
> can have side effects so is not always safe?
>
> 12  requirements section: How did Requirement #4 impact this
> specification? How does this attack come into play with this
> specification and if it does, how does the specification address it?
>
> 13  requirements section: Is requirement #8 possible? Isn't
> configuration required to return headers, deal with pre-flight
> requests etc? Or would this be addressed by Mark Nottingham's
> suggestion to always return access header?
>
> 14  requirements section: Requirement #17, does this include
> integration with identity management solutions?
>
> 15 Editorial:  Abstract
> Extend sentence "This document defines a mechanism to enable client-
> side cross-origin requests." to say, by whom.
> Mention widgets as well as web browser cases in abstract?
>
> 16 Editorial: Section 1
> "The user agent validates that the value and origin of where the
> request originated match."
> Value has not been defined.  Sentence is not very clear.
>
> 17 Editorial: Section 1
> Replace
> "User agents are enabled to discover whether a cross-origin resource
> is prepared to accept requests using a non-GET method from a given
> origin."
> with
> "User agents are enabled via preflight checking..."
>
> 18 Editorial: Section 1
> In "This extension enables server-side applications to enforce
> limitations on the cross-origin requests that they are willing to
> service"
> clarify the "limitations"
>
> 19 Editorial: Section 2
>
> Replace "This specification is written for servers and user agents."
> with "This specification is written for implementers of user agents
> that enforce policy, APIs that use it, and web servers that provide
> content that may be used in cross-site manner."
>
> 20 Editorial: Section 2
> Why is the term "hosting specifications" given, is it common
> terminology? Can it be removed?
>
> 21 Editorial: Section 2
> Is a conformant server one that returns appropriate headers for
> requests?
>
> 22 Editorial:  Section 4.5
> Where is the full list of headers defined? is a reference needed?
>
> 23 Editorial: Section 5.1 #1
> Can the list of origins be unbounded in practice?
>
> 24 Editorial: Section 6
> Mark "Everything with regards to redirects might change a little to
> more closely adhere to HTTP redirect semantics." as an editors note.
>
> 25 Editorial: Section 6.1
> some of the spacing between items seems to need additional space
>
> 26  Editorial: Section 7.3
> Replace "progresing" with "progressing"
>
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>

Received on Tuesday, 30 June 2009 15:39:19 UTC