Re: Cross-Site Request Forging (XSRF)

Posted by David E Jones-3 on Mar 08, 2009; 7:28pm
URL: http://ofbiz.116.s1.nabble.com/Cross-Site-Request-Forging-XSRF-tp197647p197648.html


On Mar 5, 2009, at 2:55 PM, David E Jones wrote:

> One thing that we could do to help with this problem, at least for  
> secure pages, is to tighten things up a bit. I'm thinking of 2 things:
>
> 1. if a request has https=true then we will not accept http requests  
> AT ALL, we will just return an error message (currently if it is a  
> form submission we just accept it)
>
> 2. if a request has https=true we will ONLY pass encrypted data (ie  
> body parameters, not URL parameters) to the service it calls; events  
> may need to be changed to better support this since they have direct  
> access to the request object, but for services we can easily filter  
> this out; that means URL parameters will be ignored in secure  
> requests that call services
>
> These things, and perhaps others, would help this problem a lot for  
> secure requests. For non-secure requests... well they aren't very  
> secure anyway! ... and they would continue to be more vulnerable to  
> XSRF attacks too.

In SVN rev 751501 I have implemented both of these.

For #2 there could be some forms that this breaks. I couldn't find  
any, but if a form sent via POST has URL parameters as well as the  
form/body parameters and a URL parameter is the same name as an IN  
parameter for the service being called it will result in an error.  
Basically with forms all parameters should go in form/body fields  
(which is our common practice, and which is more secure anyway since  
URL parameters are not encrypted).

-David