On Wed, 08 Sep 2010 15:02:12 -0400 Dmitri Pal <d...@redhat.com> wrote:
> Simo Sorce wrote: > > On Tue, 07 Sep 2010 14:45:49 +0200 > > Pavel Zuna <pz...@redhat.com> wrote: > > > > > >> Enough text. Waiting for comments. :) > >> > > > > I have one question. > > Have you made any consideration wrt security ? > > > > For example you say that you can push a complete state in a URL so > > that you can bookmark it. > > How does this cope with authentication ? > > Is there any way to validate the state is legit server side, or > > does it mean we make it an easy target for XSS exploits ? > > Last thing I want to see is an admin clicking a link and finding out > > that link actually granted some permission to the malicious user > > that sent him an carefully crafted email ... > > > > > > Currently each request is authenticated via GSSAPI but with some > planned changes we will switch to using cookies which would speed up > things. A forged URL will not help if you do not have the cookie. If > you have the cookie there is no URL you can't go to. You will be > denied if you submit something you are not allowed to submit. This is > checked on the server side. Yes, that's not the issue. The scenario is this: - Admin use Joe, goes on http://my.ipa.domain.dom/ and does some administration, his browser has a cookie. - Admin Joe sees a pop-up from his MUA, open mail and sees user Foo asking for some help, and see screenshot here: <crafted URL> - Admin Joe clicks the link which actually performs an action against the ipa server. Is this prevented? how ? Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel