On 09/08/2010 03:37 PM, Simo Sorce wrote:
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.

The browser prevents it ins straight URL attacks, using the policy of same server of origin.

Flash might be a potential attack vector.
I am not sure if browser cache poisoning is a real concern.


Is this prevented? how ?

Simo.


_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to