18 Mar
2010
18 Mar
'10
5:45 a.m.
On 03/18/2010 05:07 AM, Caleb James DeLisle wrote:
Alex Busenius wrote:
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.
On 03/16/2010 09:33 AM, Caleb James DeLisle
wrote:
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.
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? 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?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
If a configuration parameter is specified to
disable the component, getToken returns "" and isTokenValid
returns true.
WDYT?
Caleb
Caleb James DeLisle wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
>>> devs(a)xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs