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

Just one comment, Jonas said "Most content authors are not adverse in
any type of programming" but don't many people use script hacks to get
the desired functionality?  It seems to be the issue is not about
whether the content author can do programming, but whether the program
will run in the browser or the server.

Cheers,
Dave

> -----Original Message-----
> From: public-appformats-request@w3.org 
> [mailto:public-appformats-request@w3.org] On Behalf Of Jonas Sicking
> Sent: Wednesday, January 23, 2008 1:00 PM
> To: Jon Ferraiolo
> Cc: Arthur Barstow; public-appformats@w3.org; 
> public-appformats-request@w3.org
> Subject: Re: [access-control] Editorial comments on 
> Requirements Appendix v1.137
> 
> 
> 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?
> 
> 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.
> 
> 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?
> 
> >  > 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.
> 
> 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.
> 
> On my own personal site I do certainly have scripting access, 
> but not on other server spaces offered to me.
> 
> > 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.
> 
> > 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?
> 
> > 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.
> 
> >  > 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
> 
>

Received on Wednesday, 23 January 2008 22:29:10 UTC