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
