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 21:01:09 UTC