Created on 2011-02-22 20:15 by joseph_myers, last changed 2016-07-13 00:22 by rouilj.
|msg4246||Author: [hidden] (joseph_myers)||Date: 2011-02-22 20:15|
|msg4786||Author: [hidden] (ber)||Date: 2013-02-04 09:43|
Joseph, thanks for creating the issue. Can you point to a good explanation how this protection can work? Thanks, Bernhard
|msg4788||Author: [hidden] (schlatterbeck)||Date: 2013-02-04 10:13|
On Mon, Feb 04, 2013 at 09:43:44AM +0000, Bernhard Reiter wrote: Thanks for putting me on the nosy list. I think I can offer some guidance on how to implement this but currently don't have too much time myself... And I agree this should be high prio. Ralf
|msg4790||Author: [hidden] (joseph_myers)||Date: 2013-02-04 14:01|
https://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet (for example) discuss various approaches used to protect against CSRF. For Roundup I still think the right approach is a secret token used in all forms (and it should not be possible to compute the session ID from this token, so that having a leaked copy of a form doesn't allow a third party to generate a cookie to impersonate the user).
|msg4791||Author: [hidden] (ber)||Date: 2013-02-04 14:53|
Joseph, thanks for the hints!
|msg4935||Author: [hidden] (rouilj)||Date: 2013-10-09 20:31|
Also note that the CSRF token may need to be a single use token. So as soon as a post is made with the token, it gets masked/rewritten and is no longer valid. This protects again BREACH types of attacks against the token. http://breachattack.com/ which recommends the following mitigation methods: Disabling HTTP compression Separating secrets from user input Randomizing secrets per request Masking secrets (effectively randomizing by XORing with a random secret per request) Protecting vulnerable pages with CSRF Length hiding (by adding random number of bytes to the responses) Rate-limiting the requests
|msg5843||Author: [hidden] (rouilj)||Date: 2016-07-13 00:22|
I wonder if we could use the one time key mechanism used for password resets here as well. For each form we generate a template function that produces: <hidden name="otk" value="....." > and change RetireAction, RestoreAction, EditCSVAction, EditItemAction::handler, NewItemAction::handler, RegisterActon::hander, (maybe SearchAction) to verify the otk against what is stored int he session database. Would this basic idea work?
|2016-07-13 00:22:33||rouilj||set||messages: + msg5843|
messages: + msg4935
|2013-04-08 22:07:19||eadler||set||nosy: + eadler|
|2013-02-04 14:53:18||ber||set||messages: + msg4791|
|2013-02-04 14:01:29||joseph_myers||set||messages: + msg4790|
|2013-02-04 10:13:25||schlatterbeck||set||messages: + msg4788|
|2013-02-04 09:43:44||ber||set||priority: high|
nosy: + schlatterbeck, ber
messages: + msg4786