I added another sample page. This one shows two simple widgets that
coexist.

http://adsafe.org/roman.html

The w3c Technical Architecture Group (TAG) discuss ocaps for the web starting at
http://www.w3.org/2001/tag/2008/12/10-minutes#item03

teaser sample:
'DO: SW and I got invloved in this spec a while ago.... We tried to
push them to Tyler approach. We got pushback. Then they decided to do
usecases and reqmnts. Stuart and I looked at their docs and asked
"what does the algorithm do"? If we got enough people in WG that
wanted something different we could get something done. Need to muster
support for a coherent position.'

--
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM

erights@... (Mark Miller) on Monday, January 5, 2009 wrote:

>The w3c Technical Architecture Group (TAG) discuss ocaps for the web starting
at
>http://www.w3.org/2001/tag/2008/12/10-minutes#item03

For me, the highlight was, "Crockford says add a switch in Firefox to
disable non-adSafe ads". If this feature gets adopted, and used, we'll see
an overnight change in Javascript style. :-)

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | When it comes to the world     | Periwinkle
(408)356-8506      | around us, is there any choice | 16345 Englewood Ave
www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032

At the end of the minutes, it looks like the TAG is casting about for
a next step. One useful step would be to consider amending the
web-arch document's discussion of access-control:

http://www.w3.org/TR/webarch/#id-access

The access-control section is at odds with the core architectural
principles set forth in the web-arch document. These contradictions
are the main topic of my web-key paper:

http://waterken.sourceforge.net/web-key/

Resolving the inconsistencies in the TAG's current public stance on
access-control might make it easier to adopt alternate solutions like
the web-key.

--Tyler

On Mon, Jan 5, 2009 at 1:14 PM, Mark Miller <erights@...> wrote:
>
> The w3c Technical Architecture Group (TAG) discuss ocaps for the web starting
at
> http://www.w3.org/2001/tag/2008/12/10-minutes#item03
>
> teaser sample:
> 'DO: SW and I got invloved in this spec a while ago.... We tried to
> push them to Tyler approach. We got pushback. Then they decided to do
> usecases and reqmnts. Stuart and I looked at their docs and asked
> "what does the algorithm do"? If we got enough people in WG that
> wanted something different we could get something done. Need to muster
> support for a coherent position.'
>
> --
> Text by me above is hereby placed in the public domain
>
>    Cheers,
>    --MarkM
>

Previous W2SP Workshops: 2008, 2007

The goal of this one day workshop is to bring together researchers and practitioners from academia and industry to focus on understanding Web 2.0 security and privacy issues, and establishing new collaborations in these areas.

Web 2.0 is about connecting people and amplifying the power of working together. Enabled by a wave of new technology, these social and business interactions rely on composition of content and services from multiple sources, commonly called mash-ups, leading to systems with complex trust boundaries. This trend is likely to continue because individuals and businesses desire the efficiency and simplicity these technologies offer.

Together with their virtues, these technologies raise issues about management of identities, reputation, privacy, anonymity, transient and long term relationships, and composition of function and content, both on the server and on the client (web browser). Although the underlying security and privacy issues are not new, the use of these technologies on a wide scale and by a broad audience raises new questions. This workshop is intended to discuss the limitations of current technologies and explore alternatives.

The scope of W2SP 2009 includes, but is not limited to:

• Trustworthy cloud-based services
• Privacy and reputation in social networks
• Usable security and privacy
• Security for the mobile web
• Identity management and psuedonymity
• Advertisement and affiliate fraud
• Provenance and governance
• Security and privacy as a service
• Web services/feeds/mashups
• Security and privacy policies for composible content
• Next-generation browser technology

Workshop Co-Chairs

• Larry Koved (IBM Research)
• Dan S. Wallach (Rice University)

• Adam Barth (UC Berkeley)

• Ben Adida (Harvard University)
• Dirk Balfanz (PARC)
• Adam Barth (UC Berkeley)
• Konstantin (Kosta) Beznosov
• Suresh Chari (IBM Research)
• Hao Chen (UC Davis)
• Douglas Crockford (Yahoo)
• Chris Karlof (UC Berkeley)
• Larry Koved (IBM Research)
• Shriram Krishnamurthi (Brown University)
• Collin Jackson (Stanford University)
• Rob Johnson (Stony Brook University)
• John C. Mitchell (Stanford University)
• Sean W. Smith (Dartmouth University)
• Helen Wang (Microsoft Research)
• Dan S. Wallach (Rice University)

Paper submission deadline: March 6, 2009, (11:59pm US-Eastern)
Workshop acceptance notification date: March 31, 2009
Workshop date: Thursday, May 21, 2009

Workshop paper submission web site: To be announced.

At

   http://wiki.ecmascript.org/doku.php?id=ses:ses_proposal_working_draft

