Re: CDR: description of current web security model has problems

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: CDR: description of current web security model has problems

Charles McCathieNevile-2

Maciej, you wrote:

> 2.5.3
> "Currently, the common approach used is to restrict access across  
> documents or network interfaces to material which comes from the same  
> source as the code which tries to make that access."
>
> - This sentence is not grammatically correct English.

It is grammatically correct english. It is not very clear, so we will  
re-write it. We hope it will be clearer.

> - The claim made by the sentence is not correct. Access is based on the  
> domain (and protocol and port) of the documents in the context of which  
> the code is executing. It ignores where the code comes from, if the  
> document happened to include code, such as JavaScript, from a site other  
> than that which the document came from.

This is correct, in detail. Broadly speaking, the practical upshot is  
similar to the existing brief description.

> "This makes it difficult to re-use resources on the Web, by requiring a  
> copy to be held in the domain of each application which uses that
> resource."
>
> - I don't see how this is true. JavaScript files, CSS files, images and  
> html files can all be included from other sites. The difficulty only  
> occurs when you wish to read the contents of such documents. There is no  
> client-side technology that two sites could use to collaborate.

Cross-document messaging, or simple DOM calls across a document object are  
not restricted by spec to the same site.

> "This breaks cacheability, potentially reduces maintainability, and  
> requires services to maintain the entire service rather than taking full  
> advantage of specialised third-party providers."
>
> - I'm not buying these claims but ok - does this spec propose doing  
> anything different in this regard? Does it propose that access to  
> different documents *not* be restricted based on domain/scheme/port as  
> traditionally?

The spec does not propose a security model, it points out that there are  
potential security risks invovled in granting access to a DOM from a  
different document (see your own message at @@). It notes in passing that  
one common approach (cross-domain restriction) while "good enough for many  
current uses" is neither a particularly brilliant nor a brilliantly secure  
approach for the Web at large, and so explicitly avoids mandating this  
approach.

I hope this satisfies your concern. If not please let us know within two  
weeks.

For the working group, cheers

Chaals

--
Charles McCathieNevile                     [hidden email]
   hablo español  -  je parle français  -  jeg lærer norsk
      Peek into the kitchen: http://snapshot.opera.com/

Reply | Threaded
Open this post in threaded view
|

Re: CDR: description of current web security model has problems

Bjoern Hoehrmann

* Charles McCathieNevile wrote:
>The spec does not propose a security model, it points out that there are  
>potential security risks invovled in granting access to a DOM from a  
>different document (see your own message at @@). It notes in passing that  
>one common approach (cross-domain restriction) while "good enough for many  
>current uses" is neither a particularly brilliant nor a brilliantly secure  
>approach for the Web at large, and so explicitly avoids mandating this  
>approach.

I'd appreciate some clarification here. Let's assume a user agent that
implements only the absolute requirements of the CDF specifications, and
a document http://example.org/foo.xhtml with

  <object data="http://org.example/bar.svg" ...>

Let's further assume that both documents use cookie-based authentication
and the user is logged into both sites when visiting the XHTML document;
both documents expose the user name in the DOM tree like "Hello Björn";
do I understand correctly that

  * bar.svg can read the example.org user name
  * foo.xhtml can read the org.example user name
  * bar.svg can synthesize events and bubble them into foo.xhtml

and further

  * this would be the default behavior
  * there is no way for bar.svg to opt out of it
  * there is no way for foo.xhtml to opt out of it

If this is correct it seems example.org and org.example can only protect
their users by hoping that browser vendors won't allow this to work by
default and take further steps to reduce the risk, e.g. by embedding
only fully trusted SVG content.

If I understand the model correctly, could you elaborate on why this
model is preferable to e.g. a model where implementations must not by
default grant access from either resource to the other and provide means
that allow them to opt in to a less restricted model?

I note that e.g. in the context of VoiceXML the latter model has been
chosen, see e.g. <http://www.w3.org/TR/access-control/>. At the moment
I would rather that this document is put on the Recommendation track
with changes as proposed by Ian Hickson and others, like extending it
to be also usable from HTTP headers, support for IDNs, etc.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

Re: CDR: description of current web security model has problems

Maciej Stachowiak
In reply to this post by Charles McCathieNevile-2


On Feb 6, 2006, at 4:30 AM, Charles McCathieNevile wrote:

> Maciej, you wrote:
>
>> 2.5.3
>> "Currently, the common approach used is to restrict access across  
>> documents or network interfaces to material which comes from the  
>> same source as the code which tries to make that access."
>>
>> - This sentence is not grammatically correct English.
>
> It is grammatically correct english. It is not very clear, so we  
> will re-write it. We hope it will be clearer.

It does seem grammatical now that I read more closely, but more  
confusing.

>> - The claim made by the sentence is not correct. Access is based  
>> on the domain (and protocol and port) of the documents in the  
>> context of which the code is executing. It ignores where the code  
>> comes from, if the document happened to include code, such as  
>> JavaScript, from a site other than that which the document came from.
>
> This is correct, in detail. Broadly speaking, the practical upshot  
> is similar to the existing brief description.

The practical upshot is actually not the same, because stylesheets,  
images, media resources, JavaScript, and documents from other domains  
can be included with current web technology. In the case of all of  
these but JavaScript, such access is provided in a secure way. The  
spec misleadingly makes it sound like you cannot transclude a  
document from another domain today, which you can, though with  
restricted scripting access.

In any case, the spec should not say things that are false, even if  
they did have the same "practical upshot" as the actual fact of the  
matter.


>> "This makes it difficult to re-use resources on the Web, by  
>> requiring a copy to be held in the domain of each application  
>> which uses that
>> resource."
>>
>> - I don't see how this is true. JavaScript files, CSS files,  
>> images and html files can all be included from other sites. The  
>> difficulty only occurs when you wish to read the contents of such  
>> documents. There is no client-side technology that two sites could  
>> use to collaborate.
>
> Cross-document messaging, or simple DOM calls across a document  
> object are not restricted by spec to the same site.

This is insecure by design. The spec should not in any wayencourage  
implementing cross-document DOM calls with no security restrictions.  
This can be used for phishing attacks or other information theft. I  
strongly disagree with the spec encouraging no security restrictions  
for the interfaces it defines.

>> "This breaks cacheability, potentially reduces maintainability,  
>> and requires services to maintain the entire service rather than  
>> taking full advantage of specialised third-party providers."
>>
>> - I'm not buying these claims but ok - does this spec propose  
>> doing anything different in this regard? Does it propose that  
>> access to different documents *not* be restricted based on domain/
>> scheme/port as traditionally?
>
> The spec does not propose a security model, it points out that  
> there are potential security risks invovled in granting access to a  
> DOM from a different document (see your own message at @@). It  
> notes in passing that one common approach (cross-domain  
> restriction) while "good enough for many current uses" is neither a  
> particularly brilliant nor a brilliantly secure approach for the  
> Web at large, and so explicitly avoids mandating this approach.

It is actually an approach that works well in practice. I do not  
think the spec should disparage the current de facto web security  
model without proposing an alternative. "No security restrictions on  
cross-document access" is not a viable alternative.

> I hope this satisfies your concern. If not please let us know  
> within two weeks.

It does not satisfy my concern. I believe you have left factually  
incorrect assertions in the spec and left it appearing to encourage a  
security model that is insecure by design.

If you do not wish to mandate the current web security model for  
cross-site scripting restrictions, I would be fine with documenting  
it in an informative note, and saying implementations SHOULD  
implement some security model which does not have to be the one  
presented.

Regards,
Maciej