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