is posted a very rough first draft for a "Secure ECMAScript" standard,
derived from the "Mountain View draft" of ES3.1
<http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft>
and from Cajita. I hope and believe that we can resolve differences
between this and other contenders for the Cajita-like layer: ADsafe,
Jacaranda, and Dojo Secure. (As for the Valija-like layer, both Valija
and MS WebSandbox intend to emulate at least ES3.1-strict, so there's
no need for a separate standard for that layer.)

Further discussion of SES specifically should proceed on the "caplet
group" list.

--
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Do you have an overview of the differences between SES and ES3.1 (or
maybe it is easier to define the differences between SES and Cajita)?
I see a lot of [[Prototype]] -> [[Parent]] changes, but maybe you
could summarize the important differences?
Kris

Mark Miller wrote:
>
> At
>
> http://wiki.ecmascript.org/doku.php?id=ses:ses_proposal_working_draft
> <http://wiki.ecmascript.org/doku.php?id=ses:ses_proposal_working_draft>
>
> is posted a very rough first draft for a "Secure ECMAScript" standard,
> derived from the "Mountain View draft" of ES3.1
> <http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft
> <http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft>>
> and from Cajita. I hope and believe that we can resolve differences
> between this and other contenders for the Cajita-like layer: ADsafe,
> Jacaranda, and Dojo Secure. (As for the Valija-like layer, both Valija
> and MS WebSandbox intend to emulate at least ES3.1-strict, so there's
> no need for a separate standard for that layer.)
>
> Further discussion of SES specifically should proceed on the "caplet
> group" list.
>
> --
> Text by me above is hereby placed in the public domain
>
> Cheers,
> --MarkM
>
>  <!-- #ygrp-mkp{ border: 1px solid #d8d8d8; font-family:
> Arial; margin: 14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border:
> 1px solid #d8d8d8; } #ygrp-mkp #hd{ color: #628c2a; font-size: 85%;
> font-weight: bold; line-height: 122%; margin: 10px 0px; } #ygrp-mkp
> #ads{ margin-bottom: 10px; } #ygrp-mkp .ad{ padding: 0 0; }
> #ygrp-mkp .ad a{ color: #0000ff; text-decoration: none; } --> <!--
> #ygrp-sponsor #ygrp-lc{ font-family: Arial; } #ygrp-sponsor #ygrp-lc
> #hd{ margin: 10px 0px; font-weight: bold; font-size: 78%;
> line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{ margin-bottom:
> 10px; padding: 0 0; } --> <!-- #ygrp-mlmsg {font-size:13px;
> font-family:
> arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
> #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
> input, textarea {font:99% arial,helvetica,clean,sans-serif;}
> #ygrp-mlmsg pre, code {font:115% monospace;*font-size:100%;}
> #ygrp-mlmsg * {line-height:1.22em;} #ygrp-text{ font-family:
> Georgia; } #ygrp-text p{ margin: 0 0 1em 0; } #ygrp-tpmsgs{
> font-family: Arial; clear: both; } #ygrp-vitnav{ padding-top: 10px;
> font-family: Verdana; font-size: 77%; margin: 0; } #ygrp-vitnav a{
> padding: 0 1px; } #ygrp-actbar{ clear: both; margin: 25px 0;
> white-space:nowrap; color: #666; text-align: right; } #ygrp-actbar
> .left{ float: left; white-space:nowrap; } .bld{font-weight:bold;}
> #ygrp-grft{ font-family: Verdana; font-size: 77%; padding: 15px 0; }
> #ygrp-ft{ font-family: verdana; font-size: 77%; border-top: 1px
> solid #666; padding: 5px 0; } #ygrp-mlmsg #logo{ padding-bottom:
> 10px; } #ygrp-reco { margin-bottom: 20px; padding: 0px; } #ygrp-reco
> #reco-head { font-weight: bold; color: #ff7900; } #reco-grpname{
> font-weight: bold; margin-top: 10px; } #reco-category{ font-size:
> 77%; } #reco-desc{ font-size: 77%; } #ygrp-vital{ background-color:
> #e0ecee; margin-bottom: 20px; padding: 2px 0 8px 8px; } #ygrp-vital
> #vithd{ font-size: 77%; font-family: Verdana; font-weight: bold;
> color: #333; text-transform: uppercase; } #ygrp-vital ul{ padding:
> 0; margin: 2px 0; } #ygrp-vital ul li{ list-style-type: none; clear:
> both; border: 1px solid #e0ecee; } #ygrp-vital ul li .ct{
> font-weight: bold; color: #ff7900; float: right; width: 2em;
> text-align:right; padding-right: .5em; } #ygrp-vital ul li .cat{
> font-weight: bold; } #ygrp-vital a{ text-decoration: none; }
> #ygrp-vital a:hover{ text-decoration: underline; } #ygrp-sponsor
> #hd{ color: #999; font-size: 77%; } #ygrp-sponsor #ov{ padding: 6px
> 13px; background-color: #e0ecee; margin-bottom: 20px; }
> #ygrp-sponsor #ov ul{ padding: 0 0 0 8px; margin: 0; } #ygrp-sponsor
> #ov li{ list-style-type: square; padding: 6px 0; font-size: 77%; }
> #ygrp-sponsor #ov li a{ text-decoration: none; font-size: 130%; }
> #ygrp-sponsor #nc{ background-color: #eee; margin-bottom: 20px;
> padding: 0 8px; } #ygrp-sponsor .ad{ padding: 8px 0; } #ygrp-sponsor
> .ad #hd1{ font-family: Arial; font-weight: bold; color: #628c2a;
> font-size: 100%; line-height: 122%; } #ygrp-sponsor .ad a{
> text-decoration: none; } #ygrp-sponsor .ad a:hover{ text-decoration:
> underline; } #ygrp-sponsor .ad p{ margin: 0; } o{font-size: 0; }
> .MsoNormal{ margin: 0 0 0 0; } #ygrp-text tt{ font-size: 120%; }
> blockquote{margin: 0 0 0 4px;} .replbq{margin:4} -->

- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl3OrQACgkQ9VpNnHc4zAxUrQCgsxAlxVfj/52zM1hTXGVXTHQA
D2gAoLK5u2/l7pHEv/Kcbyc6WnPpQTj7
=fLQe
-----END PGP SIGNATURE-----

Consider the following JavaScript source:

    [ /[/]/ /foo]/ + bar

According to the ES3 spec, this is interpreted as:

    [ new RegExp("[") ] / new RegExp("foo]") + bar

According to the ES3.1 draft spec, it is interpreted as:

    [ new RegExp("[\/]") / foo ] / +bar

Apparently, Firefox and IE7 were lexing regexp literals in the way
ES3.1 specifies. I had considered re-allowing regexp literals in
Jacaranda 0.4, but this has scared me off doing so -- the potential
for lexical confusion attacks is just too great.

--
David-Sarah Hopwood ⚥

On Feb 9, 2009, at 9:42 AM, Marcel Laverdet wrote:

> From what I remember this started out as a bug in IE and then
> Firefox followed suit for compatibility which left the other
> browsers with no choice.

No, other browsers followed suit first.


> I can't find the original bug but `/[/]/` only started parsing in
> FF1.5, in FF1.0 it would throw a syntax error.

https://bugzilla.mozilla.org/show_bug.cgi?id=309840

Quoting from comment 0:

Description From  Jesse Ruderman   2005-09-23 19:33:25 PST   (-)
[reply]     Private

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/
20050923
Firefox/1.4

Firefox gives an "unterminated character class" error on the regular
expression
/[/]/.  Safari and Opera 8.5 accept it.

I noticed this because a regular expression containing [/] appears in
http://msdn.microsoft.com/workshop/code/browdata.js, which was
mentioned in
bug 309695 comment 9.

/be

David-Sarah Hopwood wrote:
> Consider the following JavaScript source:
>
>    [ /[/]/ /foo]/ + bar
>
> According to the ES3 spec, this is interpreted as:
>
>    [ new RegExp("[") ] / new RegExp("foo]") + bar
>
> According to the ES3.1 draft spec, it is interpreted as:
>
>    [ new RegExp("[\/]") / foo ] / +bar
>
> Apparently, Firefox and IE7 were lexing regexp literals in the way
> ES3.1 specifies. I had considered re-allowing regexp literals in
> Jacaranda 0.4, but this has scared me off doing so -- the potential
> for lexical confusion attacks is just too great.

ADsafe rejects [ /[/]/ /foo]/ + bar. Just because ECMAScript says its ok doesn't
mean that ADsafe must. ADsafe insists that all internal / must have \.

2009/2/9 Douglas Crockford <douglas@...>
>
> David-Sarah Hopwood wrote:
> > Consider the following JavaScript source:
> >
> > [ /[/]/ /foo]/ + bar
> >
> > According to the ES3 spec, this is interpreted as:
> >
> > [ new RegExp("[") ] / new RegExp("foo]") + bar
> >
> > According to the ES3.1 draft spec, it is interpreted as:
> >
> > [ new RegExp("[\/]") / foo ] / +bar
> >
> > Apparently, Firefox and IE7 were lexing regexp literals in the way
> > ES3.1 specifies. I had considered re-allowing regexp literals in
> > Jacaranda 0.4, but this has scared me off doing so -- the potential
> > for lexical confusion attacks is just too great.
>
> ADsafe rejects [ /[/]/ /foo]/ + bar. Just because ECMAScript says its ok
doesn't
> mean that ADsafe must. ADsafe insists that all internal / must have \.

Cajita disallows regex literals, but Valija uses the ES3.1 rule for
lexing regexs and rewrites
     [ /[/]/ /foo]/ + bar
to
   [ (new RegExp('[\\/]', '')) / foo ] / +bar
though I think we do something to make sure it will always use the
builtin RegExp ctor, again using the ES3.1 semantics.

