Ian Hickson | 3 Oct 01:40 2007
Picon

[access-control] Potential security problem (port should be auto-restricted)


Right now, if I have a server at example.com that says:

   Access-Control: allow <http://hixie.ch/>

...it looks like I'm safe, because I control the domains hixie.ch and 
example.com completely. Except, I'm actually not safe. To be safe, I'd 
have to say:

   Access-Control: allow <http://hixie.ch:80/>

...because in fact, anyone with an account on the machine which hosts 
hixie.ch can open any random port above 1024, and then host a Web server 
there that claims to be hixie.ch, such that URIs with the prefix:

   http://hixie.ch:9999/

...would be under someone else's control.

Thus, I think the spec should not default the port to unrestricted. I 
think that few authors would ever include the port, since the _URI_ syntax 
"http://hixie.ch/" implies port 80, and they won't think of that as a 
problem.

I recommend that the spec default the port to the default port for the 
given scheme (80 for http:, 443 for https:, etc).

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
(Continue reading)

Ian Hickson | 3 Oct 02:03 2007
Picon

[access-control] Minor issues


I was confused when reading the spec last night because the term 
"requesting URI" is used to mean something that is not the requesting URI. 
I recommend changing the term throughout to "referrer root URI" or some 
such. (IIRC, I invented the concept. So if _I'm_ confused...)

"For instance, a specification using the access control mechanism needs to 
define what the requesting URI is." is wrong; the specification using the 
access control mechanism needs to define the source for the requesting 
URI, but the actual requesting URI is defined in section "2.2.3. URI 
Matching".

"up to and including the root element start tag" in step 5 of "2.2.2. 
Access Check" seems dangerous; I would recommend defining it as being "up 
to but _not_ including the root element" since otherwise documents like 
the following could have unexpected side-effects:

    <script xmlns="http://www.w3.org/1999/xhtml" 
            src="data:text/javascript,alert('test')"/>

"If the processing instruction has any other pseudo-attributes than deny, 
allow and exclude, has not exactly two pseudo-attributes or has both deny 
and allow specified terminate the overall algorithm and deny access to the 
resource." in step 5.1 of "2.2.2. Access Check" seems wrong: shouldn't you 
be able to have just one pseudo-attribute? (i.e. isn't the "exclude" 
attribute optional?)

You have a "Note:" in section "2.1.2. Access-Control HTTP Header" that has 
the word "may" in it: "As stated by RFC 2616, multiple Access-Control 
headers may be combined."
(Continue reading)

Marcos Caceres | 3 Oct 07:14 2007
Picon

[WIDGETS] Zip Support (request for comments)


Hi all,
I'm currently trying to draft up the normative text for the level of
Zip support that the widgets spec should have. For the spec, I'm
trying to base the support for Zip on what is currently available
across various operating systems (Vista, XP, and OSX). I'm basing it
on those OSs for interoperability. The problem I am having is that
there is no formal "standard" for what features of Zip are currently
supported across the "native" OS implementations. The current version
of the zip APPNOTE (6.3.2) [1], has some nice features, but in no way
does it match the reality of what is currently implemented in the
various operating systems. Does anyone know of any definitive
reference of what parts of Zip are implemented across leading OSs?

The other problem is that the Zip spec is a non-normative text that is
periodically being updated. I've also found it difficult to locate
previous version of the specification so it is hard to mandate that
implementers adhere to a particular version of the Zip spec (eg.
version 2.0). Any ideas as to how to spec this (without actually
having to re-spec Zip itself)?

This is what I have got so far...

For the purposes of this specification, A valid Zip file is a data
object that conform to the Zip File Format Specification (version
6.3.2) with the exclusion or support of the following features. In the
event that a widget user agents encouters Zip file that is in error,
the widget user agent must abort any processing of the Zip file and
should inform the end-user with an appropriate localized error dialog:

(Continue reading)

Ric Johnson | 3 Oct 02:05 2007
Picon

access-control


I have a few questions for the new draft:

Is this really required? I can achieve the same with
   a) Dynamic script tags (JSON requests) as long I am am comfortable with GET
   b) PROXY governance
   c) CNAMEs as a way to bypass the domain restrictions

Other issues:
  a) No only does the browser have to allow this, but XMLRequest does as well.
  b) What about <a href="http://json.Com">JSON</a> responses?  XML is
great, but let us not fall into the "Not invented here" trap

I am NOT saying that this is not a good idea.  It is just that if I
have access to the web server to add a header, then I probably will be
able to solve this problem today.

I actually need this for my JSON requests.  As it stands now, I can do
cross-domain without really looking at security.  Might there be a way
to emulate this using script now?

Ric Johnson | 2 Oct 00:57 2007
Picon

[access-control] json


I have a few questions for the new draft:
http://www.w3.org/TR/2007/WD-access-control-20071001/

Is this really required? I can achieve the same with
    a) Dynamic script tags (JSON requests) as long I am am comfortable with GET
    b) PROXY governance
    c) CNAMEs as a way to bypass the domain restrictions

