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