We rely on the builtin RegExp ctor to be callable with string
arguments without introducing a breach, / after a close bracket token
to always be interpreted as a div operator, and our normalization for
string escapes to produce a string literal where the browser agrees
with us where the string ends.

Marcel Laverdet wrote:
>
> From what I remember this started out as a bug in IE and then Firefox
> followed suit for compatibility which left the other browsers with no
> choice. I can't find the original bug but `/[/]/` only started parsing
> in FF1.5, in FF1.0 it would throw a syntax error.
>
> You could throw out any malformed regexp literals (any that differ
> between ES3 \ ES3.1) which is a fairly small subset and you would be ok.

I could, if I knew that there were no more bugs like this. Note that
lexical confusion attacks of this kind can easily be turned into complete
breaks of a subset implementation:

   [ /[/]/ /alert('toast')]/ + 1

Verifier sees valid, harmless code:
   [ new RegExp("[") ] / new RegExp("alert('toast')]") + 1

Browser runs exploit code:
   [ new RegExp("[\/]") / alert('toast') ] / +1

Since there's no way that I could reliably have known about the IE lexer
bug, it's just too risky.

Anyone know of other bugs where common JS implementations lex or parse
valid ES3 code with a different meaning than specified? (The only one
I can think of right now is \v in IE, but at least that doesn't result
in a parse with a different structure.)

--
David-Sarah Hopwood ⚥

Brendan Eich wrote:
> On Feb 9, 2009, at 9:42 AM, Marcel Laverdet wrote:
>
>> From what I remember this started out as a bug in IE and then
>> Firefox followed suit for compatibility which left the other
>> browsers with no choice.
>
> No, other browsers followed suit first.
>
>> I can't find the original bug but `/[/]/` only started parsing in
>> FF1.5, in FF1.0 it would throw a syntax error.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=309840

<https://bugzilla.mozilla.org/show_bug.cgi?id=309840#c12>

# This fixes a highly dup'ed IE compatibility bug.  It's an extension
# to ECMA syntax that's allowed by Section 16.  I'm approving it so
# that we can get it into 1.8b5 / Firefox 1.5b2.

As the example in my first post demonstrated, it is absolutely not
correct that this was an allowed Section 16 extension. That section
allows lexical extensions only if a program does not match the lexical
grammar in the spec (in this case using the ES3 definition of
RegularExpressionLiteral), and allows regexp syntax extensions only
if the resulting RegularExpressionBody does not match Pattern.

In fact this just makes me even more worried: it seems that Section 16
is being misinterpreted in a way that prevents independently developed
parsers, implemented strictly from the spec, from being able to match the
parsing behaviour of browsers on syntactically valid ES3 code. Is this
just a one-off mistake, or is Section 16 consistently being interpreted
too loosely?

--
David-Sarah Hopwood ⚥

Douglas Crockford wrote:
> David-Sarah Hopwood wrote:
>> Consider the following JavaScript source:
>>
>>    [ /[/]/ /foo]/ + bar
>>
>> According to the ES3 spec, this is interpreted as:
>>
>>    [ new RegExp("[") ] / new RegExp("foo]") + bar
>>
>> According to the ES3.1 draft spec, it is interpreted as:
>>
>>    [ new RegExp("[\/]") / foo ] / +bar
>>
>> Apparently, Firefox and IE7 were lexing regexp literals in the way
>> ES3.1 specifies. I had considered re-allowing regexp literals in
>> Jacaranda 0.4, but this has scared me off doing so -- the potential
>> for lexical confusion attacks is just too great.
>
> ADsafe rejects [ /[/]/ /foo]/ + bar. Just because ECMAScript says its ok
doesn't
> mean that ADsafe must. ADsafe insists that all internal / must have \.

I'm confused -- how does it know that the middle '/' in "/[/]/" is
"internal"? Is it lexing according to the intersection of Pattern
from section 15.10.1, and RegularExpressionBody?

--
David-Sarah Hopwood ⚥

On Feb 10, 2009, at 6:34 AM, David-Sarah Hopwood wrote:
> Brendan Eich wrote:
> > On Feb 9, 2009, at 9:42 AM, Marcel Laverdet wrote:
> >
> >> From what I remember this started out as a bug in IE and then
> >> Firefox followed suit for compatibility which left the other
> >> browsers with no choice.
> >
> > No, other browsers followed suit first.
> >
> >> I can't find the original bug but `/[/]/` only started parsing in
> >> FF1.5, in FF1.0 it would throw a syntax error.
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=309840
>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=309840#c12>
>
> # This fixes a highly dup'ed IE compatibility bug. It's an extension
> # to ECMA syntax that's allowed by Section 16. I'm approving it so
> # that we can get it into 1.8b5 / Firefox 1.5b2.
>
> As the example in my first post demonstrated, it is absolutely not
> correct that this was an allowed Section 16 extension.
>
You're right, but so what? The IE bug and monopoly combined to create
a de-facto standard. Appealing to the de-jure standard does you no
good, and correcting my 2005-ear misunderstanding (you've corrected it
more recently in es-discuss) does not change the de-facto standard
trumping the de-jure one.

