Hi Samuel, Mathieu,
Le 21/10/2019 à 09:43, Samuel a écrit :
If I'm correct this is related to XSS attack [1] but this kind of attack is not limited to url parameters. An attacker can do the same thing with a
POST request (I mean parameter in body instead of url)
You are right, they just are harder. You need to use CSRF, or an existing stored XSS[1]. We don't handle CSRF yet, with OFBIZ-10427 we are working on
it. Anyway, even if we don't have any known at the moment, we can't never guarantee a stored XSS . So yes it's theoretically possible in 2 more
difficult ways than a simple GET. I guess that's why this was implemented in 1st place. Again, because you can do a lot more with services than with
events:
"A service with the type Java is much like an event where it is a static
method, however with the Services Framework we do not limit to web based
applications."[2]
Anyway what would you suggest? You know you can set
service.http.parameters.require.encrypted=N, is that not enough?
I am not convinced by the explanation or by the non-solution of keeping
an option with confusing security impacts.
IMO for the sake of both simplicity and sanity we should just nuke the
option and accept URI parameters unconditionally.
Agree with Mathieu, an option to desactivate security check with no clear
impact seems to me a bad idea.
So as Mathieu said to make thing simpler I'd like to remove this function. In my opinion security is mainly about good practices, if we want to
increase security maybe we should provide documentation.
Samuel
It was just that attacking with GET is easier than with POST. A lot has already been done with OFBIZ-2330 and related. We did not have much returns
since a while. So I have no problem removing this method... and closing OFBIZ-2330, maybe after "fixing" OFBIZ-9804...
[1]
https://security.stackexchange.com/questions/175679/how-to-exploit-xss-in-post-request-when-parameter-is-going-in-body
[2] https://cwiki.apache.org/confluence/display/OFBIZ/Service+Engine+Guide
Jacques
