[xwiki-devs] Protection against Cross-Site Request Forgery?
Hi devs, Should XWiki protect itself against CSRF? See http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29 and http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevent... for details. In short: an attacker could use something like: <img src="http://xwikiserver/bin/save/Some/Document?content=Hacked"/> to alter the wiki using another user's account. Protection usually involves embedding tokens in submitted forms and URLs. The good news is that it can be done transparently using a LGPL tool from OWASP. The bad news is that it does not protect against attacks from the same wiki, but only for Cross-Site attacks. And it also breaks direct manipulation using URLs (as an expert user, I do enter URLs directly instead of clicking through the interface, and I won't like it if I couldn't do it anymore). So, WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/
Yes we should be protected against that. We also should have ways to limit the rights to insert JS and scripting in pages based on similar rights are the "programming" rights. It should be possible to run a wiki where only a certain group of people is allowed to insert that type of content in pages. This should be additionally handled at insert time (in addition of execution time like the programming rights) We also should be able to list all pages that make use of these advanced features: - programming - scripting - javascript Ludovic Sergiu Dumitriu a écrit :
Hi devs,
Should XWiki protect itself against CSRF? See http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29 and http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevent... for details.
In short: an attacker could use something like: <img src="http://xwikiserver/bin/save/Some/Document?content=Hacked"/> to alter the wiki using another user's account. Protection usually involves embedding tokens in submitted forms and URLs. The good news is that it can be done transparently using a LGPL tool from OWASP. The bad news is that it does not protect against attacks from the same wiki, but only for Cross-Site attacks. And it also breaks direct manipulation using URLs (as an expert user, I do enter URLs directly instead of clicking through the interface, and I won't like it if I couldn't do it anymore).
So, WDYT?
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Nov 15, 2009, at 1:29 PM, Ludovic Dubost wrote:
Yes we should be protected against that. We also should have ways to limit the rights to insert JS and scripting in pages based on similar rights are the "programming" rights.
It should be possible to run a wiki where only a certain group of people is allowed to insert that type of content in pages.
This should be additionally handled at insert time (in addition of execution time like the programming rights)
We also should be able to list all pages that make use of these advanced features:
- programming - scripting - javascript
Re JS note also that we have a jira issue to allow disabling the HTML macro. This is not enough obviously since users can add JSX. In addition this issue is about completely removing the HMTL macro, not settings rights on it (which we could/should do in the same way as we're doing for the groovy macro). Thanks -Vincent
Ludovic
Sergiu Dumitriu a écrit :
Hi devs,
Should XWiki protect itself against CSRF? See http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF %29 and http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevent... for details.
In short: an attacker could use something like: <img src="http://xwikiserver/bin/save/Some/Document?content=Hacked"/
to alter the wiki using another user's account. Protection usually involves embedding tokens in submitted forms and URLs. The good news is that it can be done transparently using a LGPL tool from OWASP. The bad news is that it does not protect against attacks from the same wiki, but only for Cross-Site attacks. And it also breaks direct manipulation using URLs (as an expert user, I do enter URLs directly instead of clicking through the interface, and I won't like it if I couldn't do it anymore).
So, WDYT?
participants (3)
-
Ludovic Dubost -
Sergiu Dumitriu -
Vincent Massol