Re: Policy enforcement point

Hi Jonas,
See below.
Jon


public-appformats-request@w3.org wrote on 02/02/2008 05:24:59 PM:

>
> Hi All,
>
> Starting a new thread on this since I want to only talk about the
> requirements and problems we're trying to solve first. Before getting
> involved in discussing the various solutions.
>
> We have received a number of comments saying that the policy enforcement
> point (PEP) should be the server rather than the client.
>
> First I'd like to note that some of the enforcement will always have to
> live in the client. The client is already today what enforces the
> same-origin policy. If you open a HTML resource from another site in an
> <iframe>, or a PNG resource from another site in an <img>, the network
> request will always happen, but the client is what stops other sites
> from reading the data.

Yes. Of course, as we all know well, the client today does not stop
<script>, <img> and various other elements from going to other sites, and
the current same-domain policy is as basic as it can be (i.e., either you
are part of the same domain or you are not).

>
> Second, the argument has been brought up that server side PEP is more
> flexible. However the current access-control spec allows both
> server-side and client side filtering, so all the flexibility of server
> side PEP should already be there. If that is not the case, please
> explain exactly what flexibility is lacking in the current proposal.

Yes, of course, servers can still do what they want to in the presence of
Access Control.

Access Control has a negative from a security perspective in that, if you
don't implement server-side policy management and leave it to the client,
then the data comes down the pipe only to be discarded by the client after
failing the Access Control check, but that means that malicious clients
(i.e., clients that pretend to implement Access Control properly but don't)
or man-in-the-middle software have access to the data.  Therefore, if your
data isn't public, then I would recommend server-side PEP to the web
community. The basic rule in security is that the server should not blindly
trust the client, and the client should not blindly trust the server.

If the server supports POST, then almost certainly the server will want to
implement CSRF protection logic.

Therefore, if you have non-public data or you support POST, then you
usually need to have server-side logic anyway, in which case there isn't
much use for client-side PEP. If you have public data, then you also don't
need client-side PEP since it's OK for everyone to access the data.

My opinion is that it would be better to adopt a different approach where:

1) Simplify the client: Define a new API in the client (e.g., JSONRequest,
a new parameter to XMLHttpRequest, or something entirely new such as a
CrossSiteRequest) which can send GET and POST requests to cross-domain
URIs. Ideally, this new API work not work with existing SOAP servers. Look
at JSONRequest to see how simple the client-side would be (i.e.,
JSONRequest.get() and JSONRequest.post()).

2) Push all PEP to the server: Make it so that a server developer has to do
something new in order to opt-in to the new cross-site mechanism. In the
documentation that explains what a server needs to do to opt-in, explain
why it is necessary to implement a PEP on the server if the data is not
public and warn about CSRF attacks.

3) Provide some companion open source: Find someone in the community to
develop open source PHP (and maybe JSP, ASP, etc.) that implements
declarative allow and deny logic that is similar to the grammar that exists
in the Access Control spec today. As a result, a novice developer could
customize a single PHP file (or JSP or ASP) to implement whatever access
control logic he wants.

4) Design the new approach such that it can work reasonably well in today's
browsers via a pure JavaScript implementation that uses a dynamic script
tag under the hood so that this feature is available in today's browser via
JavaScript but uses native browser support as new browsers ship.

It's not that Access Control as it exists today is bad or doesn't have
value, it's just that it would have been better (i.e., simpler, more
secure, more flexible, faster adoption in the industry) if the group had
taken a different approach.

>
> Third, people has been bringing up security concerns with client side
> PEP. If you are concerned about client side PEP, please elaborate on
> exactly what attacks you are worried about in the current proposal.

Over at OpenAjax Alliance we have had lots of discussion about the security
implications of Access Control. My personal opinion, informed by this
discussion, is that there is some vulnerability in selected scenarios to
man-in-the-middle attacks and password stealing attacks, but these
scenarios appear to be on the fringe and unlikely to happen often in
practice, and if they do happen often enough, the community can be educated
about how to deal with them. In general, the WAF WG should be commended for
their strong efforts to take into account security issues.

>
>
> In short, if you have concerns about the ability to do client side PEP,
> please describe in detail those concerns. Don't jump directly to
> alternative solutions.
>
>
> Best Regards,
> Jonas Sicking
>