On Apr 18, 2009, at 4:48 AM, Jacques Le Roux wrote:

At 
https://demo904.ofbiz.org/catalog/control/setUserPreference?userPrefGroupTypeId=GLOBAL_PREFERENCES&userPrefTypeId=COMPACT_HEADER&userPrefValue=Y

I get see this message.
Found URL parameter [userPrefTypeId] passed to secure (https) request-map with uri [setUserPreference] with an event that calls service [setUserPreference]; this is not allowed for security reasons! The data should be encrypted by making it part of the request body (a form field) instead of the request URL.

That particular is already fixed, and just hasn't updated yet.

I thought we gave up with this message (or just have it only in log?).

If a change had been made you would have seen it in the commit log... and hopefully explicitly called out as such (it is unfortunate that we get so many poorly written commit logs that don't even try to describe the changes made...).

But I was just thinking about that yesterday and I think that we should contunue to have it in trunk and not in 9.04. So we will be able to catch them (before having a tool to list them all, I hope to work on that next week) without disturbing 9.04 users

The main point of that error is to protect against XSRF attacks. Without that error and not allowing the condition it checks there is nothing keeping spoofed parameters from piggy-backing on a cloned encrypted request (or caught and modified through a man-in-the-middle sort of attack).

Personally I'd rather see these fixed in both the release branch and in the trunk, but if we get too many complaints about it in the release branch then I'm totally fine disabling that constraint temporarily.

-David

Reply via email to