On 03/18/2010 05:07 AM, Caleb James DeLisle wrote:
>
>
> Alex Busenius wrote:
>> On 03/16/2010 09:33 AM, Caleb James DeLisle wrote:
>>> I don't want this proposal to die because of unnecessary noise which I
>>> introduced,
>>> I have thought about it and I am in agreement with the general idea of
>>> sending the user a hash which
>>> must be returned with the post in order for the data to be saved.
>>>
>>> I don't like adding code to xwiki-core so I suggest this be made into a
>>> component.
>>> We would need 2 functions:
>>> String getToken()
>>> boolean isTokenValid(String token)
>>>
>>> getToken uses org.xwiki.bridge.DocumentAccessBridge.getCurrentUser() to get
>>> the user who called it
>>> and the user name is stored in a HashMap of <String, String> with a random
>>> string of text.
>>>
>>> If getToken finds a token already in the map, it returns that token (so it
>>> may be called multiple times
>>> in the generation of a page)
>>>
>>> isTokenValid checks the current user against the token then removes the
>>> entry from the HashMap so the token
>>> may not be reused.
>>>
>> Did I understand the idea correctly that isTokenValid should be called
>> from all macros that modify data, but not from the old core directly?
> No the old core would call it but it wouldn't itself be in the old core. The
> call goes something like
>
> TokenGenerator tg = Utils.getComponent(TokenGenerator.class);
> if (tg.isTokenValid(request.getParameter("securitytoken"))) {
> //do save action...
> }
>
> This makes the old core dependent on the token generator so we have to take
> care that the token generator
> does not become dependent on the old core because cyclic dependency is
> forbidden by maven.
>
Ah, I see. Cyclic dependencies should not be a problem as long as the
tokens are cached locally in the token generator and not in the HttpSession.
> Suppose the authentication code were to fire login and logout events with the
> ObservationManager, this way a
> user could have a token for the duration of a login (I don't like it but
> invalidating one save window with another
> is unacceptable IMO.)
>
This events might still be useful also for the per user+url token cache
I wrote about in another mail, to clean up the cache from unfinished
requests (user opens edit page and closes the tab).
Alex
> WDYT?
>
> Caleb
>
>> So
>> for example the SaveAction (which saves edited documents at the moment)
>> would not be protected for now, but the future action component would
>> also use isTokenValid at some point?
>>
>>
>>> If a configuration parameter is specified to disable the component,
>>> getToken returns "" and isTokenValid
>>> returns true.
>>>
>>> WDYT?
>>>
>>> Caleb
>>>
>>>
>>> Caleb James DeLisle wrote:
>>>> Sergiu Dumitriu wrote:
>>>>> On 03/10/2010 07:44 PM, Caleb James DeLisle wrote:
>>>>>> Take a look at the "sammy is my hero" worm, myspace sent a hash to the
>>>>>> user like the one you propose,
>>>>>> the worm made the required get request to get the hash, then made the
>>>>>> post along with the hash.
>>>>>> What prevents javascript from opening the page with the hash in an
>>>>>> iframe and then reading in the iframe
>>>>>> to get the hash, then creating a form with the required data and posting
>>>>>> it to the save action?
>>>>>>
>>>>>> If we were to combine a requirement for post requests with checking of
>>>>>> the referrer header, then we
>>>>>> would block links, forms and javascript based attacks leaving only an
>>>>>> attack through older versions
>>>>>> of flash which support referrer forgery and at this point the difficulty
>>>>>> of the attack becomes such that
>>>>>> we need to consider a wider array of attack vectors.
>>>>> Sammy also required that XSS is enabled.
>>>>>
>>>>> Protecting from attacks originating in the wiki is kind of impossible at
>>>>> the moment, since JS can be inserted anywhere, and there's no (nice) way
>>>>> to prevent attacks from JS inside the application. As long as JS can be
>>>>> inserted, an attacker can do all the steps that the client would do to
>>>>> perform an action.
>>>>>
>>>>> The secret token works as a prevention mechanism when the attack comes
>>>>> from another site because the browser security model prevents the attack
>>>>> code to read the form.
>>>> I just did a few tests on iframes and I was wrong, they do have good same
>>>> origin policy.
>>>>
>>>> Caleb
>>>>
>>>>>> Caleb
>>>>>>
>>>>>>
>>>>>> Alex Busenius wrote:
>>>>>>> Unfortunately, using POST requests instead of GET requests is not
>>>>>>> enough. It will not prevent attacks that use forms and/or JavaScript to
>>>>>>> generate POST requests.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>
>>>>>>> On 03/09/2010 02:48 PM, Caleb James DeLisle wrote:
>>>>>>>> I had thought about proposing this myself but decided against it
>>>>>>>> because it seems
>>>>>>>> to me like a workaround for problems which can be solved in other ways.
>>>>>>>>
>>>>>>>> Suppose we were to add a check to the actions which alter data which
>>>>>>>> made sure the request method
>>>>>>>> was 'post' and made it configurable in one of the configuration files?
>>>>>>>> We would have
>>>>>>>> to look over the default skins for incorrect links and leave the
>>>>>>>> configuration
>>>>>>>> option off by default for backward compatibility at least until the
>>>>>>>> next major version
>>>>>>>> but we could provide wiki operators the ability to prevent CSRF.
>>>>>>>>
>>>>>>>> Caleb
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> devs mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>
>>>>>> _______________________________________________
>>>>>> devs mailing list
>>>>>> [email protected]
>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>
>>>> _______________________________________________
>>>> devs mailing list
>>>> [email protected]
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>> _______________________________________________
>>> devs mailing list
>>> [email protected]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> _______________________________________________
>> devs mailing list
>> [email protected]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
