IE Team's Proposal for Cross Site Requests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
122 messages Options
1 ... 34567
Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Chris Wilson-12

Sorry, these fell down in my inbox due to a poor inbox rule construction.
Bjoern Hoehrmann [mailto:[hidden email]] wrote:

>In evaluating Microsoft's XDR proposal I believe two questions are most
>important. First, how well does it address what people actually want to
>do in terms of cross site requests.

Agreed.  With the understanding, of course, that additional complexity adds security risk, probably in a non-linear fashion.

>The mechanism is very crude, you can
>not use methods other than GET and POST, you can't set headers, you have
>no standard methods for authentication, you can only transfer strings,

I think these are all true.

>you have to be able to manipulate the HTTP header,

I presume "you" in this case is the application author, meaning that they need to have access to the server in order to read and respond with the headers.  If so, yes.

>and it only works if
>you can use the special new API, not if you use some other methods to
>embed external resources.

I'm afraid I don't understand "other methods to embed external resources."

>If that is all developers want to do, XDR may be quite suitable. If, on
>the other hand, developers actually need and want additional methods,
>authentication, transfer data that isn't simply a string conveniently,
>and other things, it is quite possible they will come up with crude ad-
>hoc work arounds to address their requirements, and are highly likely to
>implement security vulnerabilities in their applications in the process;

Fair enough.  That's a good case for having extremely explicit use cases - not just "well, somebody might want to..." but actual use cases - for what scope we expect to cover here.  We expected XDR to have a more limited scope.

I'd point out that most of the missing bits you mention aren't hard to add to XDR in a more secure way - e.g., for authentication we could simply add a cross-domain-authenticate header, which then would have no chance of colliding with current authentication on current servers.  Cookies in general are a little harder to figure out how to do securely across x-domain and SO, but not impossible.

>more so if many different applications require different workarounds.

>It does not matter all that much to most users whether they get screwed
>because of a browser bug, or a web site bug. It appears that Microsoft
>realizes as much, citing how easily other solutions are misconfigured as
>one motivation for the XDR work, but it is very much unclear to me why
>developers are not going to make grave errors when setting up XDR-based
>sites and services.

If you believe that XDR doesn't cover the most critical core cases, and therefore MOST developers are going to be forced into making these grave errors, then you might be correct.

>The second questions is simply whether this is all. Is there going to be
>an "XDRv2" in "IE9" with more developer aids to build secure cross site

In short, I don't know.  If XHR2+AC still has the same security concerns, and web developers express the need for more functionality (as I think you feel they need, as per above), then yes, I expect we would expand it.

>Or other solutions in other Microsoft products? The latter would
>http://lists.w3.org/Archives/Public/public-appformats/2008Apr/0073.html
>seem to be so in the case of the next version of Microsoft Silverlight.

I obviously can't speak for other Microsoft products.  Silverlight, of course, has to layer their code on top of what they can get out of other browsers' extensibility and networking (because they don't want to write their own network stack if they can avoid it).

>In the current Beta version you will find many of the things we hear are
>bad from the Internet Explorer Team, that is, policy files, cookies are
>sent, the same APIs are used for same-domain and cross-domain requests,
>and while there are two differnt kinds of policy files, and an upcoming
>full cross-domain model for socket access. But no apparent XDR support.

Indeed.  Because they have to work across browsers.  They'd like to expose XDR instead.

>That Microsoft itself cannot agree on one technology, or at least only
>one philosophy to approach the problem does not inspire confidence in
>any of the solutions, and the prospect of having to cope with several
>new cross domain access solutions, even though we already have too many,
>is rather worrying.

Again, because they have to work across browsers and platforms.  They have much different constraints than we do.

>Personally speaking, the IE Team's emphasis on security and simplicity
>is a welcome contrast to the XHR2+AC design team's emphasis on broad
>applicability, ease of deployment, and efficiency, but XDR is so limited
>in its ability that I might aswell continue using remote <script>s and
>HTML form posts, that at least works everywhere and the security impli-
>cations are well-known.

Part of the feedback we'd welcome is how additional functionality is needed in the real world.

-Chris

Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Chris Wilson-12
In reply to this post by Arun Ranganathan-2

Stripping the parts Sunava already answered.
Arun Ranganathan wrote:
>*In particular* what is the direct parallel you are drawing between the
>Flash approach and the XHR2+AC approach? Sunava's commentary eagerly
>awaited. In this message
>
>http://lists.w3.org/Archives/Public/public-webapi/2008May/0196.html
>
>you suggest we look at "DNS Hardening" for "clues." Can you be a bit
>more specific here, if possible?

In both XHR2+AC and Flash's policy file approach, the "allow credentials" and the actual access to data occur in separate network transactions, and likely (but not guaranteed, of course) separate network connections.  This enables the vector of DNS attacks - the idea being that between those two connections, an attacker could insert themselves in to the stream.  (Actually, more likely it would be the other way around - an attacker would insert themselves into the stream, give back "it's okay to do x-domain", then release and let the real site give back data.

XDR, by contrast, performs the "access check" in effect on the same connection, since it's not a multi-part negotiation.

>All things being equal, it is likely that XDR and XHR2+AC will co-exist,
>and the major JS libraries can probably straddle the difference. Of
>course, I'd prefer it if we had a single API that addressed the more
>robust needs of web applications, including Cookies, etc. :)

I would too.  But I'd prefer to not be p0wned by security vulnerabilities even more than I'd like to address all needs in v1.

>But IE8 beta does support postMessage, just as other UAs do. And it
>would seem that postMessage will be used for cross-site requests because
>of the widespread support across UAs, modulo caller/callee understanding
>across sites (e.g. there's likely to be a propagation of iframe-based
>APIs which can be requested with Cookies, Auth, etc. and on which other
>sites will call .postMessage). This would have well-known limitations.

Yup.

>Coming to the table and commenting on proposals will create better
>solutions for developers.

Yes, I agree.  We need to do better.

-C


Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Ian Hickson

On Thu, 22 May 2008, Chris Wilson wrote:

