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

[Adam Young]

On 09/08/2010 02:47 PM, 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 ...
>
> Simo.
>
>    


Simo,

Two different concepts here, the state in the URL, and the security model.

The state is completely a client side concept, it manages the values 
used to repopulate the webui.  The existing security model prevents 
calls against the server if you don't have a Kerberos key set.  We are 
providing no more access than is already availble to the server.  
Kerberos is our friend here, as it obviates what seem to be the most 
common JSON attacks.

Bascially, the state only tells the web ui what to execute.  It 
hasthings like :current tab is user, currrent facet is search, search 
criteria was 'Ada'.   No code, it is not interprested as code.

The security model is a different beast.  We are doing nothing with the 
web server that you canot do already using the https/xml APIs.  So if 
there is aproblem, it is out there today.  I make no judgements on that, 
as I am not a security expert.

An early problem with JSON was that it was basically just a block of 
code processed with an 'eval' statmet.  THe browser now handles the 
parsing for us, with the exception of older browsers, where we use a 
code library.  In either case, we avoid the eval issues.

Also, since we own both the client and server side of the equasion, we 
don't have to worry about a maliciosu third party injecting code  into 
our stream.  The tunnel between client and server is encrypted, and we 
only send JSON requests back to the server of origin.  In fact, as far 
as I know, the same origin policy is still in effect, and  
(Fedora/RHEL/Mozilla) does nothing to circumvent it.