> In fact this just makes me even more worried: it seems that Section 16
> is being misinterpreted in a way that prevents independently developed
> parsers, implemented strictly from the spec, from being able to
> match the
> parsing behaviour of browsers on syntactically valid ES3 code. Is this
> just a one-off mistake, or is Section 16 consistently being
> interpreted
> too loosely?
>

This has nothing to do with Section 16 or my former misunderstanding
of it, and everything to do with IE forcing a de-facto standard. As
far as I know, no one at Microsoft added the bug allowing unescaped /
in a character class by arguing based on a misinterpretation of
Section 16. I think you are barking up the wrong tree.

/be
>
>
> --
> David-Sarah Hopwood ⚥
>
>
>

2009/2/10 David-Sarah Hopwood <david.hopwood@...>:
> Marcel Laverdet wrote:
>>
>> From what I remember this started out as a bug in IE and then Firefox
>> followed suit for compatibility which left the other browsers with no
>> choice. I can't find the original bug but `/[/]/` only started parsing
>> in FF1.5, in FF1.0 it would throw a syntax error.
>>
>> You could throw out any malformed regexp literals (any that differ
>> between ES3 \ ES3.1) which is a fairly small subset and you would be ok.
>
> I could, if I knew that there were no more bugs like this. Note that
> lexical confusion attacks of this kind can easily be turned into complete
> breaks of a subset implementation:
>
> [ /[/]/ /alert('toast')]/ + 1
>
> Verifier sees valid, harmless code:
> [ new RegExp("[") ] / new RegExp("alert('toast')]") + 1
>
> Browser runs exploit code:
> [ new RegExp("[\/]") / alert('toast') ] / +1
>
> Since there's no way that I could reliably have known about the IE lexer
> bug, it's just too risky.
>
> Anyone know of other bugs where common JS implementations lex or parse
> valid ES3 code with a different meaning than specified? (The only one
> I can think of right now is \v in IE, but at least that doesn't result
> in a parse with a different structure.)

Plenty.  But I suspect you know of them.  There's conditional
compilation comments /* @cc_on */,
  and there's the newlines in block comments thing return /*
*/ foo();
and there's format control characters between pairs like */ and \".
There's other tricks you can do with \u escapes in identifiers and NUL
and BOM characters in source.



> --
> David-Sarah Hopwood ⚥

On Feb 10, 2009, at 6:36 PM, Mike Samuel wrote:
> and there's the newlines in block comments thing return /*
> */ foo();
>

Fixed in Firefox 3.1 beta nightlies:

https://bugzilla.mozilla.org/show_bug.cgi?id=475834

We could push the fix back into a 3.0.x maintenance release if it
would help. Anyone with https://bugzilla.mozilla.org editbugs
permission who wants this, feel free to nominate the patch for approval.

/be

Suppose that S is a Unicode string in which each character matches
ValidChar below, not containing the subsequences "<!", "</" or "]]>", and
not containing ("&" followed by a character not matching AmpFollower).
S encodes a syntactically correct ES3 or ES3.1 source text chosen by
an attacker.

   ValidChar :: one of
     '\u0009' '\u000A' '\u000D' // TAB, LF, CR
     [\u0020-\u007E]
     [\u00A0-\u00AC]
     [\u00AE-\u05FF]
     [\u0604-\u06DC]
     [\u06DE-\u070E]
     [\u0710-\u17B3]
     [\u17B6-\u200A]
     [\u2010-\u2027]
     [\u202F-\u205F]
     [\u2070-\uD7FF]
     [\uE000-\uFDCF]
     [\uFDF0-\uFEFE]
     [\uFF00-\uFFEF]

   AmpFollower :: one of
     '=' '(' '+' '-' '!' '~' '"' '/' [0-9]
     '\u0027' '\u005C' '\u0020' '\u0009' '\u000A' \u000D'
     // single quote, backslash, space, TAB, LF, CR

(ValidChar excludes format control characters, and some other
characters known to be mishandled by browsers. AmpFollower is
intended to exclude characters that can start an entity reference.)

S is inserted between "<script>" and "</script>" in a place where a
<script> tag is allowed in an otherwise valid HTML document, or
between "<script><![CDATA[" and "]]></script>" in a place where a
<script> tag is allowed in an otherwise valid XHTML document.
The HTML or XHTML document starts with a correct <!DOCTYPE or
<?xml declaration respectively, and is encoded as well-formed
UTF-8.


Are these restrictions sufficient to ensure that the embedded
script is interpreted as it would have been if referenced from
an external file, foiling any attempts of browsers to collude
with the attacker in misparsing it?

Are some of the restrictions unnecessary?

--
David-Sarah Hopwood ⚥

No, I'm not paranoid enough yet. It's not sufficient only to say
that the HTML is encoded as UTF-8 (see below).

