On 03/16/2010 10:23 AM, Caleb James DeLisle wrote: > > > Marius Dumitru Florea wrote: >> Hi Caleb, >> >> 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) >> >> So the token is the same for consecutive (GET) requests coming from the >> same user? >> >>> isTokenValid checks the current user against the token then removes the >>> entry from the HashMap so the token >>> may not be reused. >> >> What happens if the user opens in edit mode two different pages? Isn't >> the second save invalidated by the first save? > > Good point I missed. I would have to have a script to disable such an onerous > 'feature' :) > I guess it will only work if a single number is valid basically forever. I > wish components had access to the > Request, Response and Session so it could expire on logout.
What if this map would store a mapping (user + url) -> token, or (user + reason) -> token, where "reason" would be some description of the intended change like "edit:Main.Test" or "rights:SomeUser+comment-edit"? getToken would return different tokens for different pages/"reasons" and isTokenValid would need to provide the same url/"reason" for check to succeed. > > Caleb > >> >> Thanks, >> Marius >> >>> 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
