Re: [access-control] Editorial comments on Requirements Appendix v1.137

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.

Jon

Jonas Sicking <jonas@sicking.cc> 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.

>
> 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.

>
> >  > 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.

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.

>
> 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.

>
> > 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.

>
> > 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.

>
> > But given my disagreement
> > with reqt #4, my belief is that it is OK if Access Control requires
that
> > it is necessary to front-end the data with a small amount of server
> > scripting, such as (once again) <?php $string =
> > fopen("textfile.txt","r"); echo $string; ?>
>
> I don't think doing this is ok. I also don't see how the above code does
> anything useful.

Sorry. The full example would include a couple of additional lines that set
content type and HTTP headers as required by Access Control in addition to
sending down the text file.

>
> >  > 5. Req #5 - I don't understand the last sentence in this context
(for
> >  > example what is "this"):
> >  >
> >  > [[
> >  > This equally applies to sending a resource as part of the request
> >  > entity body.
> >  > ]]
>
> "this" refers to the rest of the requirement. How about this:
>
> It should be possible to put the resource that is made available
> cross-site in its normal format on the server. It should be possible to
> use normal development tools to interact with the resource directly on
> the server. I.e. it should not be needed to repackage or reformat the
> resource just to make it possible to load from other servers.
>
> The above paragraph equally applies to sending a resource as part of the
> request entity body.
>
> >  > 6. Req #7 - change to:
> >  >
> >  > [[
> >  > It should be possible to distribute content of any type.
> >  > ]]
>
> Sounds good
>
> >  > 7. Req #7 - I don't understand the last sentence in this context:
> >  >
> >  > [[
> >  > This applies equally to the request and response entity body.
> >  > ]]
>
> How about:
>
> Content of any type should be possible to distribute. I.e. we should not
> limit ourselves to content of a particular type.
>
> The above paragraph applies equally to the request and response entity
body.
>
> Though I think that the text as it is is as clear.
>
> >  > 8. Req #9 a) change "wrongly" to "incorrectly"; b) change "whole" to

> >  > "the entire"
>
> Sounds good
>
> >  > 9. Req #10 - the second sentence uses the work "example" three times

> >  > and hence is bit hard to understand. Perhaps something like the
> >  > following would be clearer:
> >  >
> >  > [[
> >  > For instance, the following examples should be possible to use for
> >  > resources residing on ...
> >  > ]]
>
> Sounds good.
>
> / Jonas