Re: [xwiki-devs] [proposal] Add support for secet token verification

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.

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 >>>> 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