>
> In both XHR2+AC and Flash's policy file approach, the "allow
> credentials" and the actual access to data occur in separate network
> transactions, and likely (but not guaranteed, of course) separate
> network connections.  This enables the vector of DNS attacks - the idea
> being that between those two connections, an attacker could insert
> themselves in to the stream.  (Actually, more likely it would be the
> other way around - an attacker would insert themselves into the stream,
> give back "it's okay to do x-domain", then release and let the real site
> give back data.
>
> XDR, by contrast, performs the "access check" in effect on the same
> connection, since it's not a multi-part negotiation.

I think you're misunderstanding what it is that the preflight check does.
In XHR/AC, the preflight is a check to ensure that the server is willing
to receive the request in the first place. XDR doesn't check for this at
all (it's why it is possible to use XDR to POST to unsuspecting intranet
servers, something you can't do with XHR unless the intranet server only
supports HTTP 1.0 and thus doesn't check Host: headers).

In both XDR _and_ XHR/AC, the response is checked for the correct magic
bits before any data is returned to the client. The security check is
still done on the response, the data from the original OPTIONS request
isn't used to determine whether or not to return data to the client.

In any case, if your DNS infrastructure has been compromised to the level
that you describe then all of this is moot. If you can control what
arbitrary hosts resolve to then there are much more effective attack
scenarios, such as taking over the JS file that does all the XHRing in the
first place, or stealing the user's credentials or cookies directly.
Talking about DNS rebind attacks against XHR's OPTIONS infrastructure is
like talking about whether to use bullet-proof glass or shatter-free glass
on the front of a hot dog stand.

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

Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Arun Ranganathan-2

On Thu, 22 May 2008, Chris Wilson wrote:
>> In both XHR2+AC and Flash's policy file approach, the "allow
>> credentials" and the actual access to data occur in separate network
>> transactions, and likely (but not guaranteed, of course) separate
>> network connections.  
<snip />

And Ian responded:
> In both XDR _and_ XHR/AC, the response is checked for the correct magic
> bits before any data is returned to the client. The security check is
> still done on the response, the data from the original OPTIONS request
> isn't used to determine whether or not to return data to the client.
>
>  
<snip />

I think that if the uber point that Chris makes with respect to Access
Control is that we should try and economize on header exchanges (and
thus the possibility of different connections), I think that's a valid
point.

But architecturally, I'm not sure it's a *bad* thing that we engage in
two-point request negotiations in the situations that we do this  --
asking first for permission, and then sending the request.  Seems like
this is a sticky point with you w.r.t. Access Control in general, and
this is a hard point to evolve in a way that addresses your concerns.  
On the one hand, we're engaging in a layer of diligence to ensure that
both parties agree on the data that is to be exchanged (credentialed?)
and methods to use (OPTIONS: and Allow:), and on the other hand we have
to weigh the scenario that you cite that in a multipart request-response
negotiation, the connection can be hijacked.

I still think that the vector of attacks you cite are open, difficult
problems that exist outside the scope of AC.  I mean, standard requests
for HTML documents often are multipart requests today on the web, and
thus are prone to similar attack vectors (in your example, replace the
notion of XS-XHR with requests for pages and add "attacker can insert
themselves into the stream...").   But thinking about economizing on
headers or connections in general is a good thing; I'm just not sure I
have a straw person yet as to where this can be done (right now I'm
grasping at straws like Keep-Alive :-) ).

Thank you for sharing your security concern here.  I worry that this
will become a bit of an intractable debate about direction, but the
concerns are definitely worth thinking about, and I'm glad we're airing
them.

In the simplest case of GET, XHR2+AC and XDR resemble each other closely
enough.  Our divergence stems from wanting to evolve more capabilities,
including methods and credentials.  For instance, do you think you might
want to introduce more HTTP methods into the system?  Let's assume that
you want to treat POST like XDR does.  For other methods, shouldn't
there be a determination request?  Or do you think such things should
not be allowed at all?

-- A*

Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Jonas Sicking-2
In reply to this post by Chris Wilson-12

Chris Wilson wrote:
> Indeed, there has been a lot of back and forth on the topics of XDR
> and XHR2+AC over the last couple of weeks.

As others have pointed out, it hasn't so much been a back-and-forth as
much as the rest of the group asking Microsoft for detailed information
and waiting for answers.

> This message is not
> attempting to set forth in detail all the objections we have had;
> Sunava will deliver that in a concise form. From the comments in
> various responses in this topic, it is clear that expectations are
> extremely high for the level of detail in those objections;

I don't think expectations are extremely high. We simply want
information that is detailed enough that it can be used as basis for
technical discussions and changes to the spec.

So far the input has mostly been "We are worried about the security
implications of AC+XHR and think XDR is safer". That is not enough to
make any changes to the Access-Control spec to address those worries.
The rest of the group does not even know *what* the worries are.

> that takes
> much time to prepare, and involves a number of people here across
> multiple teams.  Some of these concerns are direct and technical, and
> might be fixed in the XHR2+AC draft; however, some of our most
> important concerns pertain to the approach of enabling cross-domain.

Not really sure what this means, but I'm hoping that Sunava will explain
in his email what these concerns are.

Given that the whole Access-Control spec is about enabling cross-domain,
saying that that is the part you have concerns with doesn't really
narrow things down :)

> However, we
> feel the design of grafting cross-domain access on to the
> already-existing XHR system is dangerous,

Why? The new-XDR-API vs. reuse-existing-XHR-API discussion does not seem
related to security. Though given the lack of specifics so far there
isn't much for me to go on here.

> and the current design is
> being arrived at by the method of discussing what developers want to
> do, then trying to make it safe, rather than starting with what is
> secure by principle and incrementally adding functionality.
> Experience has taught us it is much easier to ship a system that is
> secure by design and add functionality than try to secure a
> implementation after it ships by rolling back features.

I don't know what you mean by "secure by principal" and "secure by
design" here. Are you alluding to the fact that XDR can never send out
requests that aren't possible already?

If so, that seems like it would only be "secure by design" as far as
securing the server goes. Not as far as protecting the users data goes,
which seems just as important.

I would argue that Access-Control is better at protecting the users data
than XDR. Since XDR isn't built for transferring private data (since it
doesn't send cookies) it forces web developers to develop their own
mechanisms on top of XDR. Most likely many of these mechanisms are going
to be less safe than Access-Control since they are unlikely to spend as
much effort and expertise securing their mechanism compared to how much
has been put into Access-Control.

Removing a tool to do safe cross-site private data transfer doesn't mean
that sites will stop doing it. It just means that they will use other
mechanisms.

>  For example,
> today the current XHR draft proposes to block a list of headers that
> are unsafe only in a cross-domain context; however, this is difficult
> to deploy since XHR has already shipped, and challenging to imagine
> that there are no other headers in use by servers anywhere around the
> world that might not be good to access.

How would the fact that same-site XHR is already deployed affect how we
can deploy cross-site XHR? Is your concern that sites today attempt to
do cross-site XHR requests and rely on the fact that that throws?

Also, is this a security concern, or a concern that AC+XHR will break
existing pages?

> In our opinion, one of the fundamental problems with the XHR2+AC
> proposal is that it blithely reuses an already-existing API for
> same-domain communication, and then attempts to patch the cracks that
> appear when it is used to perform cross-domain transfers.

Again, why is this a problem? Even if we were to go with the security
model of XDR, I would strongly advocate that we would use XHR as the API
to access this security model.

The discussion about the security model and the discussion about the API
seems like two orthogonal discussions to me (with the security model
discussion being far more interesting), and I would prefer if we
discussed them separately.

> We want to be extremely clear that XDR is most definitely NOT, in our
> opinion, a “slightly different API that solves nearly the same
> problem” – neither is it “different for no extra benefit.”   [3]  Nor
> is it an “incompatible proposal,” [4]

Why? The fact that the two APIs are nearly identical seems to indicate
that they are.

But again, the API discussion seems separate from the security model one.

> As for the XHR2+AC draft itself, I don't believe we intended anything
> we ever said to equate to “XHR2+AC is good;" I challenge the assertion
> of “Microsoft reviews W3C spec as good” [5] as an accurate
> generalization of what has been said [6].  This message did not claim
> to reflect a deep technical analysis of its contents of the Access
> Control draft, but let’s lay aside that concern; it is far more
> germane that there was no indication that we saw at the time that this
> access control mechanism would be simply directly applied to the
> XMLHttpRequest object.

So does that mean that if we removed the ability to specify custom
headers and custom HTTP methods then microsoft have no security concerns
with the spec? That really was what changed when XHR was combined with
Access-Control.

> We’ve given the feedback that we believe this approach to enabling
> cross-domain is inherently insecure, but unfortunately the working
> group has not been receptive to these lessons we have learned from our
> experience.

We have received no input to the WG about what microsofts experience is.
Will Sunavas email detail this too?

> For example, one response was: “I'm also not sure how you
> could be surprised by the WGs vote not to replace years worth of work
> with a completely different and incompatible proposal.  Especially
> when any security concerns could have been addressed by tweaks to the
> existing specification.”  [8]  In my opinion, this response is flawed
> on multiple levels; first, because we had never recommended throwing
> away all work on XHR2+AC and replacing it with XDR; we’ve suggested
> that XDR is a focused subset of cross-domain functionality that we
> believe is securable today.  Certainly, XHR2+AC attempts to enable a
> lot more functionality; that would assure its place in the future.

So you are not so much opposed XHR2+AC as you say that we should do both?

> Secondly, I would think that issues of security in design would make
> it obvious that more work is necessary; just because something has
> been around for a year doesn’t mean it’s right, or that it is the best
> way of doing something.

I agree that just because something has been around for a longer time
doesn't make it better. However I'm still not sure how you could be
surprised that the group would give up years worth of work to replace it
with a new dropped in proposal, rather than by making the changes you
felt were needed to the existing proposal.

The communication we got from microsoft wasn't "we think the following
things are wrong with the existing proposal for the following reasons,
and thus suggest these changes", but rather "we think think this thing
we have here is better than your thing, oh, and btw, we've already put
our thing in IE8 and plan to keep it there". That is hardly working with
the W3C.

> Finally, we disagree that the security
> concerns about XHR2+AC can be addressed by mere tweaks to the
> technical details.  For example, I pointed out that the flow of this
> design is inherently open to DNS rebinding attacks [9],

These DNS rebinding attacks are already possible using normal same-site
XHR today. I also note that you never replied to my reply in that
thread: http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0117.html

Something that unfortunately has been a common theme :(

It is still unknown to me if microsofts concern can be accomplished by
mere tweaks to the spec. Simply because I don't know what the concern is
with the various differences between the spec.

For example the fact that the site has no ability to choose who to
enable cross site requests for, is that an intentional difference?

Or the fact that cookies are not sent? What was your concern there? (I
have my own concerns with cookies as has been, and is still being
discussed on this list).

> as well as
> other issues we’ve pointed out.  I believe we have several times laid
> out some of our concerns with the current XHR2+AC method of doing
> cross-domain; it continues to be claimed that “nobody has responded to
> the requests for a description of these problems” [10].

For example in the thread mentioned above.

> I don’t
> believe that’s appropriate; I think whenever we do describe where we
> see design flaws and potential exploit area (e.g. [11])

You do describe where you see flaws. But you don't describe what flaws
you are seeing, or why you think they are flaws. Saying "there is a
problem with that part of the spec" just leaves us guessing what you
want changed.

> At any rate, focusing on individual technical issues misses the point;
> spackling security over existing designs to extend them in ways they
> were not intended is very complex to get right.

Without discussion individual technical issues I don't see how we could
discuss the merits of one proposal vs the other. Having meta discussions
about "we've designed our spec with security by principal" doesn't
really take us any further. Of course every one involved has had
security as their main concern.

> To address these concerns, we built a simpler, more focused API to
> enable some set of cross-domain access we felt could be secured, in
> the most focused way possible.  Unlike Access Control, XDR is modeled
> off the defacto security policy defined by HTML 4.0 – that is, the
> prohibition against HTTP methods other than GET and POST and
> limitations of HTTP headers are in the HTML 4.0 specification and
> widely used as Tyler Close from HP pointed out to the Web API mailing
> list.  [16]  Indeed, the Open Ajax Alliance claims that XDR promises
> to be simpler and more secure [17].

As has been mentioned before, just because you are only issuing requests
that HTML 4.0 can already do doesn't make it an inheritly safer spec.
You're leaving the responsibility of identify control up to the
websites, and by removing the Content-Type header you force servers to
guess the content type which also have security problems.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

Re: Moving forward with XHR2 and AC

Anne van Kesteren-2
In reply to this post by Anne van Kesteren-2

I changed my mind on several things below.

On Fri, 16 May 2008 13:37:54 +0200, Anne van Kesteren <[hidden email]>  
wrote:

> On Fri, 16 May 2008 02:07:57 +0200, Ian Hickson <[hidden email]> wrote:
>> Anne, can you summarise what needs doing to XHR2 and AC to move them
>> forwards to last call? Is there a list of outstanding comments anywhere?
>
> XMLHttpRequest Level 2
>
> * Depends on XMLHttpRequest Level 1 feedback:  
> http://dev.w3.org/2006/webapi/XMLHttpRequest/disposition-of-comments-2
> * It needs an introduction at some point. (Though not per se for Last  
> Call I suppose.)

This is both still true though I made some progress incorperating  
feedback. (Need to make sure everything relevant made XMLHttpRequest 2 too  
though.


> Access Control for Cross-Site Requests
>
> * Need to deal with Access-Control-Policy-Path normalization

Done.


> * Need to figure out if we want the server to whitelist headers/methods  
> (we had methods before and then dropped it)

I changed my mind on this. Given the reply from Björn in particular I  
don't think there's anything that needs to be done here.


> * Need to figure out if we want the server to opt in to  
> cookies/credentials

I rejected this proposal in another e-mail.


It seems therefore that Access Control is ready for Last Call and it seems  
slightly safer to wait with XMLHttpRequest 2 until we have had all the  
feedback on XMLHttpRequest 1 for which the comment deadline is Monday June  
2.


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

Reply | Threaded
Open this post in threaded view
|

Re: Moving forward with XHR2 and AC

Jonas Sicking-2

Anne van Kesteren wrote:

>
> I changed my mind on several things below.
>
> On Fri, 16 May 2008 13:37:54 +0200, Anne van Kesteren <[hidden email]>
> wrote:
>> On Fri, 16 May 2008 02:07:57 +0200, Ian Hickson <[hidden email]> wrote:
>>> Anne, can you summarise what needs doing to XHR2 and AC to move them
>>> forwards to last call? Is there a list of outstanding comments anywhere?
>>
>> XMLHttpRequest Level 2
>>
>> * Depends on XMLHttpRequest Level 1 feedback:
>> http://dev.w3.org/2006/webapi/XMLHttpRequest/disposition-of-comments-2
>> * It needs an introduction at some point. (Though not per se for Last
>> Call I suppose.)
>
> This is both still true though I made some progress incorperating
> feedback. (Need to make sure everything relevant made XMLHttpRequest 2
> too though.
>
>
>> Access Control for Cross-Site Requests
>>
>> * Need to deal with Access-Control-Policy-Path normalization
>
> Done.

I think we do need to deal with this. Just leaving it be will I think
will cause exploitable servers out there.

>> * Need to figure out if we want the server to whitelist
>> headers/methods (we had methods before and then dropped it)
>
> I changed my mind on this. Given the reply from Björn in particular I
> don't think there's anything that needs to be done here.

I strongly disagree here. Sorry about being slow to reply, will make
sure that happens today.

>> * Need to figure out if we want the server to opt in to
>> cookies/credentials
>
> I rejected this proposal in another e-mail.

Same thing here.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

Re: Moving forward with XHR2 and AC

Ian Hickson
On Sun, 25 May 2008, Jonas Sicking wrote:
> >
> > > Access Control for Cross-Site Requests
> > >
> > > * Need to deal with Access-Control-Policy-Path normalization
> >
> > Done.
>
> I think we do need to deal with this. Just leaving it be will I think
> will cause exploitable servers out there.

I don't understand how this is different to anything else that servers can
do to shoot themselves in the foot. I think that the danger for authors
using misconfigured and IIS servers is far outweighed by the benefit to
all authors in terms of the reduced load. Firing an OPTIONS request for
every single request is a high cost.


> > > * Need to figure out if we want the server to whitelist
> > > headers/methods (we had methods before and then dropped it)
> >
> > I changed my mind on this. Given the reply from Björn in particular I
> > don't think there's anything that needs to be done here.
>
> I strongly disagree here. Sorry about being slow to reply, will make
> sure that happens today.

Did you send the feedback on this? I think going forward, given the
history of this spec, I would recommend that Anne ignore requests that
don't include reasoning. It isn't reasonable to disagree with decisions
without explaining why. The only result is delay, something that we really
don't need here.


> > > * Need to figure out if we want the server to opt in to
> > > cookies/credentials
> >
> > I rejected this proposal in another e-mail.
>
> Same thing here.

Ditto. Anne weighed the various factors and input here before responding.
Just disagreeing with his conclusion doesn't introduce any new
information, so his conclusion presumably wouldn't change.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Reply | Threaded
Open this post in threaded view
|

Re: Moving forward with XHR2 and AC

Arthur Barstow
In reply to this post by Jonas Sicking-2

Jonas - would please elaborate on your concerns regarding these three  
comments/issues? I would like to see the WG get consensus on these  
before we propose advancing the spec to Last Call.

More explicit details below.

-Regards, Art Barstow


On May 25, 2008, at 1:30 PM, ext Jonas Sicking wrote:

>
> Anne van Kesteren wrote:
>> I changed my mind on several things below.
>> On Fri, 16 May 2008 13:37:54 +0200, Anne van Kesteren  
>> <[hidden email]> wrote:
>>> On Fri, 16 May 2008 02:07:57 +0200, Ian Hickson <[hidden email]>  
>>> wrote:
>>>> Anne, can you summarise what needs doing to XHR2 and AC to move  
>>>> them
>>>> forwards to last call? Is there a list of outstanding comments  
>>>> anywhere?
>>>
>>> XMLHttpRequest Level 2
>>>
>>> * Depends on XMLHttpRequest Level 1 feedback: http://dev.w3.org/ 
>>> 2006/webapi/XMLHttpRequest/disposition-of-comments-2
>>> * It needs an introduction at some point. (Though not per se for  
>>> Last Call I suppose.)
>> This is both still true though I made some progress incorperating  
>> feedback. (Need to make sure everything relevant made  
>> XMLHttpRequest 2 too though.
>>> Access Control for Cross-Site Requests
>>>
>>> * Need to deal with Access-Control-Policy-Path normalization
>> Done.
>
> I think we do need to deal with this. Just leaving it be will I  
> think will cause exploitable servers out there.

Do you have a counter-proposal and/or other inputs on what should be  
done?


>>> * Need to figure out if we want the server to whitelist headers/
>>> methods (we had methods before and then dropped it)
>> I changed my mind on this. Given the reply from Björn in  
>> particular I don't think there's anything that needs to be done here.
>
> I strongly disagree here. Sorry about being slow to reply, will  
> make sure that happens today.

Looking forward to your comments.


>>> * Need to figure out if we want the server to opt in to cookies/
>>> credentials
>> I rejected this proposal in another e-mail.
>
> Same thing here.

Again, looking forward to your comments.


Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Bjoern Hoehrmann
In reply to this post by Chris Wilson-12

* Chris Wilson wrote:
>In both XHR2+AC and Flash's policy file approach, the "allow
>credentials" and the actual access to data occur in separate network
>transactions, and likely (but not guaranteed, of course) separate
>network connections.  This enables the vector of DNS attacks - the idea
>being that between those two connections, an attacker could insert
>themselves in to the stream.  (Actually, more likely it would be the
>other way around - an attacker would insert themselves into the stream,
>give back "it's okay to do x-domain", then release and let the real site
>give back data.

It is insufficient to describe what an attacker could do, you have to
show that an attacker can compromise a system only because of the new
feature. The attack you describe transforms cross site requests into
same origin requests, instead of injecting a spoofed OPTIONS response
the attacker could just as well inject a spoofed GET response and have
a script included that then has same-origin access to the site. What
you describe is essentially as powerful as a XSS vulnerability. There
may well be attack vectors that have not yet been considered, but this
is not one of them.

>XDR, by contrast, performs the "access check" in effect on the same
>connection, since it's not a multi-part negotiation.

If true, this is actually only so due to some undocumented implemen-
tation detail. At the moment the XDR implementation in the IE8 Beta
agressively bypasses caches, otherwise it would be vulnerable to the
"attack" you describe above because the attacker could inject a 304
response that updates the XDR header in a cached response and the
browser would then grant access to it despite the victim forbidding
that. As I understand it, "XHR2+AC" implementers want to cache the
responses, so I would expect them to by actually "vulnerable", but
see above.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

Re: Moving forward with XHR2 and AC

Jonas Sicking-2
In reply to this post by Ian Hickson

Ian Hickson wrote:

> On Sun, 25 May 2008, Jonas Sicking wrote:
>>>> Access Control for Cross-Site Requests
>>>>
>>>> * Need to deal with Access-Control-Policy-Path normalization
>>> Done.
>> I think we do need to deal with this. Just leaving it be will I think
>> will cause exploitable servers out there.
>
> I don't understand how this is different to anything else that servers can
> do to shoot themselves in the foot. I think that the danger for authors
> using misconfigured and IIS servers is far outweighed by the benefit to
> all authors in terms of the reduced load. Firing an OPTIONS request for
> every single request is a high cost.

It is different in its likelihood to happen. I think we can expect
people to deploy all the features of this spec on IIS. We do have a
requirement that the spec should be deployable on existing servers and I
think we're currently failing that requirement.

What I suggest is that we prohibit the Access-Control-Policy-Path header
from being used on URIs that include the string "..\", in escaped or
unescaped form. One worry with this is if there are encodings which put
the '.' or '\' characters to other codepoints than 2E and 5C
respectively. I.e. would we need to forbid its use on URIs other than
ones containing

(.|%2e)(.|%2e)(\|%5c)

/ Jonas

Reply | Threaded
Open this post in threaded view
|

Re: Moving forward with XHR2 and AC

Thomas Roessler

On 2008-05-27 11:00:44 -0700, Jonas Sicking wrote:

> What I suggest is that we prohibit the Access-Control-Policy-Path
> header from being used on URIs that include the string "..\", in
> escaped or unescaped form. One worry with this is if there are
> encodings which put the '.' or '\' characters to other codepoints
> than 2E and 5C respectively. I.e.  would we need to forbid its
> use on URIs other than ones containing

That sounds like perpetuating a bad hack in a spec.  I'd rather see
us say -- in a note somewhere in the spec -- that servers will want
to be careful, and will want to, e.g., configure their respective
web application firewall to prevent this attack from occuring.

That's very different from having specific client conformance
requirements around this kind of server behavior.

--
Thomas Roessler, W3C  <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Moving forward with XHR2 and AC

Jonas Sicking-2

Thomas Roessler wrote:

> On 2008-05-27 11:00:44 -0700, Jonas Sicking wrote:
>
>> What I suggest is that we prohibit the Access-Control-Policy-Path
>> header from being used on URIs that include the string "..\", in
>> escaped or unescaped form. One worry with this is if there are
>> encodings which put the '.' or '\' characters to other codepoints
>> than 2E and 5C respectively. I.e.  would we need to forbid its
>> use on URIs other than ones containing
>
> That sounds like perpetuating a bad hack in a spec.  I'd rather see
> us say -- in a note somewhere in the spec -- that servers will want
> to be careful, and will want to, e.g., configure their respective
> web application firewall to prevent this attack from occuring.
>
> That's very different from having specific client conformance
> requirements around this kind of server behavior.

I really dislike it too, but just putting a "be careful" note in the
spec isn't going to help anyone.

If we don't put this in the spec I suspect that in reality this is
something that implementations are going to want to do anyway. I guess
I'm fine with having this as a non-normative note to ensure that
implementations that want to be on the safe side can.

But at that point we might as well enforce it in the spec too so that
sites can rely on it.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

Re: Moving forward with XHR2 and AC

Ian Hickson
In reply to this post by Jonas Sicking-2

On Tue, 27 May 2008, Jonas Sicking wrote:
>
> What I suggest is that we prohibit the Access-Control-Policy-Path header
> from being used on URIs that include the string "..\", in escaped or
> unescaped form. One worry with this is if there are encodings which put
> the '.' or '\' characters to other codepoints than 2E and 5C
> respectively. I.e. would we need to forbid its use on URIs other than
> ones containing
>
> (.|%2e)(.|%2e)(\|%5c)

I could live with that.

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

Reply | Threaded
Open this post in threaded view
|

RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

Sunava Dutta
In reply to this post by Arthur Barstow

Art, Jonas,
Just a quick update. We've put a lot of effort into the paper and the good news is we're nearly done. It's going through a final peer-review to make sure we've received feedback from experts in the company including our security gurus. (Yes, they do exist at MSFT -:))

I'll be sending out the paper on Tuesday evening or Wednesday the latest. Thanks for waiting.

> -----Original Message-----
> From: Arthur Barstow [mailto:[hidden email]]
> Sent: Friday, May 16, 2008 5:06 AM
> To: ext Jonas Sicking; Sunava Dutta
> Cc: [hidden email]; [hidden email] WG (public); public-
> [hidden email]; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris Wilson;
> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal for
> Cross Site Requests]
>
> Sunava - I tend to agree with Jonas re the timing of MS' response/
> feedback.
>
> Given the f2f meeting is now about six weeks away, can you commit to
> and deliver on an earlier deadline, no later than June 6?
>
> -Regards, Art Barstow
>
>
> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
>
> >
> > Sunava Dutta wrote:
> >>>  >This message is not attempting to set forth in detail all the
> >>> objections we have had; Sunava will >deliver that in a concise form.
> >>>
> >>> Can you give us a ballpark ETA on this?
> > > [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
> > this to
> > > be ready and available to the Web API by mid June in the latest.
> >
> > Wow, this is really bad news that we won't get this feedback until
> > just two weeks before the face to face meeting. Especially given
> > the numerous delays in getting this feedback in the past I am very
> > worried that there will be further delays. Are you absolutely
> > certain that won't happen again?
> >
> > Even just having two weeks in order to discuss this feedback prior
> > to the meeting seems like very short on time.
> >
> > I would really encourage you to consider providing this feedback
> > more promptly. I do not wish to attend a face to face meeting
> > solely to discuss new feedback which we have not had the
> > opportunity to research and cannot usefully discuss. I also hope to
> > cover much more than microsofts feedback during the meeting.


Reply | Threaded
Open this post in threaded view
|

RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

Sunava Dutta

Woo hooo, my first mail to the new webapps alias! -:)

Thanks for waiting for us to get feedback in from people across MSFT. As promised, here is the whitepaper on client side cross domain security articulating the security principles and challenges (high level and specifics ) of the current CS-XHR draft.
I've also addressed the questions members raised in the FAQ.

As Jonas and Art mention, in order to provide the opportunity for members to research and usefully discuss the contents and other issues, lets talk about our concerns among other items F2F in the first week of July.

https://mail.windows.microsoft.com/OWA/redir.aspx?C=7165bcd1f09048ac9fdcd34d2f9556b1&URL=http%3a%2f%2fcode.msdn.microsoft.com%2fxdsecuritywp%2fRelease%2fProjectReleases.aspx%3fReleaseId%3d1157

Look forward to hosting the members here in Redmond.


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Sunava Dutta [[hidden email]]
Sent: Friday, June 06, 2008 2:54 PM
To: Arthur Barstow; ext Jonas Sicking; Marc Silbey
Cc: [hidden email]; [hidden email] WG (public); [hidden email]; Eric Lawrence; Chris Wilson; David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
Subject: RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for  Cross Site Requests]

Art, Jonas,
Just a quick update. We've put a lot of effort into the paper and the good news is we're nearly done. It's going through a final peer-review to make sure we've received feedback from experts in the company including our security gurus. (Yes, they do exist at MSFT -:))

I'll be sending out the paper on Tuesday evening or Wednesday the latest. Thanks for waiting.

> -----Original Message-----
> From: Arthur Barstow [mailto:[hidden email]]
> Sent: Friday, May 16, 2008 5:06 AM
> To: ext Jonas Sicking; Sunava Dutta
> Cc: [hidden email]; [hidden email] WG (public); public-
> [hidden email]; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris Wilson;
> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal for
> Cross Site Requests]
>
> Sunava - I tend to agree with Jonas re the timing of MS' response/
> feedback.
>
> Given the f2f meeting is now about six weeks away, can you commit to
> and deliver on an earlier deadline, no later than June 6?
>
> -Regards, Art Barstow
>
>
> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
>
> >
> > Sunava Dutta wrote:
> >>>  >This message is not attempting to set forth in detail all the
> >>> objections we have had; Sunava will >deliver that in a concise form.
> >>>
> >>> Can you give us a ballpark ETA on this?
> > > [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
> > this to
> > > be ready and available to the Web API by mid June in the latest.
> >
> > Wow, this is really bad news that we won't get this feedback until
> > just two weeks before the face to face meeting. Especially given
> > the numerous delays in getting this feedback in the past I am very
> > worried that there will be further delays. Are you absolutely
> > certain that won't happen again?
> >
> > Even just having two weeks in order to discuss this feedback prior
> > to the meeting seems like very short on time.
> >
> > I would really encourage you to consider providing this feedback
> > more promptly. I do not wish to attend a face to face meeting
> > solely to discuss new feedback which we have not had the
> > opportunity to research and cannot usefully discuss. I also hope to
> > cover much more than microsofts feedback during the meeting.

Reply | Threaded
Open this post in threaded view
|

RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

Sunava Dutta

Try this link instead: http://code.msdn.microsoft.com/xdsecuritywp


________________________________________
From: Sunava Dutta
Sent: Wednesday, June 11, 2008 8:24 PM
To: Sunava Dutta; Arthur Barstow; ext Jonas Sicking; Marc Silbey; [hidden email]
Cc: [hidden email]; [hidden email] WG (public); [hidden email]; Eric Lawrence; Chris Wilson; David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
Subject: RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for  Cross Site Requests]

Woo hooo, my first mail to the new webapps alias! -:)

