We already know that the parameter is the issue. Having to change all the parameter i.e. refactoring code is always the answer. The question was more about the recommended way of handling this issue without exposing application to any specific vulnerability. I believe Mark T has answered this already.
Thanks, On Thu, 18 Oct 2018 at 14:09, Mark H. Wood <mw...@iupui.edu> wrote: > On Thu, Oct 18, 2018 at 11:55:24AM +0100, M. Manna wrote: > > Thanks a bunch Mark. > > > > "The correct fix is to ensure that the user agents are sending > > specification compliant requests." - Do you mean at browser level ? If > so, > > is there any specific browser/update we can use? We've checked a few > > browsers so far (Firefox, Edge, Chrome) and none of them seem to have > this > > option (or we might've missed it). > > [snip] > > > > > The URI we have for this problem has the following param (did work > with > > > > 8.5.28) > > > > > > > > defaultMessageType=true&locale=en_US&action=[key:label.edit] > > The browser did not actually *compose* that parameter, did it? > > If I had this problem, given only what I know from this thread, I > would suppose that the page which contained an href having such a > parameter is the source of the problem. Some link is improperly > encoded. > > I would say it is debatable whether browsers should be "correcting" > hrefs which are handed to them by some site. > > -- > Mark H. Wood > Lead Technology Analyst > > University Library > Indiana University - Purdue University Indianapolis > 755 W. Michigan Street > Indianapolis, IN 46202 > 317-274-0749 > www.ulib.iupui.edu >
