Hi,
On 20/10/2019 12:27, Mathieu Lirzin wrote:
Hello,
Samuel <samuel.trego...@nereide.fr> writes:
Moreover if you don't use a service event in your request map you can
access whatever url parameter you want, so I cannot see why service
event is so particular in this regards.
Indeed if the issue is about forbidding URI parameters because of
security reason, this check should be hardcoded in the RequestHandler
not by individual EventHandler implementations.
Otherwise this is just absurd because every administrator/integrator can
then implement an ad-hoc Java/Groovy event handler invoking a service
without being warned about a “known” security issue.
Jacques Le Roux <jacques.le.r...@les7arts.com> writes:
I agree that it's an overkill. I guess because services give you more
power so need to be more secure.
The same person that, like you, doubted about the reason of
checkSecureParameter() spoke also about the possibility to "inject
stuff using parameters"
Here is what he said (actually this was reported to me by a 3rd person
but I much trust them both)
"The other case I reported has more to do with people being able to
inject stuff using parameters. Because they are not always
escaped. In particular the case for the VIEW_INDEX parameter and
alike view_size, view_index often in combination with screen
widget but not only"
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)
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
[1]: https://en.wikipedia.org/wiki/Cross-site_scripting
