On Tue, 19 May 2009, João Eiras wrote:
> >
> > How is this different from making two mutations per mutation event, or
> > calling postMessage() twice for each invokation of the 'message'
> > event, or loading two new iframes every time an iframe's 'load' event
> > fires?
>
> It's quite differe
On Tue, Jun 9, 2009 at 3:40 PM, Jonas Sicking wrote:
> I'm in general not a big fan of the redirect model in CORS, but this
> one especially seems like a problem. One solution would be to include
> the full redirect chain (or change the Origin to 'null') if
> redirecting across servers with a non-s
On Tue, Jun 9, 2009 at 3:40 PM, Jonas Sicking wrote:
> On Tue, Jun 9, 2009 at 3:05 PM, Tyler Close wrote:
>> On Tue, Jun 9, 2009 at 2:52 PM, Adam Barth wrote:
>>> On Tue, Jun 9, 2009 at 2:20 PM, Tyler Close wrote:
I had thought CORS, by it's use of Origin, was meant to be a safe
replaceme
On Tue, Jun 9, 2009 at 3:05 PM, Tyler Close wrote:
> On Tue, Jun 9, 2009 at 2:52 PM, Adam Barth wrote:
>> On Tue, Jun 9, 2009 at 2:20 PM, Tyler Close wrote:
>>> I had thought CORS, by it's use of Origin, was meant to be a safe
>>> replacement for JSON-P.
>>
>> Can you explain again how the attack w
On Tue, Jun 9, 2009 at 2:52 PM, Adam Barth wrote:
> On Tue, Jun 9, 2009 at 2:20 PM, Tyler Close wrote:
>> I had thought CORS, by it's use of Origin, was meant to be a safe
>> replacement for JSON-P.
>
> Can you explain again how the attack works for Origin-header-for-CORS?
> Keep in mind that the
On Tue, Jun 9, 2009 at 2:20 PM, Tyler Close wrote:
> I had thought CORS, by it's use of Origin, was meant to be a safe
> replacement for JSON-P.
Can you explain again how the attack works for Origin-header-for-CORS?
Keep in mind that the response is delivered to the original
requester, who should
On Tue, Jun 9, 2009 at 2:05 PM, Adam Barth wrote:
> On Tue, Jun 9, 2009 at 1:47 PM, Tyler Close wrote:
>> So if a page from Victim origin sends a request to Attacker origin
>> which is redirected to a URL at Victim origin, the server at Victim
>> origin receives a request with user credentials for
On Tue, Jun 9, 2009 at 1:47 PM, Tyler Close wrote:
> So if a page from Victim origin sends a request to Attacker origin
> which is redirected to a URL at Victim origin, the server at Victim
> origin receives a request with user credentials for Victim origin and
> an Origin header value for Victim o
The Origin I-D says the following about redirects:
"""
If a user agent issues an HTTP request in reaction to an HTTP
redirect, the Origin header MUST contain the same value as the Origin
header in the HTTP request that generated the redirect.
"""
So if a page from Victim origin sends a requ
On Tue, 09 Jun 2009 21:15:18 +0200, Tyler Close wrote:
> Could you provide a code example that shows how to send an XHR request
> to the same Origin without credentials using the HTML5
> element?
where ... is some page that does an XMLHttpRequest to the a page that is same
origin with the p
Somehow this arrived late in my inbox :/
On Tue, 09 Jun 2009 18:29:25 +0200, Tyler Close wrote:
> I think there are two main reasons:
>
> 1. ADsafe, Caja and others provide finer grained control over what the
> widget can do.
Could you elaborate on that?
> 2. All ads/widgets are fetched by the
On Tue, Jun 9, 2009 at 12:09 PM, Anne van Kesteren wrote:
> On Tue, 09 Jun 2009 18:38:47 +0200, Tyler Close wrote:
>> So requests from XMLHttpRequest have an Origin header, and requests
>> from GuestXMLHttpRequest don't. The server should treat requests
>> coming from GuestXMLHttpRequest as bits a
On Tue, 09 Jun 2009 18:38:47 +0200, Tyler Close wrote:
> So requests from XMLHttpRequest have an Origin header, and requests
> from GuestXMLHttpRequest don't. The server should treat requests
> coming from GuestXMLHttpRequest as bits arriving from an unknown
> client (ie: a "guest"), and so only a
Thanks Tyler. I understand your use case now. I don't see the harm
in sending Origin: null, so I haven't changed the I-D, which requires
a (possibly null) Origin header in some cases.
Adam
On Tue, Jun 9, 2009 at 11:50 AM, Tyler Close wrote:
> On Tue, Jun 9, 2009 at 11:19 AM, Adam Barth wrote:
On Tue, Jun 9, 2009 at 11:19 AM, Adam Barth wrote:
> On Tue, Jun 9, 2009 at 9:38 AM, Tyler Close wrote:
>> On Tue, Jun 9, 2009 at 9:29 AM, Adam Barth wrote:
>>> Isn't the whole
>>> point of this feature to be able to distinguish guest and non-guest?
>>
>> So requests from XMLHttpRequest have an Or
On Fri, 5 Jun 2009, Ben Dodson wrote:
>
> I was wondering if binary data would somehow be supported in the
> upcoming websockets?
The protocol has been written to support it, but it will probably not be
supported in the first version of the API, since, as Anne mentions, there
isn't solid suppo
On Tue, Jun 9, 2009 at 9:38 AM, Tyler Close wrote:
> On Tue, Jun 9, 2009 at 9:29 AM, Adam Barth wrote:
>> Isn't the whole
>> point of this feature to be able to distinguish guest and non-guest?
>
> So requests from XMLHttpRequest have an Origin header, and requests
> from GuestXMLHttpRequest don't
On Tue, Jun 9, 2009 at 9:55 AM, Giovanni
Campagna wrote:
> 2009/6/9 Adam Barth :
>> I recommend reading
>> http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf for
>> examples of why this is often sufficient for the attacker to perform
>> misdeeds.
>
> I read it, and I must say that it
2009/6/9 Adam Barth :
> On Tue, Jun 9, 2009 at 5:33 AM, Giovanni
> Campagna wrote:
>> 1) I cannot understand what advantages has the attacker into logging
>> the user with attacker's credentials. I expect that the user will
>> notice the different account used (for example in the web app
>> interfa
On Tue, Jun 9, 2009 at 9:38 AM, Tyler Close wrote:
> On Tue, Jun 9, 2009 at 9:29 AM, Adam Barth wrote:
>> On Tue, Jun 9, 2009 at 9:19 AM, Tyler Close wrote:
>>> On Tue, Jun 9, 2009 at 12:22 AM, Adam Barth wrote:
Please send "Origin: null" in these cases. The problem with omitting
the ori
On Tue, Jun 9, 2009 at 9:29 AM, Adam Barth wrote:
> On Tue, Jun 9, 2009 at 9:19 AM, Tyler Close wrote:
>> On Tue, Jun 9, 2009 at 12:22 AM, Adam Barth wrote:
>>> Please send "Origin: null" in these cases. The problem with omitting
>>> the origin header is that the server can't tell if the request c
Making a static declaration of a to indicate to the UA which
APIs to make available to a widget is already used in existing widget
and gadget implementations; requestFeature() isn't.
For example, here is the definition used by Google, and implemented in
Shindig:
Gadget Features. A list o
On Tue, Jun 9, 2009 at 9:19 AM, Tyler Close wrote:
> On Tue, Jun 9, 2009 at 12:22 AM, Adam Barth wrote:
>> Please send "Origin: null" in these cases. The problem with omitting
>> the origin header is that the server can't tell if the request comes
>> from a legacy client or if the header was remov
On Tue, Jun 9, 2009 at 12:54 AM, Anne van Kesteren wrote:
> On Tue, 09 Jun 2009 03:39:19 +0200, Mark S. Miller wrote:
>> This use-case was the motivation for ADsafe, though any of the JavaScript
>> sanitizers would do.
>>
>> Without some such sanitization technology, it remains unsafe to load
>> u
On Tue, Jun 9, 2009 at 12:22 AM, Adam Barth wrote:
> On Mon, Jun 8, 2009 at 5:59 PM, Mark S. Miller wrote:
>> For concreteness, for the Origin header for these requests, I'll start with
>> the simplest proposal that meets my goals: no Origin header for either same
>> origin requests or cross origin
On Tue, Jun 9, 2009 at 5:33 AM, Giovanni
Campagna wrote:
> 1) I cannot understand what advantages has the attacker into logging
> the user with attacker's credentials. I expect that the user will
> notice the different account used (for example in the web app
> interface)
I recommend reading
http:
Title: Questions on A&E spec
Here are a couple of potentially easy questions on the Widgets 1.0: APIs and Events spec:
5.15 The openURL() Method
Does "the appropriate protocol handler" mean an external application (e.g. browser for http://) is invoked, or can the "handler" be the widget u
On Tue, Jun 9, 2009 at 10:14 AM, Marcin
Hanclik wrote:
> Hi Marcos,
>
>>>Right. However, I don't know why we are discussing this if, as you
>>>said before, it has no relevance to widgets.
> Last week during the BONDI meeting that you also attended we concluded that
> requestFeature() will be appli
Hi Cameron,
I am sorry for responding that late, but my mail client wrongly classified your
message and I realized of its existence right now :)
>>What is the issue with constants?
We would like to have this constant
bondi.camera.Camera.NIGHT_MODE
to be only accessible as above.
Camera and Camer
Hi,
just a reminder that DOM3 discussion should be on the www-dom list. Please
follow up there.
(I have forwarded a collated version of this thread to that list.)
cheers
Chaals
On Thu, 04 Jun 2009 12:52:39 +0200, Sergey Ilinsky
wrote:
Hi,
For me it is not clear at all what are the use ca
On Tue, Jun 9, 2009 at 10:19 AM, Marcin
Hanclik wrote:
>>>Ok, that makes sense; but I have serious doubts anyone will implement that.
> Why?
> You mean because it would not sell, because it is bad by design or any other
> reason?
>
It's a bad design, IMO. However, we will discuss this as part of
Hi,
The spec states [1]:
"The key(n) method must return the name of the nth key in the list.
The order of keys is user-agent defined, but must be consistent
within an object between changes to the number of keys. (Thus,
adding or removing a key may change the order of the keys, but
On 6/9/09 11:58 AM, Anne van Kesteren wrote:
On Tue, 09 Jun 2009 11:32:49 +0200, Marcos Caceres wrote:
Like I said, as far as WebApps is concerned requestFeature() does not
exists. What I meant was the requestFeature() undermines
without addressing the security issues.
I'm getting more and
2009/6/9 Adam Barth :
> Hi Giovanni,
>
> On Mon, Jun 8, 2009 at 6:52 AM, Giovanni
> Campagna wrote:
>> As I understand from various discussions here and from articles
>> around, I've learned that CSRF is a security leak which involves:
>>
>> 1) user visites http://www.mybank.com/login
>> 2) the ser
On Fri, 05 Jun 2009 19:02:07 +0200, Ben Dodson wrote:
> I was wondering if binary data would somehow be supported in the upcoming
> websockets?
"Binary" data is not handled at all really in ECMAScript at the moment so more
changes would be required than just adding it to the WebSocket API.
--
On Tue, 09 Jun 2009 11:32:49 +0200, Marcos Caceres wrote:
> Like I said, as far as WebApps is concerned requestFeature() does not
> exists. What I meant was the requestFeature() undermines
> without addressing the security issues.
I'm getting more and more confused. You claim you do not understa
2009/6/9 Anne van Kesteren :
> On Tue, 09 Jun 2009 01:38:14 +0200, Marcos Caceres wrote:
>> On 6/8/09 11:20 PM, Anne van Kesteren wrote:
>>> On Mon, 08 Jun 2009 20:34:19 +0200, Marcos Caceres
>>> wrote:
Yes, that was the design. If requestFeature() is introduced,
is basically useless.
>>
In XMLHttpRequest in the send() method is overloaded to take a Document and a
DOMString. All non-Document objects are treated with the semantics of
DOMString. (Attempt to stringification etc.) Is there a way to specify this
without explicit language in the specification?
--
Anne van Kesteren
Quick review of the WAR spec...
http://dev.w3.org/2006/waf/widgets-access/
1. The definitions section seems to introduce "instantiated
components" as a first class object that is granted access. However,
what the spec talks about are the rights that the widget execution
scope is granted.
"Step 7
...
10. For each element in the elements list, if the element is one of the
following:
A description element:
If this is not the first description element encountered, then the user
agent must ignore the element and its child nodes. Stop processing this element
... "
My point is:
Th
Hi Marcos,
>>Right. However, I don't know why we are discussing this if, as you
>>said before, it has no relevance to widgets.
Last week during the BONDI meeting that you also attended we concluded that
requestFeature() will be applicable also to widgets. The detailed discussion is
planned anywa
>>Ok, that makes sense; but I have serious doubts anyone will implement that.
Why?
You mean because it would not sell, because it is bad by design or any other
reason?
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: mar
>>Yes, that was the design. If requestFeature() is introduced,
>>is basically useless.
Not necessarily. There can be different security aspects for both.
The basic idea is to make requestFeature() also to be a feature.
Thanks.
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 |
On Tue, 09 Jun 2009 03:39:19 +0200, Mark S. Miller wrote:
> This use-case was the motivation for ADsafe, though any of the JavaScript
> sanitizers would do.
>
> Without some such sanitization technology, it remains unsafe to load
> untrusted ads directly on your page. Adam and I are still arguing
Hi Giovanni,
On Mon, Jun 8, 2009 at 6:52 AM, Giovanni
Campagna wrote:
> As I understand from various discussions here and from articles
> around, I've learned that CSRF is a security leak which involves:
>
> 1) user visites http://www.mybank.com/login
> 2) the server sends a cookie, call it MyBank
On Tue, 09 Jun 2009 01:38:14 +0200, Marcos Caceres wrote:
> On 6/8/09 11:20 PM, Anne van Kesteren wrote:
>> On Mon, 08 Jun 2009 20:34:19 +0200, Marcos Caceres
>> wrote:
>>> Yes, that was the design. If requestFeature() is introduced,
>>> is basically useless.
>>
>> Now I'm confused.
>
> hehe, j
Hi,
I was wondering if binary data would somehow be supported in the upcoming
websockets?
On Mon, Jun 8, 2009 at 5:59 PM, Mark S. Miller wrote:
> For concreteness, for the Origin header for these requests, I'll start with
> the simplest proposal that meets my goals: no Origin header for either same
> origin requests or cross origin requests. But for both the same origin case
> and the c
The below doesn't appear to be a technical criticism of
Origin-as-CSRF-defense but rather a recommendation for a certain
design pattern for building web applications. That design pattern
seems useful. You might consider building a framework a la Rails that
makes it easy for developer to adopt thi
49 matches
Mail list logo