Other issues:
   a) No only does the browser have to allow this, but XMLRequest does as well.
   b) What about <a href="http://json.Com">JSON</a> responses?  XML is
great, but let us not fall into the "Not invented here" trap

I am NOT saying that this is not a good idea.  It is just that if I
have access to the web server to add a header, then I probably will be
able to solve this problem today.

I actually need this for my JSON requests.  As it stands now, I can do
cross-domain without really looking at security.  Might there be a way
to emulate this using script now?

Ric Johnson | 3 Oct 02:09 2007
Picon

[access-control] JSON


I have a few questions for the new draft:
http://www.w3.org/TR/2007/WD-access-control-20071001/

Is this really required? I can achieve the same with
   a) Dynamic script tags (JSON requests) as long I am am comfortable with GET
   b) PROXY governance
   c) CNAMEs as a way to bypass the domain restrictions

Other issues:
  a) No only does the browser have to allow this, but XMLRequest does as well.
  b) What about <a href="http://json.Com">JSON</a> responses?  XML is
great, but let us not fall into the "Not invented here" trap

I am NOT saying that this is not a good idea.  It is just that if I
have access to the web server to add a header, then I probably will be
able to solve this problem today.

I actually need this for my JSON requests.  As it stands now, I can do
cross-domain without really looking at security.  Might there be a way
to emulate this using script now?

Jon Ferraiolo | 3 Oct 19:50 2007
Picon

Re: [WIDGETS] Zip Support (request for comments)

