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