Jon Ferraiolo wrote:
Hi Anne,
The FAQ was very helpful in documenting the rationale behind some of the
approaches in the Access Control spec. However, I disagree with most of
the reasoning, as shown below. The use case are a step in the right
direction, and I have some feedback on them. (Further down)
>Access Control for Cross-site Requests DESIGN DECISION FAQ
>
>** Why is there a second check for non-GET requests?
>
>For non-GET requests two checks with Access-Control HTTP headers and
><?access-control?> processing instructions are performed. Initially a
>"permission to make the request" check is done on the response to the
>authorization request. And then a "permission to read" check is done
on the
>response of the actual request. Both of these checks need to succeed in
>order for success to be relayed to the protocol (e.g. XMLHttpRequest).
I appreciate the attention that the WG has put into trying to promote a
secure approach to deliverying POST requests, but IMO it would be better
to pursue a different technical strategy, such as what we see in
JSONRequest or something derivative of that. With JSONRequest, POSTs are
allowed without requiring a prior GET (or HEAD or OPTIONS). JSONRequest
also can be made available via a JavaScript implementation that works in
today's browsers. Its approach is simpler for everyone involved, both
server-side developers and client-side (i.e., JavaScript) developers.
I'm not sure if JSONRequest is perfect as is (e.g., only supports JSON
and not XML), but it was designed by Doug Crockford, who gives talks at
Ajax conferences on web security, and IMO he has a good handle on
security issues.
Using JSONRequest here would not fulfill requirement 7 from the spec as
JSONRequest can only be used to POST JSON data.
Maybe we need to clarify that 7 applies to both POSTing and GETtin data.
Anne, would you mind adding text to state that? We should probably
expand 5 to include sending of data too.
I don't see how JSONRequest can be expanded to include posting XML data
without violating requirment 1, especially the second pullet point.
>** Why are cookies and authentication information sent in the request?
>
>Sending cookies and authentication information enables user-specific
>cross-site widgets (external XBL file). It also allows for a user
>authenticated data storage API that services can use to store data in.
As I have said previously, I disagree that XBL (and XSLT) should impact
decisions about how to provide the best technology for cross-site data
access. The XBL and XSLT specs can say that user agents must allow
cross-domain access, just as is allowed for CSS stylesheets.
I don't understand why you think XML data is unimportant? I don't
believe that one-format-to-rule-them-all is ever going to work. It
hasn't in the past.
Where did the idea of user-specific widgets come from, anyway? IMO, that
would be a very, very low priority (approaching zero).
Why? User specific data seems very useful. It would be great to be able
to create mashups that pull my calender data from google calender as
well as my addressbook from yahoo mail.
The negative with sending cookies is that it opens up CSRF attack
opportunities when web sites say allow "*", which I expect would be the
most common scenario. There are other approaches to sending data to a
3rd party domain that are more secure and still achieve the same result.
Once again, JSONRequest does not send cookies. I assume that Doug
Crockford assumes that authenticated information (if necessary) would
come from be sent with the payload (rather than via cookies), which
means that if domain FOO wants to upload data to domain BAR, then domain
FOO's web page would require the user to someone enter their BAR
authentication information (which could be stored in FOO's cookies, not
BAR's cookies). With such an approach, the user will be told by FOO's
web page that this web page needs his BAR account information, so the
user gets to opt-in to allowing the cross-site POST, instead of the
current approach in Access Control where cookies (potentially with
credentials) are always sent without the user being aware.
Without sending cookies we can't satisfy requirement 12. Especially in
combination with requirement 3.
JSONRequest requires that I give my login data to the requesting site.
That seems scary.
>Cookies and authentication information is already sent cross-site for the
>HTML <img>, <script>, and <form> elements so this does not introduce a new
>attack vector. It simply makes use of the Web.
<img> and <script> only work with GET, so if a web server follows best
practices (i.e., only support POST when submitting data), then you
aren't subject to data submission attacks. There is no way to retrieve
data via <img>, so that doesn't allow data retrieval attacks. With
<script>, the only way to retrieve data is if the server supports
JSON-with-callback.
This is exactly how access control works too. You can issue GET requests
that include cookies and auth information to 3rd party sites, but you
can't retrieve data by default. You can only retrieve data if the server
explicitly allows it.
> Because of these factors, I don't think <img> and
> <script> should be used to say that the web is already vulnerable.
I'm not sure what you mean by this. All we are saying is that it is
already possible to issue GET requests that include cookies in a number
of ways. Do you not agree with this?
It is true that <form> works with both GET and POST and does send
cookies to other domains, which means web site developers today indeed
need to protect against CSRF attacks via cross-domain use of <form>,
where CSRF protection is usually is accomplished by the server actually
managing a session with the user where a random token is maintained
across the session (without storing it within cookies). Right now,
Access Control does not have a good mechanism for achieving
server-controlled session management with such a random token, largely
because it uses a client-side PEP approach. In fact, Access Control gets
in the way of the way most server developers would implement CSRF
protection.
Please elaborate as I don't understand what you mean here. If you think
access control allows for any specific attacks please describe in detail
the attack.
>** Why can't cookies authentication information be provided by the script
>author for the request?
>
>This would allow distrubted cookie / user credentials search.
>
>** Why is the client the policy enforcement point?
>
>The client already is the policy enforcement point for these requests. The
>mechanism allows the server to opt-in to let the client expose the data.
>Something it currently does not do and something which servers rely
upon the
>client not doing.
This confuses "access control" with "policy enforcement point". Yes,
browsers today implement an access control policy that (currently)
prevents (among other things) XHR from talking to other domains and
prevents frames from different domains to see each other's DOM. But
"policy enforcement point" means deciding which particular users or
which particular domains should have the ability to retrieve data or
change data.
With JSONRequest, the access control rules are loosened such that the
new mechanism (i.e., JSONRequest) is allowed to access other domains,
and therefore assumes that the policy enforcement point is the server
who receives the GET and POST requests. This approach makes more sense
and results in a simpler mechanism.
Sure, saying 'anyone can access the data' is simpler. It also seems to
open new attack vectors. Requirement 1 states that we must not allow new
attack vectors.
>Note however that the server is in full control. Based on the request
it can
>simply opt to return no data at all or not provide the necessary handshake
>(in form of the Access-Control HTTP headers and <?access-control?>
>processing instructions.
>
>** Why does the mechanism do both black- and whitelisting?
This is a result of requirements 4, 8 and 9 together.
>In case the server and documents hosted on the server are in control by
>different people it is necessary that the server people are able to
override
>the document people (if the document wants to share access) and vice versa
>(if the server wants to share access).
>
I think that both whitelisting and blacklisting represent a major
weakness in the Access Control spec. I have yet to see important use
cases where it makes sense for a particular domain FOO to allow access
to a particular domain BAR. In the real world, when would
http://www.facebook.com ever list a particular domain to which it would
provide access? As best as I can tell, the primary use cases are *
(i.e., allow everyone) and *.mydomain.com (i.e., allow access to all of
your own subdomains). For simplicity reasons, the best way to go is to
drop whitelisting and blacklisting entirely and therefore just support
*, which is what JSONRequest does.
I don't think that seems very far fetched that a set of servers want to
collaborate. For example www.livejournal.com and user.livejournal.com
might want to allow each other to read data. They are basically the same
site, but use different domain names for various security reasons.
>Access Control for Cross-site Requests USE CASES
>
>FOO in the scenarios below is a fictional person who lives in Havana and
>likes playing with Web technology that isn't implemented anywhere.
Of course, the "isn't implemented anywhere" is a bit of humor, but it
does point out a weakness with Access Control. It won't provide value to
the world until it is available in a majority of deployed browsers.
Since MS and Apple are not participating in the discussion so far, there
is a worry that their browser might never support Access Control. I have
no insight into what Apple is thinking regarding Access Control, but I
hearing security concerns from people at MS about Access Control within
discussion at OpenAjax. But let's suppose that Apple and MS do come
around and ultimately ship it, let's say in 3 years. It will then take
roughly another 3 years or so before the majority of deployed browsers
support the feature. On the other hand, JSONRequest can be implemented
in JavaScript and will work with today's browsers, and therefore the
community can use it immediately.
What the above paragraph translates into is that I would like to see a
requirement that says something about it being highly desirable that the
mechanism can run in today's browsers as they exist today (without
requiring the addition of a new browser plugin).
You are arguing that we shouldn't design a new standard because the new
standard doesn't work out of the box in all existing browsers. This
would seem to limit progress a whole lot. If we followed that we would
put most of W3C out of business, no?
I've heard ample interest from all major browser vendors, with possible
exception of microsoft, but I don't have as good personal connections
with anyone on the IE team as I do with the other browser vendors.
>* FOO owns test.example.org and test2.example.org. FOO uses XSLT
extensively
>on both domains and because FOO doesn't want to use a pre-processing
script
>to duplicate XSLT files he puts them all on test.example.org and
includes a
><?access-control allow="test2.example.org"?> at the top of them.
IMO opinion, the XSLT and XBL specs should simply say that user agents
should allow cross-site access, just like what happens today with CSS
and JavaScript. Don't need Access Control for that.
This would seem to open very scary new attack vectors. Just because a
spec is produced that says that it's ok to load new data types cross
site doesn't mean that server administrators automatically protect
themselves against that. Note that both XSLT and XBL can basically use
any raw XML file. All XSLT needs is one magic attribute on the root
element, and XBL might not even need that.
>* FOO has implemented the fictional OPEN DATA REST API on test.example.org
>to store data so that services that help him keep track of bookmarks,
>friends, et cetera can store the info on FOO's domain instead of their
own.
>This allows FOO to switch to any other service provider taking his data
>easily with him. Using Access Control he enables 2del.icio.us.invalid and
>flickr2.invalid to access his data so they can store and manipulate data.
>To keep other people from messing with his data the API only works if
you're
>authenticated with test.example.org.
I didn't fully understand the above workflow. This I understand: FOO has
a web site at test.example.org that implements OPEN DATA REST API. But
how is it that del-icio.us or flickr would even know about
test.example.org to invoke the OPEN DATA REST APIs on that site? And why
doesn't the web page at test.example.org simply invoke flickr or
del.icio.us APIs (probably using dynamic script tag with JSON today
using a particular API key) to retrieve the data and then upload it to
test.example.org? BTW - flickr does have a rich set of APIs today (after
all, it's part of Yahoo), but all I could find for del.icio.us were a
small number of APIs that seemed to work only via server-side
facilities. (Maybe I am missing something.)
The flow is that example.org inc advertises that they have implemented a
public REST API that provide certain services. Other sites then use that
API and build functionality on top of that.
Such APIs have been announced by very many web vendors already. Here are
some examples:
www.flickr.com/services/api
http://developer.yahoo.com/maps/simple/index.html
www.google.com/apis/adwords/
http://wiki.developers.facebook.com/index.php/API
>* FOO signs up for the personaldata.example.com Web service where you can
>enter all kinds of personal information, such as your address, credit card
>information, et cetera. Every shopping site that has a contract with
>personaldata.example.com can then easily extract data out of it as long as
>FOO is authenticated with personaldata.example.com which gives him a
better
>shopping experience.
Yikes! No way would any ecommerce site leverage the browser and access
control for anything involving credit card numbers. If there were such a
personaldata.example.com web service, then it would implement
server-to-server communications to deal with authentication and passing
of secure information on a case-by-case basis, with various legal
documents among the various parties. Therefore, I do not think this is a
valid use case.
I agree that banking is more scary and would generally require very
strong security checks.
>* FOO enables cross-site access to his FOAF file and hopes everyone will
>follow him so that the Tabulator http://www.w3.org/2005/ajar/tab becomes
>easier to use/write/etc.
This one needs more detail, such as would FOO allow everyone to have GET
access, everyone to have POST access, or what? (Note that if everyone is
given access, then there is no need for the complicated allow/deny
syntax for this particular use case. In fact, the only use case here
that might leverage allow/deny features is the OPEN DATA REST API, but
that one needs to be fleshed out some more.)
Yep, this exact use case would not need allow/deny rules.
Each of the use cases needs a small write-up about how the given use
case is accomplished today (or is not possible today) and what proposed
alternative technologies (e.g., JSONRequest) might be used instead of
access control to achieve the desired result.
As I've stated above, and many times before, JSONRequest fails to meet
many of our requirements. Such as 4, 5, 7, 8 in combination with 4, 9 i
think, 10, 11, and 12. And possibly even 1.
Best Regards,
Jonas Sicking
Jon
[EMAIL PROTECTED] wrote on 01/16/2008 05:23:06 AM:
>
> Hi,
>
> In the interested of moving forward and having to repeat myself a bit
less
> I created two documents:
>
> * http://annevankesteren.nl/temp/access-control-faq
> * http://annevankesteren.nl/temp/access-control-use-cases
>
> Feel free to ask questions if anything is unclear.
>
> Kind regards,
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>
