Re: Policy enforcement point

Jon Ferraiolo wrote:
>  > 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.

But we're still giving servers the ability protect themselves against 
sharing their security policy if they so wish, by using server side PEP.

Sounds to me like your argument is simply that client side PEP adds 
complexity without adding much value. Is that correct?

> My opinion is that it would be better to adopt a different approach where:
[snip]
> 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.

As I said, lets talk about the problems first. Otherwise it will be hard 
to see if the proposed solutions solve the problems.

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

Sorry, this is very much lacking the detail I was asking for so I can't 
really evaluate it one way or another.

Best Regards,
/ Jonas

Received on Monday, 4 February 2008 22:33:26 UTC