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

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

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

Received on Wednesday, 23 January 2008 22:48:17 UTC