Thanks for waiting for us to get feedback in from people across MSFT. As promised, here is the whitepaper on client side cross domain security articulating the security principles and challenges (high level and specifics ) of the current CS-XHR draft.
I've also addressed the questions members raised in the FAQ.

As Jonas and Art mention, in order to provide the opportunity for members to research and usefully discuss the contents and other issues, lets talk about our concerns among other items F2F in the first week of July.

https://mail.windows.microsoft.com/OWA/redir.aspx?C=7165bcd1f09048ac9fdcd34d2f9556b1&URL=http%3a%2f%2fcode.msdn.microsoft.com%2fxdsecuritywp%2fRelease%2fProjectReleases.aspx%3fReleaseId%3d1157

Look forward to hosting the members here in Redmond.


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Sunava Dutta [[hidden email]]
Sent: Friday, June 06, 2008 2:54 PM
To: Arthur Barstow; ext Jonas Sicking; Marc Silbey
Cc: [hidden email]; [hidden email] WG (public); [hidden email]; Eric Lawrence; Chris Wilson; David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
Subject: RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for  Cross Site Requests]

Art, Jonas,
Just a quick update. We've put a lot of effort into the paper and the good news is we're nearly done. It's going through a final peer-review to make sure we've received feedback from experts in the company including our security gurus. (Yes, they do exist at MSFT -:))

