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