See also: IRC log
refer to http://code.msdn.microsoft.com/xdsecuritywp
Also refer to Microsoft's text-only version, manifested in an email post to the listserv: http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0158.html
<EricLaw> Opera IRC + ISA Firewall client = Happy?
Starting with Jonas Sicking's feedback: http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0168.html
<sicking> original feedback from sunava: http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0120.html
Sunava: I think we'll use Jonas'
email as a starting point.
... I notice we've got preflights for lots of proposals. I'd
like a description of what the preflight covers.
Jonas: There are some outstanding suggested modifications. These are in issue tracker as of a couple of days ago.
<weinig> http://dev.w3.org/2006/waf/access-control/
Anne: You mean editor's draft.
<sicking> http://dev.w3.org/2006/waf/access-control/
<anne> and also: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
chaals: There are two specs: W3C Access Control spec., Microsoft proposal. Then XDR proposal.
anne: the rough outline is that
access control for cross-site requests defines a policy for
resources that can be requested cross-domain, and a pre-flight
policy for [HTTP Verbs] other than GET. We propose that
XMLHttpRequest, and cross-site XSLT leverage the access control
specification.
... the way the AC spec. works is it specs. out two genres of
request: GET (safe), and "other requests"
... requests such as POST, PUT, DELETE are pre-flight
requested. The browser first performs an OPTIONS request to the
server with tentative verbs. Server replies showing awareness,
e.g. 'can handle POST requests cross-domain.' server must check
headers ('orgin', 'host').
... currently, by design, all requests will be done with
credentials included. pre-flight, etc.
sunava: you mention that Access Control doesn't allow you to do anything outside the Web today....
Jonas: there are two headers,
"accept" and "accept-language" that are deemed safe
enough.
... So for example, if you use a CSS request, the browser will
set the accept header we set accept-language header, etc.
Eric: it's not the script which controls headers (clarifying)
Anne: the preflight request on the server says I can handle "cross site requests for this URI".
<trackbot> Sorry... I don't know anything about this channel
<trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
<tlr> trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
Jonas: it would have to grant access twice. "Yes I can handle the request." Then, "I can handle the request and you are allowed to expose what I send to user."
<shepazu> trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
Maciej: if you are sending a GET
rquest with no initial headers, you can initiate that request
but can't see the result unless the server opts in.
... thus no new feature / exposure is added.
Eric: you mention that there's two headers today. Is there's the expectation that the allow list will grow?
Jonas: there was a thread about if more should be added to it. Nothing came out of that discussion. Discusion on "how are you sure that these are actually safe" never went anywhere. I think we'll try and be conservative here.
Eric: there is a consideration that headers with a certain prefix would be ok....
Anne: other way around. headers prefixed with "SEC-" or "PROXY-" cannot be set at all. That's for same site and cross site.
Jonas: which spec (XHR) or AC these prohibitions should live in.
Anne: specs. that deal with HTTP (cross site) should probably not be allowed to set these anyway. These specs are also troublesome for same site. (Agrees with Jonas). This also goes for "dangerous" HTTP verbs, e.g. TRACE
Eric: is there a provision to grow that list (e.g. CONNECT, TRACE).
Jonas: I would be hesitant to add to that list. Some things are already added to XHR-1.
Anne: It depends on whether IETF does another dangerous method, and servers start shipping with it.
Maciej: idea is to block dangerous existing methods, and it's responsibility of servers to not add to that list.
Eric: it seems odd because you're constraining future development of HTTP. You're saying that certain methods are so dangerous that even preflighting isn't enough.
Maciej: the fact that those
methods are dangerous is not intentional in their design.
... e.g. TRACE, TRACK.
Jonas: this is where we at Mozilla have made a proposal, where server has to send a whitelist of methods.
Anne: in theory all methods work. There is a set of methods you'd perform a case insensitive check against. There are a lot of interop. issues with HTTP verbs. Basically WEBDAV would work same site. For cross-site you would have the opt-in. Anyting that has CONNECT, TRACE or TRACK will not work anywhere.
Dave: I envision a scenario where you opt in to allow XHR under one scenario, you ok the preflight, and in doing that, you enable, inadvertently, WEBDAV methods.
Jonas: to some extent I share your concern. The way the spec. is written today, you are sharing a separate part of your URI space, and you don't add dangerous things to that URI space. If you want to add "fancy" things, add it to another part of your site.
Anne: you can still do Origin header based filtering....
Sunava: you do an open request (GET or POST) and we send an XDomainRequest: 1 header. Server responses XDomainRequestAllowed: 1 and we expose the response. We make it stateless. What we did onprogress, onload, onerror. XDR fails silently (onerror). One of the top things is that we realize that implementations have issues, and we're more comfortable right now minimizing. We focus on public data. Sites aren't hardened against cross-domain requests, so we still
Eric: from security perspective,
we were extremely conservative. Our ability to remove
functionality is difficult; thus we try to ensure that we don't
permit exposure that's not strictly necessary.
... we don't provide access to response headers, etc. It is a
very confined communication channel.
Sunava: Sites aren't hardened against cross-domain requests, so we still mandate headers. With the advent of HTML5 cross-domain messaging, we were more comfortable having a method with public data, and using other methods for private.
Eric: ... confined communication
channel, which offers minimal channel for cross-domain.
... via two header exchanges.
Doug: You say that there's nothing that HTML forms don't allow. But forms are explicit. I want to make sure that the average person who is using the site is also protected by the measure.
Eric: if someone had turned off forms (for whatever reason), XDR circumvents that... (asking for clarification).
Doug: I would love if users were notified, but I realize that this is difficult. "You may not be aware of this, but you are communicating with another server."
chaals: this type of activity is spec'd out by a security activity.
Eric: there seems to be a general consensus that delegating this type of model to the user is not a good idea -- correct?
Jonas: Even within Mozilla, there are differing opinions. Some people feel that there are use cases for users to be notified.
Eric: concern I have is for stipulations within HTTP spec. for user notification which isn't really followed by user agents.
<chaalsXO> ./kick shepazu
<chaalsXO> s/.kick schepazu//
<CGI099> test. sunava is back
<chaalsXO> http://www.w3.org/2008/webapps/track/products/4 -> XHR2 issues
<chaalsXO> http://www.w3.org/2008/webapps/track/products/7 -> AC4CSR issues
<CGI099> IWe'll go through Jonas responses to the paper paragraph by paragrah and have a short discussion
Sunava: (clarification) "Origin" header does allow PEP to be on the server.
Eric: when you make the original OPTIONS request, you send the origin header, and you send the Cookies and credentials. If it chose to do so, it could respond with 404, etc.
Sunava: We may have a best practices guideline.
Jonas: we can never require that existing servers do anything particular. Non-normative text is not my priority, but [agrees it is important].
Sam: in the broad case of the Craigslist example, you don't need to check the origin. For the "public" data case, we rarely need to inform users.
Eric: revealing the access control policy isn't desirable (cites example of banks merging, where the AC is in fact sensitive)
Sharath: ... Shouldn't there be a way to revoke the age, e.g. if I publish an age which is more than a few days, and I have to revoke something, how do I do that?
Anne: you can still refuse the request. You tell the browser that you are aware of the XS mechanism. The only thing you are opting into is that I can handle all these XS requests. If you wish to revoke that, check Origin header.
Eric: Can I revoke scenarios
where I cannot check origin header? Answer = no.
... scenario you're in a hotel. Gives you a malicious proxy,
grants lots of permissions. Subsequently you've left unsafe
network, but you've got a cached credential that wasn't what
you wanted.
Jonas: I'd like this to be an issue.
Maciej: don't you have that problem with normal HTTP access? Gives you bad JS, e.g. urchin.js. This isn't different with access control.
Eric: in the proxy case, I'm much more concerned about a site that has inadvertently exposed stuff.
Jonas: I don't know how much we can do about this. Adding a limit for 1 day for max age. Also have non-normative recommendations.
<shepazu> ISSUE: revocation of cached access grants
<trackbot> Created ISSUE-25 - Revocation of cached access grants ; please complete additional details at http://www.w3.org/2008/webapps/track/issues/25/edit .
Maciej: When you make an Access
Control request, then the response can give headers that can
revoke grants there were allowed in a previous transactions.
There's no sound way to revoke without connecting to the
site.
... This new mechanism would allow corrections of mistakes.
Hixie: people who are putting header here will have access to server.
Maciej: having a maximum time limit is probably easier than working with [server].
Jonas: twenty four hours sounds like a good idea.
Anne: If you connect to a different proxy, you should clear all access control caches. Anne to explain why in spec.
Sunava: next feedback is access control secure by design. Jonas says yes.
<shepazu> ACTION: anne to fix the spec to say that If you connect to a different proxy, you should clear all access control caches, and to explain why in spec. [recorded in http://www.w3.org/2008/07/01-wam-minutes.html#action01]
<trackbot> Created ACTION-9 - Fix the spec to say that If you connect to a different proxy, you should clear all access control caches, and to explain why in spec. [on Anne van Kesteren - due 2008-07-08].
Jonas: XDR and AC started from scratch, and added features. AC has gone further. Without the server doing anything, it should not be exposed to anything new that it hasn't been exposed to before.
<mjs> for the record I retract my proposal, since it does not seem any easier than server-side filtering based on Origin
Jonas: we've gone further in our feature set.
Eric: one of the things that's
come of this is that preflights are becoming more and more
common. Preflights become one of the security components of
this.
... if the preflight checks are done correctly, then the
security aspect of the implementation is much better.
... we kind of talked about preflighting, but MSFT has some
more concerns [about preflighting].
<mjs> let me check
<mjs> my opinion: depending on a time limit is easier than changing server configuration to filter cross-site request
Eric: one of the complaints we've
had is we didn't get a lot of feedback about AC. But we looked
at it separately from XHR, thus there was no stated
implementation. It was at that point an academic point.
... we started with an object different from XHR, because
there's significant concern about XHR object. The object itself
has a large-ish attack surface.
<mjs> but revocation via response headers is not particularly easier than filtering
Jonas: My question is, is the concern about the feature set that XHR enables, or is it reusing the same API? THere's an API discussion, and a feature-set/security discussion. We can technically limit the XHR object, but doesn't mean we have to have a specific feature set.
Eric: if too many security
restrictions are imposed, saying it's the same object becomes a
little weird. Our concern is mostly around the
functionality.
... our primary concern is security. Their relevance to
security is what's gating our ability to [move forward].
Sunava: next point -- additionally access control sets up safe way to transfer private data. This prevents sites from inventing something less safe (quoting Jonas)
Eric: we agree creating security
protocols is important. Both Cookies and HTTP-Auth are
implemented in ways that are error prone. We are concerned
about re-using these authentication mechanisms.
... in a model where you have the ability to grant on entire
URI space... (by way of example, a particular server on which
data lives was exposed to cross-domain access. But on the same
URI space, another team had private data. Both teams [thus
collided in expectation]
... cross-domain requests are targeted towards public data.
Other mechanisms exist for private data.
... token granting token APIs are defacto standards, which can
also be done with x-document communication mechanisms.
... we recognize it is possible, but our key messaging on how
this can be done is for public data. Public data scenario is
interesting to a substantial body of customers.
Maciej: to stop misuse of platform, is to give people a better way to do it.
Zhenbin: People don't understand
the consequence of doing access control, and thus the opt in to
things they don't realize (cites example Eric gave).
... making things more difficult won't make people study the
consequence.
Eric: goal is to make safe things
easy.
... (cites JSONRequest and Crockford) client asks server about
something new, server responds. Preflighting. IN current draft,
the "are you hip" thing isn't specific.
... great security improvement to preflighting request is "yes
I'm cool with Cookies, HTTP-Auth..."
... preflight response by default wouldn't allow cookies, auth,
etc.
... where server *explicitly* opts in, that's better.
Maciej: there are two levels of
allowing things. GET requests without anything special don't
get a preflight. By NOT responding to OPTIONS, you don't opt in
to anything else.
... if you want to have opt in be fine grained, how do you make
it less complicated?
Jonas: syntax you had before was tricky. You had to redo OPTIONS request if you had a different method. That added a lot of complexity. It was kind of interwoven. For each allowed server, you had to state what you wanted that server to do. We can do this better.
Eric: GET request with no
preflight seems reasonable. But concern is "header foo" is
desirable to others, and once you respond to a preflight, it
seems like a big jump.
... GET request with no preflight seems reasonable, but going
to be a hard to draw the line. If you do choose to respond to
the OPTIONS request, the fact that you respond to everything
seems like a big jump.
Zhenbin: (asks for clarification about GET + Cookies)
<chaalsXO> s/work?/work/
<chaalsXO> SD: * doesn't clearly say what it allows - everyone can access, or one person can access everything?
<chaalsXO> JS: Out of context yes, but it should be clear since everything about the spec clarifies it
<chaalsXO> SD: OK
<chaalsXO> JS: If we drop * with cookies then this might go away
<chaalsXO> JS: One big thing remaining is access control path canonicalisation
<chaalsXO> ... concern about granting by path - granting from one URI to cover a whole set...
<chaalsXO> EL: Flash had a problem doing this path-based granting. You can encode hex sequences for ../ and make path-matching security holes
<chaalsXO> .. e.g. /bad/visitor/* can be mapped to /bad/visitor/../../../../victim/secret...
<chaalsXO> JS: I don't knowif flash are doing anything to mitigate this.
<chaalsXO> ... have a proposal, where anything that climbs upwards gets auto-denied.
<chaalsXO> ... there are very few use cases for this.
<chaalsXO> EL: You have toensure that the servers accurately trap this correctly...
<chaalsXO> ... there are attacks based on gps in the normalisation process.
<chaalsXO> JS: Not happy just saying servers should solve this
<chaalsXO> IH: The only sane thing is to make this apply to the entire domain, as a waay to avoid the problem
<chaalsXO> JS: There is a risk with that where too much access is enabled ...
<chaalsXO> IH: The alternative is requiring a lot more pre-flight traffic
<chaalsXO> JS: I am happy leaving this out for now
<chaalsXO> IH: Could make sense
<chaalsXO> ZY: If the server relies on the preflight, you get a problem
<chaalsXO> JS: Right. But you should not be able to do that - an anyway the risk is bad enough to avoid anyway
<chaalsXO> MJS: Seems like a tricky space to get into. Maybe we should start out only allowing options on a single resource
<chaalsXO> DS: Would be good to note the rationale in the spec...
<chaalsXO> IH: The nasty case is atompub, where you have zillions of requests...
<chaalsXO> JS: We don't have a nice solution here. Setting it on the root seems bad too.
<chaalsXO> IH: I really want this feature, but I don't see a good way to do it and think we probaby have to punt it to v2
<chaalsXO> DS: Does that constrain us?
<chaalsXO> IH: No, we just have nothing and can add the feature
<chaalsXO> SD: You cn send stuff through headers to the PI?
<chaalsXO> EL: THink this issue is covered
<chaalsXO> ... related concern is the restriction of setting the range header outbound.
<chaalsXO> JS: right - I implemented something that would allow that exploit...
<chaalsXO> ... we could note in the spec that this is an implementation bug. I have smoe concerns about the PI, but that's for tomorrow...
<chaalsXO> ... possibly other headers have similar concerns
<chaalsXO> EL: Interesting because this is something that has a different effect in XS XHR than in local XHR
<chaalsXO> AvK: RANGE requires opt-in
<chaalsXO> JS: We couldwhite-list this. Watch for range...
<chaalsXO> AvK: Sounds messy to spec
<chaalsXO> JS: Sure, but we will have to point it out anyway...
<chaalsXO> AvK: Think you want to be able to see 206 responses...
<chaalsXO> IH: If you get a partial response, then if it doesn't start at byte 1, don't look at the PI
<chaalsXO> ... if we take PI out of the equation we may not need to worry.
<chaalsXO> AvK:Do we wnt to take headers in XBL?
<chaalsXO> IH: We keep it inAC, but special-case it out sometimes.
<chaalsXO> SD: Browsers could get header to identify x-domain cookies, not give them out mistkenly
<chaalsXO> JS: Any infastructure wouldstop working if it required new headers
<scribe> scribenick: arun
SD: (citing Jonas' feedback) This is "extra bad" considering that you are violating the HTTP spec.
<chaalsXO> MJS: There are several cookie issues - good topic for tomorrow
JS: I think x-site request
forgery issues that exist on the web today exist for very
different reasons today.
... outside of Access Control.
... it is hard to mitigate it.
... I don't think that CRSF applies directly to this.
Bryan: I think that if we
implement this exactly as you're saying, it will increase
CSRF.
... it's not just that your'e sending an attack. Now you can
process the response, and can take multiple steps on the
response.
... what's possbie right now is you can send a request, but you
can't really act on the response. If we go down this road (XHR2
+ AC) it enables an attacker to set up a multistage
send/process cycle, which is impossible today.
MJS: on the other hand, access control gives you mitigation mechanisms to check origin, etc.
JS: this is applicable to URIs where people specifically opt in to Access Control. You have a resource that accepts requests, but when they set up that resource, they didn't conceive that it could be accessed x-site.
MJS: you need 2 factors. 1. a
process against CSRF but 2. opened up access control to site in
a way you didn't intend to.
... those are certainly possible, but not likely scenario.
JS: Big risk -- sites do opt in to access control on parts of their URI space that they didn't mean to.
Bryan: difference of XDR is that sites aren't sending Cookies.
JS: mistakes can happen; what we can do is make tools good, language clear enough, do more fine-grained control. That's about all we can do. XDR does have a small risk, but it also supports a smaller feature set. No matter what we do to expand that feature set, we introduce mistakes.
Bryan: by increasing the scope of the functionality, we need to make an informed decision about [security issues].
SD: (citing Jonas' feedback)
access control follows user agents privacy policies.
... which user agents?
JS: I think spec. text should reflect that user agents privacy policy should be followed.
SD: one more high level issue.... one was preflights. any more questions on preflights?
EL: In my opinion, virtually
everything depends on the preflight. Sounds like making
preflight more restrictive, etc., are [answered]. Responses to
OPTIONS request are not cacheable.
... if am a server Fidelity with partner PayPal, response
otherwise cacheable. Some intermediary proxy would cache that
response. No preflight required. No actual concern here, unless
Fidelity were to mistakenly overgrant permissions in headers.
Server that chooses to participate in OPTIONS has to be worried
that intermediate proxy will cache response.
JS: right now a server can say allow " * ". If that gets cached on the way, that would be bad.
MJS: do proxies respect VARY header?
EL: it's a HTTP/1.1
feature.
... IE's support for VARY is dismal.
... servers may be silly to allow " * " for desirable
domains.
JS: we always make OPTIONS
requests with cache-control no cache. We can do this.
... I'm more concerned than you are here.
EL: I don't know if you know this, but beta2 does send origin (like access control)
MJS: would you (Microsoft) implement a subset of access control that matches XDR's header exchange, if it is a clean subset ?
EL: on the one hand, I understand the appeal, on the other hand, I worry about mixing our implementation with your spec.
JS: I think we can construct the spec. in such a way that you could use the same syntax, and not impede the path forward. The one concern is that it makes it very attractive for people to limit themselves to the subset that IE supports.
ZX: if the spec clearly spells out that some UA may support this mode, and that's limited, it seems conceivable.
SD: we are serious about interoperability. We'd like to see how can do access control with XDR. In IE8 this will be very difficult.
ZX: whatever change we can do with IE8 is very small.
JS: it's an incompatibility because of POST not being preflighted in XDR.
EL: it's an incompatibility among myriad.
MJS: on the XDR implementation, you wouldn't get the preflight. You're opting into two different security models. In the GET case we could construct a similar path, but not with POST.
adjourn meeting