I'll be sending out the paper on Tuesday evening or Wednesday the latest. Thanks for waiting.

> -----Original Message-----
> From: Arthur Barstow [mailto:[hidden email]]
> Sent: Friday, May 16, 2008 5:06 AM
> To: ext Jonas Sicking; Sunava Dutta
> Cc: [hidden email]; [hidden email] WG (public); public-
> [hidden email]; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris Wilson;
> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal for
> Cross Site Requests]
>
> Sunava - I tend to agree with Jonas re the timing of MS' response/
> feedback.
>
> Given the f2f meeting is now about six weeks away, can you commit to
> and deliver on an earlier deadline, no later than June 6?
>
> -Regards, Art Barstow
>
>
> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
>
> >
> > Sunava Dutta wrote:
> >>>  >This message is not attempting to set forth in detail all the
> >>> objections we have had; Sunava will >deliver that in a concise form.
> >>>
> >>> Can you give us a ballpark ETA on this?
> > > [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
> > this to
> > > be ready and available to the Web API by mid June in the latest.
> >
> > Wow, this is really bad news that we won't get this feedback until
> > just two weeks before the face to face meeting. Especially given
> > the numerous delays in getting this feedback in the past I am very
> > worried that there will be further delays. Are you absolutely
> > certain that won't happen again?
> >
> > Even just having two weeks in order to discuss this feedback prior
> > to the meeting seems like very short on time.
> >
> > I would really encourage you to consider providing this feedback
> > more promptly. I do not wish to attend a face to face meeting
> > solely to discuss new feedback which we have not had the
> > opportunity to research and cannot usefully discuss. I also hope to
> > cover much more than microsofts feedback during the meeting.

Reply | Threaded
Open this post in threaded view
|

RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

Ian Hickson

On Wed, 11 Jun 2008, Sunava Dutta wrote:
>
> Try this link instead: http://code.msdn.microsoft.com/xdsecuritywp

Could you forward the paper to the list? (Preferably as plain text, though
HTML or PDF would do in a pinch.)

It's not clear to me whether the paper on that site is actually covered by
the license on that page, and I don't really want to run the risk of
committing Google to a license by accident without speaking to our lawyers
first, and that seems like a bit of an extreme to go to just to see your
feedback. :-)

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