David-Sarah Hopwood wrote:
[...]
> The HTML or XHTML document starts with a correct <!DOCTYPE or
> <?xml declaration respectively,

I meant, the document starts with <!DOCTYPE HTML> in the case
of HTML, or <?xml version="1.0"?><!DOCTYPE HTML> in the case of
XHTML.

(This will also put the parser into sane^H^H^H^Hstandards mode.)

> and is encoded as well-formed UTF-8.

The document must also start with a UTF-8 BOM, *and* must not
contain a META directive that changes the charset, *and* in the
case of HTML, must either be retrieved from a local file or over
HTTP with the header "Content-Type: text/html; charset=UTF-8".
This is because the method of determining the encoding is chosen
based on the phase of the moon.

Any other problems?

--
David-Sarah Hopwood ⚥

2009/2/16 David-Sarah Hopwood <david.hopwood@...>
>
> Suppose that S is a Unicode string in which each character matches
> ValidChar below, not containing the subsequences "<!", "</" or "]]>", and
> not containing ("&" followed by a character not matching AmpFollower).
> S encodes a syntactically correct ES3 or ES3.1 source text chosen by
> an attacker.
>
> ValidChar :: one of
> '\u0009' '\u000A' '\u000D' // TAB, LF, CR
> [\u0020-\u007E]
> [\u00A0-\u00AC]
> [\u00AE-\u05FF]
> [\u0604-\u06DC]
> [\u06DE-\u070E]
> [\u0710-\u17B3]
> [\u17B6-\u200A]
> [\u2010-\u2027]
> [\u202F-\u205F]
> [\u2070-\uD7FF]

So no surrogates?

> [\uE000-\uFDCF]
> [\uFDF0-\uFEFE]
> [\uFF00-\uFFEF]

Why include FFEF?

> AmpFollower :: one of
> '=' '(' '+' '-' '!' '~' '"' '/' [0-9]
> '\u0027' '\u005C' '\u0020' '\u0009' '\u000A' \u000D'
> // single quote, backslash, space, TAB, LF, CR
>
> (ValidChar excludes format control characters, and some other
> characters known to be mishandled by browsers. AmpFollower is
> intended to exclude characters that can start an entity reference.)
>
> S is inserted between "<script>" and "</script>" in a place where a
> <script> tag is allowed in an otherwise valid HTML document, or
> between "<script><![CDATA[" and "]]></script>" in a place where a
> <script> tag is allowed in an otherwise valid XHTML document.
> The HTML or XHTML document starts with a correct <!DOCTYPE or
> <?xml declaration respectively, and is encoded as well-formed
> UTF-8.
>
> Are these restrictions sufficient to ensure that the embedded
> script is interpreted as it would have been if referenced from
> an external file, foiling any attempts of browsers to collude
> with the attacker in misparsing it?

You may still be subject to encoding attacks.  I'm sure there are
valid scripts that look like UTF-7, so if the script appears in the
first 1024B, you might need to make sure it's preceded by a <meta>
element specifying an encoding, and/or use the XML prologue form that
specifies an encoding.

> Are some of the restrictions unnecessary?
>
> --
> David-Sarah Hopwood ⚥

Mike Samuel wrote:
> 2009/2/16 David-Sarah Hopwood <david.hopwood@...>
>> Suppose that S is a Unicode string in which each character matches
>> ValidChar below, not containing the subsequences "<!", "</" or "]]>", and
>> not containing ("&" followed by a character not matching AmpFollower).
>> S encodes a syntactically correct ES3 or ES3.1 source text chosen by
>> an attacker.
>>
>> ValidChar :: one of
>> '\u0009' '\u000A' '\u000D' // TAB, LF, CR
>> [\u0020-\u007E]
>> [\u00A0-\u00AC]
>> [\u00AE-\u05FF]
>> [\u0604-\u06DC]
>> [\u06DE-\u070E]
>> [\u0710-\u17B3]
>> [\u17B6-\u200A]
>> [\u2010-\u2027]
>> [\u202F-\u205F]
>> [\u2070-\uD7FF]
>
> So no surrogates?

Correct. They're not characters (or even "noncharacters").

>> [\uE000-\uFDCF]
>> [\uFDF0-\uFEFE]
>> [\uFF00-\uFFEF]
>
> Why include FFEF?

It's unassigned, and there's no particular reason to exclude it.
(\uFFF0-\uFFF8 are also unassigned, but that's an area reserved
for "special" characters.)

