[Freeipa-devel] webUI code restructuring [wall of text, diagrams, ... you've been warned!]

[Adam Young]

On 09/08/2010 03:37 PM, Simo Sorce wrote:
> On Wed, 08 Sep 2010 15:02:12 -0400
> Dmitri Pal<dpal at redhat.com>  wrote:
>
>    
>> Simo Sorce wrote:
>>      
>>> On Tue, 07 Sep 2010 14:45:49 +0200
>>> Pavel Zuna<pzuna at 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.
>
>