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

Hi Art,
See comments inline below.
Jon

public-appformats-request@w3.org wrote on 01/23/2008 07:18:23 AM:

>
> Below are some editorial comments on the Requirements appendix (v1.137).
>
> Regards, Art Barstow
>
> 1. The intro could be simplified by using something like:
>
> [[
> Requirements (non-normative)
>
> This requirements for this specification are:
> ]]
>
> 2. Req #1 - change to:
>
> [[
> 1. Security requirements
>
>   * Must not introduce new attack vectors.

+1

>
>   * Must not introduce attack vectors to servers that are only
> protected only by a firewall.
>
>     Some servers authenticate solely by relying on the fact that the
> user can connect to the server.
>
>     Although anyone can issue an arbitrarily formatted request to a
> server on the internet, this is not true for servers on intranets
> behind firewalls. The only requests that can be issued to such
> servers today are ones that browsers send out. This includes GET
> requests (from a multitude of features in HTML, such as the HTML img
> element) and POST requests from the HTML form element.
>
>   * 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?

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


> 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)? Second, if you use a format other than
XML, then you need server scripting in order to set the HTTP headers.
Third, the following is not a big burden: <?php $string =
fopen("textfile.txt","r"); echo $string; ?>  Fourth, for POST, you need
back-end logic. Fifth, for CSRF protection, you need back-end logic.

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

>
> 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.
> ]]
>
> 6. Req #7 - change to:
>
> [[
> It should be possible to distribute content of any type.
> ]]
>
> 7. Req #7 - I don't understand the last sentence in this context:
>
> [[
> This applies equally to the request and response entity body.
> ]]
>
> 8. Req #9 a) change "wrongly" to "incorrectly"; b) change "whole" to
> "the entire"
>
> 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 ...
> ]]


>
>
>