>> AmpFollower :: one of
>> '=' '(' '+' '-' '!' '~' '"' '/' [0-9]
>> '\u0027' '\u005C' '\u0020' '\u0009' '\u000A' \u000D'
>> // single quote, backslash, space, TAB, LF, CR
>>
>> (ValidChar excludes format control characters, and some other
>> characters known to be mishandled by browsers. AmpFollower is
>> intended to exclude characters that can start an entity reference.)
>>
>> S is inserted between "<script>" and "</script>" in a place where a
>> <script> tag is allowed in an otherwise valid HTML document, or
>> between "<script><![CDATA[" and "]]></script>" in a place where a
>> <script> tag is allowed in an otherwise valid XHTML document.
>> The HTML or XHTML document starts with a correct <!DOCTYPE or
>> <?xml declaration respectively, and is encoded as well-formed
>> UTF-8.
>>
>> Are these restrictions sufficient to ensure that the embedded
>> script is interpreted as it would have been if referenced from
>> an external file, foiling any attempts of browsers to collude
>> with the attacker in misparsing it?
>
> You may still be subject to encoding attacks.  I'm sure there are
> valid scripts that look like UTF-7, so if the script appears in the
> first 1024B, you might need to make sure it's preceded by a <meta>
> element specifying an encoding, and/or use the XML prologue form that
> specifies an encoding.

Right; I covered that in a follow-up. Is including a UTF-8 BOM at the
start sufficient for all browsers (that is, are there any browsers
in which a <meta> tag or other content sniffing can override an
explicit initial UTF-8 BOM, in either HTML or XHTML)?

HTML5 section 8.2.2.1 seems to indicate that "if the transport layer
specifies an encoding" (i.e. presumably the charset specified in
a Content-Type header), then that should override a BOM. That's
irritating, because it means that you have to assume that the server
gets the Content-Type right, *as well as* including a BOM for the
browsers in which Content-Type doesn't override sniffing
(Internet Explorer, at least), and for the case where the document
is read from a local file.

--
David-Sarah Hopwood ⚥

2009/2/17 David-Sarah Hopwood <david.hopwood@...>:
> Mike Samuel wrote:
>> 2009/2/16 David-Sarah Hopwood <david.hopwood@...>
>>> Suppose that S is a Unicode string in which each character matches
>>> ValidChar below, not containing the subsequences "<!", "</" or "]]>", and
>>> not containing ("&" followed by a character not matching AmpFollower).
>>> S encodes a syntactically correct ES3 or ES3.1 source text chosen by
>>> an attacker.
>>>
>>> ValidChar :: one of
>>> '\u0009' '\u000A' '\u000D' // TAB, LF, CR
>>> [\u0020-\u007E]
>>> [\u00A0-\u00AC]
>>> [\u00AE-\u05FF]
>>> [\u0604-\u06DC]
>>> [\u06DE-\u070E]
>>> [\u0710-\u17B3]
>>> [\u17B6-\u200A]
>>> [\u2010-\u2027]
>>> [\u202F-\u205F]
>>> [\u2070-\uD7FF]
>>
>> So no surrogates?
>
> Correct. They're not characters (or even "noncharacters").
>
>>> [\uE000-\uFDCF]
>>> [\uFDF0-\uFEFE]
>>> [\uFF00-\uFFEF]
>>
>> Why include FFEF?
>
> It's unassigned, and there's no particular reason to exclude it.
> (\uFFF0-\uFFF8 are also unassigned, but that's an area reserved
> for "special" characters.)

Isn't it the reflection of fffe, the byte-order-marker.
This is probably a very minor issue, but if one part of a parser
naively delegates to another parser that mistakenly treats its content
as a byte string instead of code units, the presence of a BOM might
cause the delegatee to misinterpret content when something that looks
like a BOM appears at the beginning of a chunk of embedded language.


>>> AmpFollower :: one of
>>> '=' '(' '+' '-' '!' '~' '"' '/' [0-9]
>>> '\u0027' '\u005C' '\u0020' '\u0009' '\u000A' \u000D'
>>> // single quote, backslash, space, TAB, LF, CR
>>>
>>> (ValidChar excludes format control characters, and some other
>>> characters known to be mishandled by browsers. AmpFollower is
>>> intended to exclude characters that can start an entity reference.)
>>>
>>> S is inserted between "<script>" and "</script>" in a place where a
>>> <script> tag is allowed in an otherwise valid HTML document, or
>>> between "<script><![CDATA[" and "]]></script>" in a place where a
>>> <script> tag is allowed in an otherwise valid XHTML document.
>>> The HTML or XHTML document starts with a correct <!DOCTYPE or
>>> <?xml declaration respectively, and is encoded as well-formed
>>> UTF-8.
>>>
>>> Are these restrictions sufficient to ensure that the embedded
>>> script is interpreted as it would have been if referenced from
>>> an external file, foiling any attempts of browsers to collude
>>> with the attacker in misparsing it?
>>
>> You may still be subject to encoding attacks. I'm sure there are
>> valid scripts that look like UTF-7, so if the script appears in the
>> first 1024B, you might need to make sure it's preceded by a <meta>
>> element specifying an encoding, and/or use the XML prologue form that
>> specifies an encoding.
>
> Right; I covered that in a follow-up. Is including a UTF-8 BOM at the
> start sufficient for all browsers (that is, are there any browsers
> in which a <meta> tag or other content sniffing can override an
> explicit initial UTF-8 BOM, in either HTML or XHTML)?

Ah cool.  I don't know the answer to that question.


