Security bug in XmlHttpRequest, setRequestHeader()
Kusuke Ebihara (Ikousuke at co3k.org ) has discovered an interesting security bug with XHR. http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2012-January/008170.html Basically, for CGI programs, characters that are valid in HTTP headers but not in Unix shell environment variables are commonly all coerced to "_". This allows bypass of the security restrictions in http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader-method, section 5. If an application sets, e.g. a header of "User_Agent" (or in some cases "User.Agent", "User*Agent", etc...), that is indistinguishable when delivered to a CGI application from the forbidden "User-Agent". As this behavior is at least partially formally documented in http://tools.ietf.org/html/rfc3875#section-4.1.18 , and very widely implemented, the algorithm for XHR should be updated to at least consider "_", and possibly all non-alphanumeric characters, as equivalent to "-" for purposes of comparison to the blacklisted header set. Brad Hill Sr. MTS, Internet Standards and Governance PayPal Information Risk Management cell: 206.245.7844 / skype: hillbrad email: bh...@paypal-inc.com
[Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15434 Summary: [IndexedDB] Detail steps for assigning a key to a value Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jsb...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org In section 5.1 "Object Store Storage Operation", step 2: when a key generator is used with store with in line keys, the spec says: "set the property in value pointed to by store's key path to the new value for key" The "steps for extracting a key from a value using a key path" are called out explicitly under Algorithms in 4.7. Should the steps for assigning a key to a value using a key path be similarly documented? Cribbing from the spec, this could read as: 4.X Steps for assigning a key to a value using a key path When taking the steps for assigning a key to a value using a key path, the implementation must run the following algorithm. The algorithm takes a key path named /keyPath/, a key named /key/, and a value named /value/ which may be modified by the steps of the algorithm. 1. If /keyPath/ is the empty string, skip the remaining steps and /value/ is not modified. 2. Let /remainingKeypath/ be /keyPath/ and /object/ be /value/. 3. If /remainingKeypath/ has a period in it, assign /remainingKeypath/ to be everything after the first period and assign /attribute/ to be everything before that first period. Otherwise, go to step 7. 4. If /object/ does not have an attribute named /attribute/, then skip the rest of these steps and /value/ is not modified. 5. Assign /object/ to be the /value/ of the attribute named /attribute/ on /object/. 6. Go to step 3. 7. NOTE: The steps leading here ensure that /remainingKeyPath/ is a single attribute name (i.e. string without periods) by this step. 8. Let /attribute/ be /remainingKeyPath/ 9. If /object/ has an attribute named /attribute/ which is not modifiable, then skip the remaining steps and /value/ is not modified. 10. Set an attribute named /attribute/ on /object/ with the value /key/. Notes: The above talks in terms of a mutable value. It could be amended to have an initial step which produces a clone of the value, which is later returned, but given how this algorithm is used the difference is not observable, since the value stored should already be a clone that doesn't have any other references. Step 9 is present in case the key path refers to a "special" property, e.g. a String/Array length, Blob/File properties, etc. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Affiliation change
This is just a heads-up that as of the new year, I'm contracting for Mozilla instead of Google. I'll continue to work on specifications and tests as before, in particular including the HTML Editing specification.
Re: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization
> > 2) How does the draft incorporate with the existing > API[1]? It seems to me as if it'd be best to define both the attribute > as the DOM APIs in a single specification, also because they share > several events (yet don't seem to be interchangeable) and the > attribute already has an implementation. > The API proposal was implemented as in Chromium a while ago. A lot of the developer feedback we received was about finer grained control including a javascript API and letting the web application decide how to present the user interface rather than tying it to the element. The HTML Speech Incubator Group's final report [1] includes a element which addresses both these concerns and provides automatic binding of speech recognition results to existing HTML elements. We are not sure if the WebApps WG is a good place to work on standardising such markup elements, hence did not include in the simplified Javascript API [2]. If there is sufficient interest and scope in the WebApps WG charter for the Javascript API and markup, we are happy to combine them both in the proposal. [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html > > Thanks, > Peter > > [1] > http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Feb/att-0020/api-draft.html > > On Thu, Jan 5, 2012 at 07:15, Glen Shires wrote: > > As Dan Burnett wrote below: The HTML Speech Incubator Group [1] has > recently > > wrapped up its work on use cases, requirements, and proposals for adding > > automatic speech recognition (ASR) and text-to-speech (TTS) capabilities > to > > HTML. The work of the group is documented in the group's Final Report. > [2] > > The members of the group intend this work to be input to one or more > > working groups, in W3C and/or other standards development organizations > such > > as the IETF, as an aid to developing full standards in this space. > > > > Because that work was so broad, Art Barstow asked (below) for > a relatively > > specific proposal. We at Google are proposing that a subset of it be > > accepted as a work item by the Web Applications WG. Specifically, we are > > proposing this Javascript API [3], which enables web developers to > > incorporate speech recognition and synthesis into their web pages. > > This simplified subset enables developers to use scripting to generate > > text-to-speech output and to use speech recognition as an input for > forms, > > continuous dictation and control, and it supports the majority of > use-cases > > in the Incubator Group's Final Report. > > > > We welcome your feedback and ask that the Web Applications WG > > consider accepting this Javascript API [3] as a work item. > > > > [1] charter: http://www.w3.org/2005/Incubator/htmlspeech/charter > > [2] report: http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ > > [3] > > API: > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html > > > > Bjorn Bringert > > Satish Sampath > > Glen Shires > > > > On Thu, Dec 22, 2011 at 11:38 AM, Glen Shires > wrote: > >> > >> Milan, > >> The IDLs contained in both documents are in the same format and order, > so > >> it's relatively easy to compare the two side-by-side. The semantics of > the > >> attributes, methods and events have not changed, and both IDLs link > directly > >> to the definitions contained in the Speech XG Final Report. > >> > >> As you mention, we agree that the protocol portions of the Speech XG > Final > >> Report are most appropriate for consideration by a group such as IETF, > and > >> believe such work can proceed independently, particularly because the > Speech > >> XG Final Report has provided a roadmap for these to remain compatible. > >> Also, as shown in the Speech XG Final Report - Overview, the "Speech > Web > >> API" is not dependent on the "Speech Protocol" and a "Default Speech" > >> service can be used for local or remote speech recognition and > synthesis. > >> > >> Glen Shires > >> > >> > >> On Thu, Dec 22, 2011 at 10:32 AM, Young, Milan > >> wrote: > >>> > >>> Hello Glen, > >>> > >>> > >>> > >>> The proposal says that it contains a “simplified subset of the > JavaScript > >>> API”. Could you please clarify which elements of the HTMLSpeech > >>> recommendation’s JavaScript API were omitted? I think this would be > the > >>> most efficient way for those of us familiar with the XG recommendation > to > >>> evaluate the new proposal. > >>> > >>> > >>> > >>> I’d also appreciate clarification on how you see the protocol being > >>> handled. In the HTMLSpeech group we were thinking about this as a > >>> hand-in-hand relationship between W3C and IETF like WebSockets. Is > this > >>> still your (and Google’s) vision? > >>> > >>> > >>> > >>> Thanks > >>> > >>> > >>> > >>> > >>> > >>> From: Glen Shires [mailto:gshi...@google.com] > >>> Sent: Thursday, December 22, 2011 11:14 AM > >>> To: public-webap
Re: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization
Hi Glen et al., I'd like to share two pieces of feedback which came to mind when reading through the unofficial draft. 1) The primary interfaces are abbreviated as "TTS" and "SpeechReco". Personally I believe it'd be clearer for authors when these would be defined as "TextToSpeech" and "SpeechRecognition". "TTS" may not be directly obvious for those who have no experience with similar systems, whereas cutting off in the middle of "Reco | gnition" just seems a bit odd. Is the benefit this provides being a shorter word, at the cost of clarity? 2) How does the draft incorporate with the existing API[1]? It seems to me as if it'd be best to define both the attribute as the DOM APIs in a single specification, also because they share several events (yet don't seem to be interchangeable) and the attribute already has an implementation. Thanks, Peter [1] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Feb/att-0020/api-draft.html On Thu, Jan 5, 2012 at 07:15, Glen Shires wrote: > As Dan Burnett wrote below: The HTML Speech Incubator Group [1] has recently > wrapped up its work on use cases, requirements, and proposals for adding > automatic speech recognition (ASR) and text-to-speech (TTS) capabilities to > HTML. The work of the group is documented in the group's Final Report. [2] > The members of the group intend this work to be input to one or more > working groups, in W3C and/or other standards development organizations such > as the IETF, as an aid to developing full standards in this space. > > Because that work was so broad, Art Barstow asked (below) for a relatively > specific proposal. We at Google are proposing that a subset of it be > accepted as a work item by the Web Applications WG. Specifically, we are > proposing this Javascript API [3], which enables web developers to > incorporate speech recognition and synthesis into their web pages. > This simplified subset enables developers to use scripting to generate > text-to-speech output and to use speech recognition as an input for forms, > continuous dictation and control, and it supports the majority of use-cases > in the Incubator Group's Final Report. > > We welcome your feedback and ask that the Web Applications WG > consider accepting this Javascript API [3] as a work item. > > [1] charter: http://www.w3.org/2005/Incubator/htmlspeech/charter > [2] report: http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ > [3] > API: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html > > Bjorn Bringert > Satish Sampath > Glen Shires > > On Thu, Dec 22, 2011 at 11:38 AM, Glen Shires wrote: >> >> Milan, >> The IDLs contained in both documents are in the same format and order, so >> it's relatively easy to compare the two side-by-side. The semantics of the >> attributes, methods and events have not changed, and both IDLs link directly >> to the definitions contained in the Speech XG Final Report. >> >> As you mention, we agree that the protocol portions of the Speech XG Final >> Report are most appropriate for consideration by a group such as IETF, and >> believe such work can proceed independently, particularly because the Speech >> XG Final Report has provided a roadmap for these to remain compatible. >> Also, as shown in the Speech XG Final Report - Overview, the "Speech Web >> API" is not dependent on the "Speech Protocol" and a "Default Speech" >> service can be used for local or remote speech recognition and synthesis. >> >> Glen Shires >> >> >> On Thu, Dec 22, 2011 at 10:32 AM, Young, Milan >> wrote: >>> >>> Hello Glen, >>> >>> >>> >>> The proposal says that it contains a “simplified subset of the JavaScript >>> API”. Could you please clarify which elements of the HTMLSpeech >>> recommendation’s JavaScript API were omitted? I think this would be the >>> most efficient way for those of us familiar with the XG recommendation to >>> evaluate the new proposal. >>> >>> >>> >>> I’d also appreciate clarification on how you see the protocol being >>> handled. In the HTMLSpeech group we were thinking about this as a >>> hand-in-hand relationship between W3C and IETF like WebSockets. Is this >>> still your (and Google’s) vision? >>> >>> >>> >>> Thanks >>> >>> >>> >>> >>> >>> From: Glen Shires [mailto:gshi...@google.com] >>> Sent: Thursday, December 22, 2011 11:14 AM >>> To: public-webapps@w3.org; Arthur Barstow >>> Cc: public-xg-htmlspe...@w3.org; Dan Burnett >>> >>> >>> Subject: Re: HTML Speech XG Completes, seeks feedback for eventual >>> standardization >>> >>> >>> >>> We at Google believe that a scripting-only (Javascript) subset of the API >>> defined in the Speech XG Incubator Group Final Report is of appropriate >>> scope for consideration by the WebApps WG. >>> >>> >>> >>> The enclosed scripting-only subset supports the majority of the use-cases >>> and samples in the XG proposal. Specifically, it enables web-pages to >>> generate speech output and to use speech recognition as an inpu
