Editorial Update: Signature Properties
fyi, I've updated Signature Properties editors draft to include links to a standalone Signature example XML file showing all properties (without crypto) , and standalone XML Schema file (thanks to Scott Cantor for getting the schema right). No change to the Role or Profile as we have had to date. This should not break any implementations but make it easier to find and work with the schema. Comments/corrections welcome. Thanks regards, Frederick Frederick Hirsch Nokia Begin forwarded message: From: Hirsch Frederick (Nokia-CIC/Boston) frederick.hir...@nokia.com Date: January 8, 2010 8:39:27 AM EST To: XMLSec WG Public List public-xml...@w3.org Cc: Hirsch Frederick (Nokia-CIC/Boston) frederick.hir...@nokia.com Subject: Editorial Update: Signature Properties I have updated the SIgnature Properties editors draft [1] with the following changes : 1. Added new Schema section, with link to standalone XSD schema document and example XML document. 2. Updated schema portions in document with corrections from Scott, also changed format to remove Example notation. 3. Added place holder for RNG schema 4. Added Reference for Schema Part 1, internal update for consistency in references. Much thanks to Scott for updating the schema (same meaning but revised to be valid schema). regards, Frederick Frederick Hirsch Nokia [1] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/Overview.html
Introducing Rokesh Jankie, for the Web Applications groups
Hi, on request of Arthur Bartstow, I will introduce myself to the group. My name is Rokesh Jankie and I'm the lead of a product called QAFE. In QAFE we have developed a language called QAML, QAFE's Markup Language and allows you to create web (Web2.0) applications with interaction with your backend. We abstracted from any specific technology and even the event handling, business processing part is integrated and all in XML format. The reason why we joined this group, because we think the model that we created is totally new and innovative. We wanted you to also have a look at it, especially the QAML. Feel free to contact me if there are questions. Kind regards, Rokesh Jankie Website : http://www.qafe.com/
[UMP] Feedback on UMP from a quick read
[[ In particular, the user agent should not add the HTTP headers: User-Agent, Accept, Accept-Language, Accept-Encoding, or Accept-Charset ]] This seems a bit overly constrictive. Maybe we should send Accept: */*, etc? More generally, I suspect the requirements in Section 3.2 violate various HTTP RFCs. Maybe we should use the term willful violation somewhere? [[ If the response to a uniform request is an HTTP redirect, it is handled as specified by [HTTP], whether or not the redirect is itself a uniform response. If the redirect is not a uniform response, the user-agent must still prevent the requesting content from accessing the content of the redirect itself, though a response to a redirected request might be accessible if it is a uniform response. If the response to a uniform request is an HTTP redirect, any redirected request must also be a uniform request. ]] This seems looser than needed. It would be better if the redirect had to be a uniform response also. There's a note in the spec The HTML form element can also follow any redirect, without restriction by the Same Origin Policy, but the form element also sends Accept and User-Agent headers. What's the reason for excluding the headers but not requiring redirects to be uniform responses? What happens with Set-Cookie headers included in uniform responses? It seems like we ought to ignore them based on the principle that UMP requests are made from a state store / context that is completely separate from the user agents normal state store / context. Adam
File API: Blob and underlying file changes.
Hi, Does the Blob, which is obtained as File (so it refers to an actual file on disk) track the changes in the underlying file and 'mutates', or does it represent the 'snapshot' of the file, or does it become 'invalid'? Today, if a user selects a file using input type=file, and then the file on the disk changes before the 'submit' is clicked, the form will submit the latest version of the file. This may be a surprisingly popular use case, when user submits a file via form and wants to do 'last moment' changes in the file, after partial pre-populating the form. It works 'intuitively' today. Now, if the page decides to use XHR to upload the file, I think var file = myInputElement.files[0]; var xhr = ... xhr.send(file); should also send the version of the file that exists at the moment of xhr.send(file), not when user picked the file (for consistency with form action). Assuming this is desired behavior, what should the following do: var file = myInputElement.files[0]; var blob = file.slice(0, file.size); // ... now file on the disk changes ... xhr.send(blob); Will it: - send the new version of the whole file (and update blob.size?) - send captured number of bytes from the new version of the file (perhaps truncated since file may be shorter now) - send original bytes from the previous version of the file that existed when Blob was created (sort of 'copy on write') - throw exception ? Thanks, Dmitry
Re: [UMP] Feedback on UMP from a quick read
One more question: the draft doesn't seem to provide any way to generate a uniform request. Are we planning to have another specification for an API for generating these requests? Adam On Fri, Jan 8, 2010 at 1:41 PM, Adam Barth w...@adambarth.com wrote: [[ In particular, the user agent should not add the HTTP headers: User-Agent, Accept, Accept-Language, Accept-Encoding, or Accept-Charset ]] This seems a bit overly constrictive. Maybe we should send Accept: */*, etc? More generally, I suspect the requirements in Section 3.2 violate various HTTP RFCs. Maybe we should use the term willful violation somewhere? [[ If the response to a uniform request is an HTTP redirect, it is handled as specified by [HTTP], whether or not the redirect is itself a uniform response. If the redirect is not a uniform response, the user-agent must still prevent the requesting content from accessing the content of the redirect itself, though a response to a redirected request might be accessible if it is a uniform response. If the response to a uniform request is an HTTP redirect, any redirected request must also be a uniform request. ]] This seems looser than needed. It would be better if the redirect had to be a uniform response also. There's a note in the spec The HTML form element can also follow any redirect, without restriction by the Same Origin Policy, but the form element also sends Accept and User-Agent headers. What's the reason for excluding the headers but not requiring redirects to be uniform responses? What happens with Set-Cookie headers included in uniform responses? It seems like we ought to ignore them based on the principle that UMP requests are made from a state store / context that is completely separate from the user agents normal state store / context. Adam
Re: [UMP] Feedback on UMP from a quick read
On Fri, Jan 8, 2010 at 1:41 PM, Adam Barth w...@adambarth.com wrote: [[ In particular, the user agent should not add the HTTP headers: User-Agent, Accept, Accept-Language, Accept-Encoding, or Accept-Charset ]] This seems a bit overly constrictive. Maybe we should send Accept: */*, etc? More generally, I suspect the requirements in Section 3.2 violate various HTTP RFCs. Maybe we should use the term willful violation somewhere? Which RFCs are you referring to? AFAIK, Section 3.2 doesn't violate any MUST requirement in any relevant RFC. There are two uses for this requirement: 1. On browsers that don't yet support any cross-domain API, it would be nice to emulate support by routing the request through the requestor's Origin server. To help ensure the response is the same whether it was sent directly from the user agent or via the Origin server, we omit any information about the sending software. 2. Omitting these headers can significantly reduce message size and so improve performance. [[ If the response to a uniform request is an HTTP redirect, it is handled as specified by [HTTP], whether or not the redirect is itself a uniform response. If the redirect is not a uniform response, the user-agent must still prevent the requesting content from accessing the content of the redirect itself, though a response to a redirected request might be accessible if it is a uniform response. If the response to a uniform request is an HTTP redirect, any redirected request must also be a uniform request. ]] This seems looser than needed. It would be better if the redirect had to be a uniform response also. There's a note in the spec The HTML form element can also follow any redirect, without restriction by the Same Origin Policy, but the form element also sends Accept and User-Agent headers. What's the reason for excluding the headers but not requiring redirects to be uniform responses? Somewhere in the list archives, I believe there's a message that pointed out a need to remain compatible with existing HTTP redirection software that cannot be (or won't be) updated to include the new header. For example, if the page receives a URL from a URL shortening service, it would be nice to be able to complete the request even if the URL shortening service doesn't return uniform response redirects. The form argument makes it clear that following a non-uniform redirect doesn't introduce a security vulnerability. AFAICT, this feature also doesn't lead the resource author into any poor design choices. It's a good thing to question, since this feature is a relaxation of the model, but it seems valuable and without risk. Can you think of a danger here? What happens with Set-Cookie headers included in uniform responses? It seems like we ought to ignore them based on the principle that UMP requests are made from a state store / context that is completely separate from the user agents normal state store / context. That's a good point. I'll add text to that effect. Thanks, --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [UMP] Feedback on UMP from a quick read
On Fri, Jan 8, 2010 at 2:53 PM, Adam Barth w...@adambarth.com wrote: One more question: the draft doesn't seem to provide any way to generate a uniform request. Are we planning to have another specification for an API for generating these requests? Similar to CORS, UMP is just the security model; separate API specs define the API for making requests under that model. So, as XHR2 is to CORS, a yet-to-come UniformRequest is to UMP. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [UMP] Feedback on UMP from a quick read
On Fri, Jan 8, 2010 at 3:36 PM, Tyler Close tyler.cl...@gmail.com wrote: There are two uses for this requirement: 1. On browsers that don't yet support any cross-domain API, it would be nice to emulate support by routing the request through the requestor's Origin server. To help ensure the response is the same whether it was sent directly from the user agent or via the Origin server, we omit any information about the sending software. If this is an important consideration, then the server software can just copy the relevant headers. I'm not sure there's a good security case to be made here for deviating from standard operating procedure. It seems quite sensible to send an Accept header of */* instead of omitting the header. 2. Omitting these headers can significantly reduce message size and so improve performance. This seems like premature optimization to me. Do you have benchmarks that show this has any impact on page load time (or any other metric you think is interesting)? [... Requiring uniform responses to redirects ...] It's a good thing to question, since this feature is a relaxation of the model, but it seems valuable and without risk. Can you think of a danger here? Here's an obscure risk: 1) An enterprise (example.com) has a partially open redirector (go.corp.example.com) behind their firewall 2) The redirector will only redirect to *.example.com 3) There is a public site api.example.com that opts into UMP Now the attacker can probe go.corp.example.com by asking for redirects to api.example.com and reading back the response. This is especially problematic if the redirector attaches interesting bits to the URLs it directs (like API keys). This attack is not possible with the form element. Adam
Re: [UMP] Feedback on UMP from a quick read
On Fri, Jan 8, 2010 at 3:56 PM, Adam Barth w...@adambarth.com wrote: On Fri, Jan 8, 2010 at 3:36 PM, Tyler Close tyler.cl...@gmail.com wrote: There are two uses for this requirement: 1. On browsers that don't yet support any cross-domain API, it would be nice to emulate support by routing the request through the requestor's Origin server. To help ensure the response is the same whether it was sent directly from the user agent or via the Origin server, we omit any information about the sending software. If this is an important consideration, then the server software can just copy the relevant headers. I'm not sure there's a good security case to be made here for deviating from standard operating procedure. It seems quite sensible to send an Accept header of */* instead of omitting the header. I'm not making a security argument here, just an engineering one. It seems simpler and more efficient this way. 2. Omitting these headers can significantly reduce message size and so improve performance. This seems like premature optimization to me. Do you have benchmarks that show this has any impact on page load time (or any other metric you think is interesting)? Reading Steve Souders stuff has impressed upon me the cost of message size overhead. If you just open up a Firebug console, it's clear that these headers are eating up a significant fraction of the MTU and so splitting messages that should've gone over the wire in a single packet. All that said, perhaps it makes more sense to move this recommendation to individual UMP API specs, such as UniformRequest, rather than deal with it in the UMP spec, leaving it as purely about the security model. At the very least, that delays the controversy. I'll remove the text from the UMP spec. [... Requiring uniform responses to redirects ...] It's a good thing to question, since this feature is a relaxation of the model, but it seems valuable and without risk. Can you think of a danger here? Here's an obscure risk: 1) An enterprise (example.com) has a partially open redirector (go.corp.example.com) behind their firewall 2) The redirector will only redirect to *.example.com 3) There is a public site api.example.com that opts into UMP Now the attacker can probe go.corp.example.com by asking for redirects to api.example.com and reading back the response. I actually considered that case and convinced myself that the attacker *could* mount the attack using a form or iframe by timing the request. A working redirect will likely take longer to return than a broken redirect. Also, the attack can work without timing, but using a script tag, if the response can be parsed as ECMAScript. This is especially problematic if the redirector attaches interesting bits to the URLs it directs (like API keys). This attack is not possible with the form element. Any unguessable bits in the redirect URL should not be revealed, since the attacker does not get access to the non-uniform redirect response, even if the final response is a uniform response. This design is also already dangerous, since using a form tag, the attacker can already freely exercise these API keys. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [UMP] Feedback on UMP from a quick read
On Fri, Jan 8, 2010 at 4:43 PM, Tyler Close tyler.cl...@gmail.com wrote: On Fri, Jan 8, 2010 at 3:56 PM, Adam Barth w...@adambarth.com wrote: [... Requiring uniform responses to redirects ...] It's a good thing to question, since this feature is a relaxation of the model, but it seems valuable and without risk. Can you think of a danger here? Here's an obscure risk: 1) An enterprise (example.com) has a partially open redirector (go.corp.example.com) behind their firewall 2) The redirector will only redirect to *.example.com 3) There is a public site api.example.com that opts into UMP Now the attacker can probe go.corp.example.com by asking for redirects to api.example.com and reading back the response. I actually considered that case and convinced myself that the attacker *could* mount the attack using a form or iframe by timing the request. A working redirect will likely take longer to return than a broken redirect. Also, the attack can work without timing, but using a script tag, if the response can be parsed as ECMAScript. This is especially problematic if the redirector attaches interesting bits to the URLs it directs (like API keys). This attack is not possible with the form element. Any unguessable bits in the redirect URL should not be revealed, since the attacker does not get access to the non-uniform redirect response, even if the final response is a uniform response. This design is also already dangerous, since using a form tag, the attacker can already freely exercise these API keys. You're assuming the API keys are for integrity. What if they're for confidentiality? Adam
Re: File API: Blob and underlying file changes.
Adding reply from Jonas Sicking from anther list (which I used first by mistake :( ) Technically, you should send this email to the webapps mailing list, since that is where this spec is being developed. That said, this is a really hard problem, and one that is hard to test. One thing that we decided when we did security review on this stuff at mozilla is that if a File object is ever passed cross origin using postMessage, then the File object that the other origin has should not work if the file is changed on disc. For some definition of not work. On Fri, Jan 8, 2010 at 2:21 PM, Dmitry Titov dim...@chromium.org wrote: Hi, Does the Blob, which is obtained as File (so it refers to an actual file on disk) track the changes in the underlying file and 'mutates', or does it represent the 'snapshot' of the file, or does it become 'invalid'? Today, if a user selects a file using input type=file, and then the file on the disk changes before the 'submit' is clicked, the form will submit the latest version of the file. This may be a surprisingly popular use case, when user submits a file via form and wants to do 'last moment' changes in the file, after partial pre-populating the form. It works 'intuitively' today. Now, if the page decides to use XHR to upload the file, I think var file = myInputElement.files[0]; var xhr = ... xhr.send(file); should also send the version of the file that exists at the moment of xhr.send(file), not when user picked the file (for consistency with form action). Assuming this is desired behavior, what should the following do: var file = myInputElement.files[0]; var blob = file.slice(0, file.size); // ... now file on the disk changes ... xhr.send(blob); Will it: - send the new version of the whole file (and update blob.size?) - send captured number of bytes from the new version of the file (perhaps truncated since file may be shorter now) - send original bytes from the previous version of the file that existed when Blob was created (sort of 'copy on write') - throw exception ? Thanks, Dmitry