> HTML5 section 8.2.2.1 seems to indicate that "if the transport layer
> specifies an encoding" (i.e. presumably the charset specified in
> a Content-Type header), then that should override a BOM. That's
> irritating, because it means that you have to assume that the server
> gets the Content-Type right, *as well as* including a BOM for the
> browsers in which Content-Type doesn't override sniffing
> (Internet Explorer, at least), and for the case where the document
> is read from a local file.

Yeah.  I think the best thing to do is to use a fairly standard
encoding like UTF-8, and make sure the XML prologue, <meta
http-equiv="content-type">, and headers all agree.

I don't think that you can do much about file hosting services that go
out of their way to specify a whacky encoding.  Putting a BOM at the
front will help hosting services that make a genuine effort.


> --
> David-Sarah Hopwood ⚥
>
>

Mike Samuel wrote:
> 2009/2/17 David-Sarah Hopwood <david.hopwood@...>:
>> Mike Samuel wrote:
>>> 2009/2/16 David-Sarah Hopwood <david.hopwood@...>
>>>> ValidChar :: one of
[...]
>>>> [\uFF00-\uFFEF]
>>> Why include FFEF?
>> It's unassigned, and there's no particular reason to exclude it.
>> (\uFFF0-\uFFF8 are also unassigned, but that's an area reserved
>> for "special" characters.)
>
> Isn't it the reflection of fffe, the byte-order-marker.

No, \uFEFF is the BOM, and its byte-reflection \uFFFE is a noncharacter,
so already excluded from ValidChar.

(Thought you'd spotted something I'd missed for a second, there.)

--
David-Sarah Hopwood ⚥

2009/2/18 David-Sarah Hopwood <david.hopwood@...>:
> Mike Samuel wrote:
>> 2009/2/17 David-Sarah Hopwood <david.hopwood@...>:
>>> Mike Samuel wrote:
>>>> 2009/2/16 David-Sarah Hopwood <david.hopwood@...>
>>>>> ValidChar :: one of
> [...]
>>>>> [\uFF00-\uFFEF]
>>>> Why include FFEF?
>>> It's unassigned, and there's no particular reason to exclude it.
>>> (\uFFF0-\uFFF8 are also unassigned, but that's an area reserved
>>> for "special" characters.)
>>
>> Isn't it the reflection of fffe, the byte-order-marker.
>
> No, \uFEFF is the BOM, and its byte-reflection \uFFFE is a noncharacter,
> so already excluded from ValidChar.

Ah, quite right.

> (Thought you'd spotted something I'd missed for a second, there.)
>
> --
> David-Sarah Hopwood ⚥

Previous W2SP Workshops: 2008, 2007

The goal of this one day workshop is to bring together researchers and practitioners from academia and industry to focus on understanding Web 2.0 security and privacy issues, and establishing new collaborations in these areas.

Web 2.0 is about connecting people and amplifying the power of working together. Enabled by a wave of new technology, these social and business interactions rely on composition of content and services from multiple sources, commonly called mash-ups, leading to systems with complex trust boundaries. This trend is likely to continue because individuals and businesses desire the efficiency and simplicity these technologies offer.

Together with their virtues, these technologies raise issues about management of identities, reputation, privacy, anonymity, transient and long term relationships, and composition of function and content, both on the server and on the client (web browser). Although the underlying security and privacy issues are not new, the use of these technologies on a wide scale and by a broad audience raises new questions. This workshop is intended to discuss the limitations of current technologies and explore alternatives.

The scope of W2SP 2009 includes, but is not limited to:

• Trustworthy cloud-based services
• Privacy and reputation in social networks
• Usable security and privacy
• Security for the mobile web
• Identity management and psuedonymity
• Advertisement and affiliate fraud
• Provenance and governance
• Security and privacy as a service
• Web services/feeds/mashups
• Security and privacy policies for composible content
• Next-generation browser technology

Workshop Co-Chairs

• Larry Koved (IBM Research)
• Dan S. Wallach (Rice University)

• Adam Barth (UC Berkeley)

• Ben Adida (Harvard University)
• Dirk Balfanz (PARC)
• Adam Barth (UC Berkeley)
• Konstantin (Kosta) Beznosov
• Suresh Chari (IBM Research)
• Hao Chen (UC Davis)
• Douglas Crockford (Yahoo)
• Chris Karlof (UC Berkeley)
• Larry Koved (IBM Research)
• Shriram Krishnamurthi (Brown University)
• Collin Jackson (Stanford University)
• Rob Johnson (Stony Brook University)
• John C. Mitchell (Stanford University)
• Sean W. Smith (Dartmouth University)
• Helen Wang (Microsoft Research)
• Dan S. Wallach (Rice University)

Paper submission deadline: March 6, 2009, (11:59pm US-Eastern)
Workshop acceptance notification date: March 31, 2009
Workshop date: Thursday, May 21, 2009

Workshop paper submission web site: http://w2spconf.com/2009/