Samuel,
This was initiated by David (the founder of the project). It was not much discussed at the time. I guess he had a possible attack scenario in head, or
faced one.
As he commented in ServiceEventHandler::checkSecureParameter
// special case for security: if this is a request-map defined as secure in
controller.xml then only accept body parameters coming in, ie don't allow the
insecure URL parameters
// NOTTODO: may want to allow parameters that map to entity PK fields to be
in the URL, but that might be a big security hole since there are certain
security sensitive entities that are made of only PK fields, or that only need
PK fields to function (like UserLoginSecurityGroup)
// NOTTODO: we could allow URL parameters when it is not a POST (ie when
!request.getMethod().equalsIgnoreCase("POST")), but that would open a security
hole where sensitive parameters can be passed on the URL in a GET/etc and bypass this
security constraint
This article is related:
https://www.owasp.org/index.php/Information_exposure_through_query_strings_in_url
Here is an use case
https://www.fullcontact.com/blog/never-put-secrets-urls-query-parameters/
We could consider a CSRF attack. An attacker could create an email similar to the one we use to allow users to change passwords. In the fake email an
underneath URL could be
.../partymgr/control/ProfileAddUserLoginToSecurityGroup?userLoginId=ExistingEcommerceUser&partyId=ExistingEcommerceUser&AddUserLoginSecurityGroup=FULLADMIN
I let you imagine more :)
Jacques
Le 18/10/2019 à 11:28, Samuel a écrit :
Hi Jacques,
thanks for your detail and quick answer !
I still can't see the point with this check :s What kind of attack this check is protecting us ? could you describe an attack scenario where this
check is a good protection ?
My use case is to be able to access url parameters in an event service, I see that I can bypass the check with
`service.http.parameters.require.encrypted` property but still I really want to understand the point with this check ;)
Samuel
On 18/10/2019 10:48, Jacques Le Roux wrote:
Hi Samuel,
It started with http://svn.apache.org/viewvc?view=revision&revision=764286
Then I did http://svn.apache.org/viewvc?view=revision&revision=767688
Then I created OFBIZ-2330 after OFBIZ-2332, OFBIZ-2260, OFBIZ-2256
About removing, there are still few cases popping up. What is your case? Is it
relevant?
You are not the 1st one to question the security aspect, I commented that here:
https://s.apache.org/4z2bt
Thanks
Jacques
Le 18/10/2019 à 10:08, Samuel a écrit :
Hi,
recently I run against this check method which throw me an error to prevent me accessing url parameters from a service. Error message mentions a
security reason to forbid accessing url parameters but I definitely don't get this, so could you explain to me the "security" reason ? or could we
simply remove this check ?
Samuel
PS: I've also checked mentionned jira issue https://issues.apache.org/jira/browse/OFBIZ-2330, but this didn't help me understanding the "security"
reason