Reply | Threaded
Open this post in threaded view
|

Need PDF of MS' input [Was Re: Seeking earlier feedback from MS]

Arthur Barstow
In reply to this post by Sunava Dutta

Sunava - as requested by several members of the WG, please send a PDF  
version of this document directly to the public-webapps mail list.

-Thanks, Art Barstow


On Jun 11, 2008, at 11:36 PM, ext Sunava Dutta wrote:

> Try this link instead: http://code.msdn.microsoft.com/xdsecuritywp
>
>
> ________________________________________
> From: Sunava Dutta
> Sent: Wednesday, June 11, 2008 8:24 PM
> To: Sunava Dutta; Arthur Barstow; ext Jonas Sicking; Marc Silbey;  
> [hidden email]
> Cc: [hidden email]; [hidden email] WG (public); public-
> [hidden email]; Eric Lawrence; Chris Wilson; David Ross; Mark  
> Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: RE: Seeking earlier feedback from MS [Was: IE Team's  
> Proposal for  Cross Site Requests]
>
> Woo hooo, my first mail to the new webapps alias! -:)
>
> Thanks for waiting for us to get feedback in from people across  
> MSFT. As promised, here is the whitepaper on client side cross  
> domain security articulating the security principles and challenges  
> (high level and specifics ) of the current CS-XHR draft.
> I've also addressed the questions members raised in the FAQ.
>
> As Jonas and Art mention, in order to provide the opportunity for  
> members to research and usefully discuss the contents and other  
> issues, lets talk about our concerns among other items F2F in the  
> first week of July.
>
> https://mail.windows.microsoft.com/OWA/redir.aspx?
> C=7165bcd1f09048ac9fdcd34d2f9556b1&URL=http%3a%2f%
> 2fcode.msdn.microsoft.com%2fxdsecuritywp%2fRelease%
> 2fProjectReleases.aspx%3fReleaseId%3d1157
>
> Look forward to hosting the members here in Redmond.
>
>
> ________________________________________
> From: [hidden email] [[hidden email]]  
> On Behalf Of Sunava Dutta [[hidden email]]
> Sent: Friday, June 06, 2008 2:54 PM
> To: Arthur Barstow; ext Jonas Sicking; Marc Silbey
> Cc: [hidden email]; [hidden email] WG (public); public-
> [hidden email]; Eric Lawrence; Chris Wilson; David Ross; Mark  
> Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: RE: Seeking earlier feedback from MS [Was: IE Team's  
> Proposal for  Cross Site Requests]
>
> Art, Jonas,
> Just a quick update. We've put a lot of effort into the paper and  
> the good news is we're nearly done. It's going through a final peer-
> review to make sure we've received feedback from experts in the  
> company including our security gurus. (Yes, they do exist at MSFT -:))
>
> I'll be sending out the paper on Tuesday evening or Wednesday the  
> latest. Thanks for waiting.
>
>> -----Original Message-----
>> From: Arthur Barstow [mailto:[hidden email]]
>> Sent: Friday, May 16, 2008 5:06 AM
>> To: ext Jonas Sicking; Sunava Dutta
>> Cc: [hidden email]; [hidden email] WG (public); public-
>> [hidden email]; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris  
>> Wilson;
>> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
>> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal  
>> for
>> Cross Site Requests]
>>
>> Sunava - I tend to agree with Jonas re the timing of MS' response/
>> feedback.
>>
>> Given the f2f meeting is now about six weeks away, can you commit to
>> and deliver on an earlier deadline, no later than June 6?
>>
>> -Regards, Art Barstow
>>
>>
>> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
>>
>>>
>>> Sunava Dutta wrote:
>>>>>> This message is not attempting to set forth in detail all the
>>>>> objections we have had; Sunava will >deliver that in a concise  
>>>>> form.
>>>>>
>>>>> Can you give us a ballpark ETA on this?
>>>> [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
>>> this to
>>>> be ready and available to the Web API by mid June in the latest.
>>>
>>> Wow, this is really bad news that we won't get this feedback until
>>> just two weeks before the face to face meeting. Especially given
>>> the numerous delays in getting this feedback in the past I am very
>>> worried that there will be further delays. Are you absolutely
>>> certain that won't happen again?
>>>
>>> Even just having two weeks in order to discuss this feedback prior
>>> to the meeting seems like very short on time.
>>>
>>> I would really encourage you to consider providing this feedback
>>> more promptly. I do not wish to attend a face to face meeting
>>> solely to discuss new feedback which we have not had the
>>> opportunity to research and cannot usefully discuss. I also hope to
>>> cover much more than microsofts feedback during the meeting.


Reply | Threaded
Open this post in threaded view
|

RE: Need PDF of MS' input [Was Re: Seeking earlier feedback from MS]

Sunava Dutta

Yes, we're working on this as we speak. I'll send out a copy once it's ready.

> -----Original Message-----
> From: [hidden email] [mailto:public-webapps-
> [hidden email]] On Behalf Of Arthur Barstow
> Sent: Thursday, June 12, 2008 3:46 AM
> To: Sunava Dutta
> Cc: Marc Silbey; public-webapps; [hidden email] WG (public);
> public-appformats; Eric Lawrence; Chris Wilson; David Ross; Mark
> Shlimovich (SWI); Doug Stamper; Zhenbin Xu; Michael Champion
> Subject: Need PDF of MS' input [Was Re: Seeking earlier feedback from
> MS]
>
>
> Sunava - as requested by several members of the WG, please send a PDF
> version of this document directly to the public-webapps mail list.
>
> -Thanks, Art Barstow
>
>
> On Jun 11, 2008, at 11:36 PM, ext Sunava Dutta wrote:
>
> > Try this link instead: http://code.msdn.microsoft.com/xdsecuritywp
> >
> >
> > ________________________________________
> > From: Sunava Dutta
> > Sent: Wednesday, June 11, 2008 8:24 PM
> > To: Sunava Dutta; Arthur Barstow; ext Jonas Sicking; Marc Silbey;
> > [hidden email]
> > Cc: [hidden email]; [hidden email] WG (public); public-
> > [hidden email]; Eric Lawrence; Chris Wilson; David Ross; Mark
> > Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> > Subject: RE: Seeking earlier feedback from MS [Was: IE Team's
> > Proposal for  Cross Site Requests]
> >
> > Woo hooo, my first mail to the new webapps alias! -:)
> >
> > Thanks for waiting for us to get feedback in from people across
> > MSFT. As promised, here is the whitepaper on client side cross
> > domain security articulating the security principles and challenges
> > (high level and specifics ) of the current CS-XHR draft.
> > I've also addressed the questions members raised in the FAQ.
> >
> > As Jonas and Art mention, in order to provide the opportunity for
> > members to research and usefully discuss the contents and other
> > issues, lets talk about our concerns among other items F2F in the
> > first week of July.
> >
> > https://mail.windows.microsoft.com/OWA/redir.aspx?
> > C=7165bcd1f09048ac9fdcd34d2f9556b1&URL=http%3a%2f%
> > 2fcode.msdn.microsoft.com%2fxdsecuritywp%2fRelease%
> > 2fProjectReleases.aspx%3fReleaseId%3d1157
> >
> > Look forward to hosting the members here in Redmond.
> >
> >
> > ________________________________________
> > From: [hidden email] [[hidden email]]
> > On Behalf Of Sunava Dutta [[hidden email]]
> > Sent: Friday, June 06, 2008 2:54 PM
> > To: Arthur Barstow; ext Jonas Sicking; Marc Silbey
> > Cc: [hidden email]; [hidden email] WG (public); public-
> > [hidden email]; Eric Lawrence; Chris Wilson; David Ross; Mark
> > Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> > Subject: RE: Seeking earlier feedback from MS [Was: IE Team's
> > Proposal for  Cross Site Requests]
> >
> > Art, Jonas,
> > Just a quick update. We've put a lot of effort into the paper and
> > the good news is we're nearly done. It's going through a final peer-
> > review to make sure we've received feedback from experts in the
> > company including our security gurus. (Yes, they do exist at MSFT -
> :))
> >
> > I'll be sending out the paper on Tuesday evening or Wednesday the
> > latest. Thanks for waiting.
> >
> >> -----Original Message-----
> >> From: Arthur Barstow [mailto:[hidden email]]
> >> Sent: Friday, May 16, 2008 5:06 AM
> >> To: ext Jonas Sicking; Sunava Dutta
> >> Cc: [hidden email]; [hidden email] WG (public); public-
> >> [hidden email]; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris
> >> Wilson;
> >> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> >> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal
> >> for
> >> Cross Site Requests]
> >>
> >> Sunava - I tend to agree with Jonas re the timing of MS' response/
> >> feedback.
> >>
> >> Given the f2f meeting is now about six weeks away, can you commit to
> >> and deliver on an earlier deadline, no later than June 6?
> >>
> >> -Regards, Art Barstow
> >>
> >>
> >> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
> >>
> >>>
> >>> Sunava Dutta wrote:
> >>>>>> This message is not attempting to set forth in detail all the
> >>>>> objections we have had; Sunava will >deliver that in a concise
> >>>>> form.
> >>>>>
> >>>>> Can you give us a ballpark ETA on this?
> >>>> [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
> >>> this to
> >>>> be ready and available to the Web API by mid June in the latest.
> >>>
> >>> Wow, this is really bad news that we won't get this feedback until
> >>> just two weeks before the face to face meeting. Especially given
> >>> the numerous delays in getting this feedback in the past I am very
> >>> worried that there will be further delays. Are you absolutely
> >>> certain that won't happen again?
> >>>
> >>> Even just having two weeks in order to discuss this feedback prior
> >>> to the meeting seems like very short on time.
> >>>
> >>> I would really encourage you to consider providing this feedback
> >>> more promptly. I do not wish to attend a face to face meeting
> >>> solely to discuss new feedback which we have not had the
> >>> opportunity to research and cannot usefully discuss. I also hope to
> >>> cover much more than microsofts feedback during the meeting.
>
>


1 ... 34567