Jon Ferraiolo wrote:
Hi Jonas,
I realize that I am not going to convince you, but I have responded
below in any case to further my arguments that it's OK if Access Control
happened to require a server-side scripting language. To some level,
this is an academic debate, but from a different point of view, it is
highly relevant. If we eliminate the requirement that users are able to
just plunk an XML file on a server and instead require them to use a
server-side scripting language, then the (so-called) PEP can happen on
the server, where the server logic decides on which sites are allowed or
denied to do GET or POST, instead of the browser. By moving the PEP to
the server (and therefore pretty much forcing the community to use PHP,
ASP, JSP, or whatever), data only gets transmitted to authorized
clients, whereas with Access Control today the data gets transmitted all
the way to the client, which then decides whether to discard it or not,
which has some shortcomings, such as opening up the possibility of
man-in-the-middle attacks. I believe the server-side approach would
produce a simpler spec, provide for more efficienct transmission,
provide more flexibility to developers, and promote a more secure Web.
I'll be starting a new thread exclusively about PEP shortly.
Jonas Sicking <[EMAIL PROTECTED]> wrote on 01/23/2008 12:59:49 PM:
> Jon Ferraiolo wrote:
>
> > > * It should not be possible to issue cross-site POST requests
> > > containing XML data.
> > >
> > > This is because some deployed SOAP servers communicate using
XML
> > > sent over POST requests and could perform potentially dangerous
attacks.
> >
> > There has probably been long discussion in this area, but I'm not
> > confident I have full knowledge of past discussion. Nevertheless, here
> > is my response: Yes, we don't want Access Control to provide an attack
> > vector against SOAP servers; however, isn't there a way to allow
> > cross-site POST requests containing XML data without providing an
attack
> > vector against SOAP servers? For example, Access Control is
required to
> > send XML/SOAP data in a manner that will not work against SOAP
servers,
> > such as prefixing some invalid characters in front of the XML data?
>
> What would be the advantage of that?
To prevent attacks on SOAP servers.
I mean, what is the advantage over what is in the spec today?
>
> Doing so would mean that you couldn't use normal tools on the server
> side to deal with the response but would have to cut in to the parse
> stream and strip away the initial characters.
Yes. But IMO that's really not a very big deal. Sample PHP, ASP, JSP,
etc. code could be made available that shows how to do the stripping
with a single line of boilerplate code.
>
> Also, how would you do this in such a way that it works for all content
> types, not just XML?
>
> > > * Should try to prevent dictionary-based, distributed,
brute-force
> > > attacks that try to get login accounts to 3rd party servers, to
the
> > > extent possible.
> > >
> > > * Should properly enforce security policy in the face of
commonly
> > > deployed proxy servers sitting between the user agent and any of
> > > servers with whom the user agent is communicating.
> > >
> > > * Should not allow loading and exposing of resources from 3rd
party
> > > servers without explicit consent of these servers as such
resources
> > > can contain sensitive information.
> > > ]]
> > >
> >
> > How about a security requirement that takes into account how it is
human
> > nature to take the easy way out. Perhaps "Should not be designed such
> > that unsophisticated server developers unwittingly expose their
site or
> > end users to new vulnerabilities." I am thinking that it would be
bad if
> > large parts of the community unwittingly set up their servers with
> > Access Control to say allow everyone, or allow a particular set of
> > domains, because unsophisticated developers are likely unaware of
> > malicious tricks that people might use.
>
> Sounds ok to me. Could you write up a complete proposal for what you
> want added? It sounds like this is partially covered already by
> requirement 13?
OK with me if you just use the sentence I provided above.
Requirement 13 came up on the call today too. I suggest we change it to say:
Should reduce the risk of inadvertently allowing access when it is not
intended. I.e. it should be clear to the content provider what access is
granted and what is not.
Actually, this looks like a replacement of requirement 13 rather than
just an edit. But the cache part is mentioned in requirement 1 so I
think that is ok.
> > > 3. Req #4 - change to:
> > >
> > > [[
> > > Must be able to easily deploy support for cross-site GET requests.
> > > Additionally, should not have to use server-side scripting (such
as
> > > PHP, ASP, or CGI) in a typical server configuration.
> > > ]]
> >
> > I disagree with this requirement. At least make it may or a should
> > instead of must. First off, how many web services today do not use
> > server-side scripting, and just post a single static XML or JSON or
> > whatever file (my guess is only a small percentage)?
>
> It's not about server capability, but author capability. Most content
> authors are not adverse in any type of programming.
My counter-argument: We are already requiring authors to learn the
syntax of a new PI (in the case of XML) or require that they set HTTP
headers (if not XML). Also, we most definitely want people to plow
through any informative write-ups on security issues, which (in order
for them to understand those issues) represent a significant learning
curve. Therefore, there already is a learning curve to opt-in to Access
Control.
Learning to program PHP is certainly more complicated than simply
putting an .htaccess file on the server.
IMO it would not be any more complex for friendly organizations to post
some non-normative sample PHP, ASP, JSP, etc. which shows how to achieve
the desired effect. In addition to showing how to use Access Control,
these samples could demonstrate other recommended techniques, such as
how to achieve CSRF protection.
We should certainly do that too.
> There are also a lot of servers that are configured to not allow content
> authors to execute scripts. This has been the case in most professional
> environments where I have been offered server space, or where I have
> been offering server space to co workers.
I have to plead limited knowledge about how the majority of hosting
sites are set up, but I thought PHP support was fairly common. BTW - I
don't think it is a priority to satisfy every possible usage scenario.
It's OK with me if Access Control is only available to people who have
access to server-side scripting.
>
> On my own personal site I do certainly have scripting access, but not on
> other server spaces offered to me.
But that doesn't really address my assumption that useful web services
require some level of server-side programming. Your point is that some
people have web content that they put on a hosted site, but that's
different than offering web services. In my mind, the critical
requirement is to enable cross-site web services, not cross-site content.
I think cross site content is important too, especially in scenarios
where a "site" is spread out over several different domain names for
security reasons (like what myspace does).
> > Second, if you use
> > a format other than XML, then you need server scripting in order to
set
> > the HTTP headers.
>
> At least Apache does not need scripting to set http headers, but rather
> just configuring the server (though .htaccess files). I suspect this is
> possible with most other servers too.
Unsophisticated users won't know how to do that.
I think a lot more authors are able to use .htaccess files. They are
already quite commonly used.
Additionally .htaccess files lend themselves very well to tooling. For
example my hosting company (dreamhost) let me set up usernames and
passwords for individual directories and in the backend writes the
information to .htaccess files.
The same can not be said for scripting.
> > Third, the following is not a big burden: <?php
> > $string = fopen("textfile.txt","r"); echo $string; ?>
>
> Yes, I think requiring that would reduce the number of people that would
> be able to put cross site reachable content on servers would be reduced
> by a lot.
>
> > Fourth, for POST, you need back-end logic.
>
> Yes, that's why the requirement specifically says GET.
>
> > Fifth, for CSRF protection, you need back-end logic.
>
> What sort of CSRF issues are you worried about with a static GET
resource?
>
> > > 4. Req #5 - change to:
> > >
> > > [[
> > > It should be possible to put the resource, that is made available
> > > cross-site, in its normal format on the server. It should also be
> > > possible to use normal development tools to interact with the
> > > resource directly on the server. That is, it should not be
necessary
> > > to repackage or reformat the resource just to make it possible to
> > > load from other servers.
> > > ]]
> >
> > I would change the above requirement to say that it should be as
easy as
> > possible for server developers to use Access Control, with minimal
> > changes to how web servers work today, including the ability to leave
> > data in their normal formats on the server.
>
> Isn't that basically what the requirement already says? What part is the
> important difference?
Art's wording supplies a specific solution (i.e., "interact with the
resource directly on the server") whereas mine attempts to state the
requirement in terms of what we need to achieve.
First of all I do think it's important to be able to using development
tools to interact directly with the content on the server. Many
development tools, such as Dreamweaver and Nvu, as built in
functionality both for editing documents directly on a remote server, as
well as features for publishing a whole site to a server.
Forcing them to have to use separate tools to interact with the data on
the server would seriously affect their normal work flow.
Second, it seems that as long as you leave the data in their normal
formats on the server you can interact with them using the normal
development tools. So I don't understand the difference between the
wordings, other than that Arts is more explicit.
Best Regards,
Jonas Sicking