Marcos,
The IDPF went through all of the issues about how to standardize an appropriate subset of ZIP and has an approved specification. Look at (http://www.idpf.org/ocf/ocf1.0/download/ocf10.pdf) and go to section 4.

I see that you want to disallow the ZIP64 extension, but a 4G limitation seems rather small these days. I realize that W3C Widgets are usually meant for lightweight things that can download quickly, but W3C should be defining orthogonal, reusable technologies that will be suitable for a long time. Also, I would argue that any ZIP container capabilities belong in a separate specification (that supports 64 bits). The widget specification then could refer to this separate ZIP specification (perhaps even the IDPF spec) and then say that 64-bit support is not required in conformant desktop widget clients.

But more fundamentally, I'm not fully convinced that version 1.0 of the Widgets spec has to include ZIP packaging. For example, it looks to me like neither Google Gadgets nor Vista Gadgets create a single-file package. This makes me suspicious about whether ZIP packaging is a requirement.

Cheers,
Jon

"Marcos Caceres" <marcosscaceres <at> gmail.com>


          "Marcos Caceres" <marcosscaceres <at> gmail.com>
          Sent by: public-appformats-request <at> w3.org

          10/02/2007 10:14 PM


To

"public-appformats <at> w3.org" <public-appformats <at> w3.org>

cc


Subject

[WIDGETS] Zip Support (request for comments)


Hi all,
I'm currently trying to draft up the normative text for the level of
Zip support that the widgets spec should have. For the spec, I'm
trying to base the support for Zip on what is currently available
across various operating systems (Vista, XP, and OSX). I'm basing it
on those OSs for interoperability. The problem I am having is that
there is no formal "standard" for what features of Zip are currently
supported across the "native" OS implementations. The current version
of the zip APPNOTE (6.3.2) [1], has some nice features, but in no way
does it match the reality of what is currently implemented in the
various operating systems. Does anyone know of any definitive
reference of what parts of Zip are implemented across leading OSs?

The other problem is that the Zip spec is a non-normative text that is
periodically being updated. I've also found it difficult to locate
previous version of the specification so it is hard to mandate that
implementers adhere to a particular version of the Zip spec (eg.
version 2.0). Any ideas as to how to spec this (without actually
having to re-spec Zip itself)?

This is what I have got so far...

For the purposes of this specification, A valid Zip file is a data
object that conform to the Zip File Format Specification (version
6.3.2) with the exclusion or support of the following features. In the
event that a widget user agents encouters Zip file that is in error,
the widget user agent must abort any processing of the Zip file and
should inform the end-user with an appropriate localized error dialog:

Zip files must not be split into multiple files or span multiple
volumes. Zip files that are split into multiple files or span multiple
volumes are non-conforming. A widget user agent must treat Zip files
that have been split into multiple files or span multiple volumes as
being in error.

Zip files must be created using the Deflate compression algorithm as
specified in [Zip]. Zip files compressed with any other compression
algorithm are non-conforming. A widget user agent must treat Zip files
created using other compression algorithms as being in error.

A Zip file must not be created using the ZIP64 extensions defined in
Section of the Zip File Format Specification. A widget user agent must
consider Zip files created using ZIP64 extensions as being in error.

A Zip file must not be created using either the Traditional PKWARE
Encryption or Strong Encryption methods, or any other future
encryption method, defined in the Zip File Format Specification.
Widget user agents must treat encrypted Zip files as being in error.

The names of files and directories within a Zip file must be encoded
in US-ASCII within the range [a-z A-Z 0-9, ,. - _]. A Widget user
agent must consider Zip files that contain file or directory names
with characters outside the aforementioned character range as being in
error.

Kind regards,
Marcos

[1]http://www.pkware.com/documents/casestudies/APPNOTE.TXT
--
Marcos Caceres
http://datadriven.com.au


Ian Hickson | 3 Oct 20:36 2007
Picon

XBL2 underspecified


Hi Gregory,

In a recent XHTML2 working group meeting [1], you minuted yourself as 
saying "XBL draft dangersously underspecified". I was wondering if you 
could elaborate on that. I very much would like XBL2 [2] to be specified 
in detail, and any information about holes you could provide me with would 
be very helpul for achieving this goal.

[1] http://www.w3.org/2007/10/03-xhtml-minutes.html
[2] http://www.w3.org/TR/xbl/

Cheers,
--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Gregory J. Rosmaita | 3 Oct 21:17 2007
Picon

Re: XBL2 underspecified


aloha, ian!

mea culpa -- i didn't mean the XBL specification itself, i was 
referring to the XBL 2.0 Primer, but apparently i can't speak,
minute, listen to my screen reader, listen to the telecon and 
chew gum simultaneously -- next time, i'll forgo the gum...

as far as the primer is concerned, i don't have the cycles right
now, but i do need to contact lachy about providing verbiage for 
Chapter 5 (Enhancing user experience) and Chapter 6 (Re-purposing 
content to increase accessibility) as some of the work i'm involved
in vis à vis ARIA and Expert Handlers for providing a bridge between
specialized content and assistive technologies, seems to me to be 
pertinent with many cross-over points, but i was hanging fire on that 
front until i cleared my desk of (to me, at least,) a few more 
pressing/urgent issues...

i apologize for any misunderstanding; having reviewed the XBL2 
draft multiple times, i would very much like to contribute to the 
primer, if possible, as it will be an invaluable resource to those 
seeking to understand and implement XBL correctly, especially if 
the reader has no background in XBL or awareness of the issues 
which the primer will address in chapters 5 and 6

i hope this clarifies my own mis-minuted comments -- i will re-review
the XBL2 draft itself with an ear towards identifying any possible 
holes in the draft, which -- in my opinion, at least -- is quite well
specified, save for those isolated spots where the draft acknowledges 
that further and/or more suitable text is needed and will be added 
when it becomes available, such as the disclaimer in section 8.2.2. -- 
the only minor suggestion i have is that it would be helpful to indicate
if the draft is waiting for a description/definition from another 
forum/working group, or whether the details are being worked on within 
the public-appsformat forum...

gregory.

  ------------------------------------------------------------------
  "Let me save you from drowning," said the monkey as he placed the 
  fish into a tree.                                 -- Hindu proverb
  ------------------------------------------------------------------
                Gregory J. Rosmaita <oedipus <at> hicom.net>
      Camera Obscura: http://www.hicom.net/~oedipus/index.html
  ------------------------------------------------------------------

---------- Original Message -----------
From: Ian Hickson <ian <at> hixie.ch>
To: "Gregory J. Rosmaita" <oedipus <at> hicom.net>
Cc: public-appformats <at> w3.org
Sent: Wed, 3 Oct 2007 18:36:43 +0000 (UTC)
Subject: XBL2 underspecified

> Hi Gregory,
> 
> In a recent XHTML2 working group meeting [1], you minuted 
> yourself as saying "XBL draft dangersously underspecified". I 
> was wondering if you could elaborate on that. I very much would 
> like XBL2 [2] to be specified in detail, and any information 
> about holes you could provide me with would be very helpul for 
> achieving this goal.
> 
> [1] http://www.w3.org/2007/10/03-xhtml-minutes.html
> [2] http://www.w3.org/TR/xbl/
> 
> Cheers,
> -- 
> Ian Hickson               U+1047E                )\._.,--....,
> '``.    fL http://ln.hixie.ch/       U+263A                /,  
>  _.. \   _\  ;`._ ,. Things that are impossible just take 
> longer.   `._.-(,_..'--(,_..'`-.;.'
------- End of Original Message -------

Anne van Kesteren | 4 Oct 00:17 2007
Picon

Re: [access-control] Potential security problem (port should be auto-restricted)


On Wed, 03 Oct 2007 01:40:33 +0200, Ian Hickson <ian <at> hixie.ch> wrote:
> I recommend that the spec default the port to the default port for the
> given scheme (80 for http:, 443 for https:, etc).

I believe this was removed based on feedback from implementors. But maybe
we haven't fully considered all the options back then. I think we should
integrate this proposal as to not require authors to specify :80 on their
shared hosting accounts. The new algorithm would work as follows:

http://example.org matches against http://example.org:80 but not
http://example.org:81 The port defaults to the default port for the scheme.

example.org matches against http://example.org:80,
https://example.org:8000, etc. The scheme and port both act as a wildcard.

To make it possible to require a certain scheme but allow access from any
port we can introduce * for port. So you can specify http://example.org:*
which does match http://example.org:81 among others.

Any opinions?

--

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


Gmane