Unable to change VisualTheme (security)

[Bruno Busco]

Hi,
in the latest trunk (rev. 752277) I got this error whenever I try to
change the VisualTheme in the backoffice:

The Following Errors Occurred:
Error calling event: org.ofbiz.webapp.event.EventHandlerException:
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!

-Bruno

[Adrian Crum]

I encountered that error too.

-Adrian

Bruno Busco wrote:

> Hi,
> in the latest trunk (rev. 752277) I got this error whenever I try to
> change the VisualTheme in the backoffice:
>
> The Following Errors Occurred:
> Error calling event: org.ofbiz.webapp.event.EventHandlerException:
> 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!
>
> -Bruno
>

[David E Jones-3]

This is one of the new security constraints that we were discussing  
over the last week.

All data going into secure requests should be in the body so it is  
actually secure, and NOT in the URL where it is not encrypted. This is  
a good general practice, and now we're playing with enforcing it as a  
security policy. I'd like to stick to this, and most so far have  
agreed this and a couple of others are good measures to avoid problems  
with various web-based attach vectors (including XSRF types of things).

Basically just have a form in your HTML and submit it instead of  
simply creating an anchored URL.

-David


On Mar 10, 2009, at 4:19 PM, Bruno Busco wrote:

> Hi,
> in the latest trunk (rev. 752277) I got this error whenever I try to
> change the VisualTheme in the backoffice:
>
> The Following Errors Occurred:
> Error calling event: org.ofbiz.webapp.event.EventHandlerException:
> 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!
>
> -Bruno

[David E Jones-3]

I did write some message and sent them to this list, one to propose  
these changes and another to communicate that they were in place... :)

Of course, now that people are seeing the downside to security, maybe  
opinions won't be so in favor of it? ;)

-David


On Mar 10, 2009, at 4:28 PM, Adrian Crum wrote:

> I encountered that error too.
>
> -Adrian
>
> Bruno Busco wrote:
>> Hi,
>> in the latest trunk (rev. 752277) I got this error whenever I try to
>> change the VisualTheme in the backoffice:
>> The Following Errors Occurred:
>> Error calling event: org.ofbiz.webapp.event.EventHandlerException:
>> 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!
>> -Bruno

[Adrian Crum]

I don't have a problem with it. I wasn't sure what to do about it. Your
other reply was helpful.

-Adrian

David E Jones wrote:

>
> I did write some message and sent them to this list, one to propose
> these changes and another to communicate that they were in place... :)
>
> Of course, now that people are seeing the downside to security, maybe
> opinions won't be so in favor of it? ;)
>
> -David
>
>
> On Mar 10, 2009, at 4:28 PM, Adrian Crum wrote:
>
>> I encountered that error too.
>>
>> -Adrian
>>
>> Bruno Busco wrote:
>>> Hi,
>>> in the latest trunk (rev. 752277) I got this error whenever I try to
>>> change the VisualTheme in the backoffice:
>>> The Following Errors Occurred:
>>> Error calling event: org.ofbiz.webapp.event.EventHandlerException:
>>> 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!
>>> -Bruno
>
>

[Bruno Busco]

Yes, I need to better dig into it but I supposed to be related to the
recent OFBiz strongest security constraint.
The strange thing (not strictly related to the security but to how
VisualThemes are set) is that even id this security issue is already
deployed to the demo server, there should be some way to change the
Visual Theme.
Until few minutes ago the backoffice was not working with admin/ofbiz
because the multiflex theme was selected (that is not supposed to be
used in the backoffice).
I logged in as demoadmin/ofbiz and found the bluelight theme in place
for this login.
Finally I logged in as flexadmin/ofbiz and manually deleted the
UserPreferences record that had admin stuck on multiflex.
Doing this now the demo is working again but...how people was able to
change the theme?

I tried to use party/visits and webtools/logs in order to discover the
"hack" but no way.
I would be interesting to know how to track the user activity that
took to this. How to?

-Bruno

2009/3/10 David E Jones <[hidden email]>:

>
> I did write some message and sent them to this list, one to propose these
> changes and another to communicate that they were in place... :)
>
> Of course, now that people are seeing the downside to security, maybe
> opinions won't be so in favor of it? ;)
>
> -David
>
>
> On Mar 10, 2009, at 4:28 PM, Adrian Crum wrote:
>
>> I encountered that error too.
>>
>> -Adrian
>>
>> Bruno Busco wrote:
>>>
>>> Hi,
>>> in the latest trunk (rev. 752277) I got this error whenever I try to
>>> change the VisualTheme in the backoffice:
>>> The Following Errors Occurred:
>>> Error calling event: org.ofbiz.webapp.event.EventHandlerException:
>>> 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!
>>> -Bruno
>
>

[Adam Heath-2]

David E Jones wrote:

> This is one of the new security constraints that we were discussing over
> the last week.
>
> All data going into secure requests should be in the body so it is
> actually secure, and NOT in the URL where it is not encrypted. This is a
> good general practice, and now we're playing with enforcing it as a
> security policy. I'd like to stick to this, and most so far have agreed
> this and a couple of others are good measures to avoid problems with
> various web-based attach vectors (including XSRF types of things).
>
> Basically just have a form in your HTML and submit it instead of simply
> creating an anchored URL.

Bruno is saying that existing pages in ofbiz have not been updated to
handle this new security constraint, namely the visual theme selector.

[Bruno Busco]

On https://www.ofbiz.it/catalog/control/login/main?USERNAME=admin&PASSWORD=ofbiz
the actual theme is bluelight so it seems to be possible to change the
theme, but...how?

2009/3/10 Bruno Busco <[hidden email]>:

> Yes, I need to better dig into it but I supposed to be related to the
> recent OFBiz strongest security constraint.
> The strange thing (not strictly related to the security but to how
> VisualThemes are set) is that even id this security issue is already
> deployed to the demo server, there should be some way to change the
> Visual Theme.
> Until few minutes ago the backoffice was not working with admin/ofbiz
> because the multiflex theme was selected (that is not supposed to be
> used in the backoffice).
> I logged in as demoadmin/ofbiz and found the bluelight theme in place
> for this login.
> Finally I logged in as flexadmin/ofbiz and manually deleted the
> UserPreferences record that had admin stuck on multiflex.
> Doing this now the demo is working again but...how people was able to
> change the theme?
>
> I tried to use party/visits and webtools/logs in order to discover the
> "hack" but no way.
> I would be interesting to know how to track the user activity that
> took to this. How to?
>
> -Bruno
>
> 2009/3/10 David E Jones <[hidden email]>:
>>
>> I did write some message and sent them to this list, one to propose these
>> changes and another to communicate that they were in place... :)
>>
>> Of course, now that people are seeing the downside to security, maybe
>> opinions won't be so in favor of it? ;)
>>
>> -David
>>
>>
>> On Mar 10, 2009, at 4:28 PM, Adrian Crum wrote:
>>
>>> I encountered that error too.
>>>
>>> -Adrian
>>>
>>> Bruno Busco wrote:
>>>>
>>>> Hi,
>>>> in the latest trunk (rev. 752277) I got this error whenever I try to
>>>> change the VisualTheme in the backoffice:
>>>> The Following Errors Occurred:
>>>> Error calling event: org.ofbiz.webapp.event.EventHandlerException:
>>>> 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!
>>>> -Bruno
>>
>>
>

[David E Jones-3]

You could try looking at the Visit and ServerHit records for the user  
to get an idea of what may have done this.

What caused this is a good question... the database is supposed to be  
cleaned out every day, and if it isn't working then something's up.  
One possibility is that the theme was changed through an insecure URL  
if there is one somewhere in some application, and that would work.

-David


On Mar 10, 2009, at 4:44 PM, Bruno Busco wrote:

> Yes, I need to better dig into it but I supposed to be related to the
> recent OFBiz strongest security constraint.
> The strange thing (not strictly related to the security but to how
> VisualThemes are set) is that even id this security issue is already
> deployed to the demo server, there should be some way to change the
> Visual Theme.
> Until few minutes ago the backoffice was not working with admin/ofbiz
> because the multiflex theme was selected (that is not supposed to be
> used in the backoffice).
> I logged in as demoadmin/ofbiz and found the bluelight theme in place
> for this login.
> Finally I logged in as flexadmin/ofbiz and manually deleted the
> UserPreferences record that had admin stuck on multiflex.
> Doing this now the demo is working again but...how people was able to
> change the theme?
>
> I tried to use party/visits and webtools/logs in order to discover the
> "hack" but no way.
> I would be interesting to know how to track the user activity that
> took to this. How to?
>
> -Bruno
>
> 2009/3/10 David E Jones <[hidden email]>:
>>
>> I did write some message and sent them to this list, one to propose  
>> these
>> changes and another to communicate that they were in place... :)
>>
>> Of course, now that people are seeing the downside to security, maybe
>> opinions won't be so in favor of it? ;)
>>
>> -David
>>
>>
>> On Mar 10, 2009, at 4:28 PM, Adrian Crum wrote:
>>
>>> I encountered that error too.
>>>
>>> -Adrian
>>>
>>> Bruno Busco wrote:
>>>>
>>>> Hi,
>>>> in the latest trunk (rev. 752277) I got this error whenever I try  
>>>> to
>>>> change the VisualTheme in the backoffice:
>>>> The Following Errors Occurred:
>>>> Error calling event: org.ofbiz.webapp.event.EventHandlerException:
>>>> 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!
>>>> -Bruno
>>
>>

[David E Jones-3]

Actually, I'm starting to wonder if we should revert it and relax that  
constraint. We have a lot of links that go to requests that call  
services and pass parameters and that would need to be updated. For  
sure they would be far more secure, but there is a bit of work to do  
(I'm realizing now that I've looked into it more and soaked up the  
implications a bit...). For example, most Delete/Remove/etc links are  
this way. Now, for sure they aren't very secure as-is, but there are  
quite a few to change (a form widget update can fix many of them  
perhaps, but that is complicated for multi forms as the natural way  
would be to do nested forms which are a nice fantasy but not supported  
in the real world ;) ).

Anyway, I'm working on it, but it's a bit of a mess I've created with  
this one...

-David


On Mar 10, 2009, at 4:43 PM, Adrian Crum wrote:

> I don't have a problem with it. I wasn't sure what to do about it.  
> Your other reply was helpful.
>
> -Adrian
>
> David E Jones wrote:
>> I did write some message and sent them to this list, one to propose  
>> these changes and another to communicate that they were in  
>> place... :)
>> Of course, now that people are seeing the downside to security,  
>> maybe opinions won't be so in favor of it? ;)
>> -David
>> On Mar 10, 2009, at 4:28 PM, Adrian Crum wrote:
>>> I encountered that error too.
>>>
>>> -Adrian
>>>
>>> Bruno Busco wrote:
>>>> Hi,
>>>> in the latest trunk (rev. 752277) I got this error whenever I try  
>>>> to
>>>> change the VisualTheme in the backoffice:
>>>> The Following Errors Occurred:
>>>> Error calling event: org.ofbiz.webapp.event.EventHandlerException:
>>>> 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!
>>>> -Bruno

[David E Jones-3]

In SVN rev 752399 I changed this to only log a warning and not blow up  
with an exception. After playing around more I think there are too  
many places that need cleanup/fixing before we can make enforcing this  
the default behavior.

So, until then...

To get there with the form widget I think we'll need to introduce a  
new field type, like a form-backed link that we can use instead of the  
hyperlink field type that we currently use to pass parameters in the  
URL.

-David


On Mar 10, 2009, at 11:38 PM, David E Jones wrote:

>
> Actually, I'm starting to wonder if we should revert it and relax  
> that constraint. We have a lot of links that go to requests that  
> call services and pass parameters and that would need to be updated.  
> For sure they would be far more secure, but there is a bit of work  
> to do (I'm realizing now that I've looked into it more and soaked up  
> the implications a bit...). For example, most Delete/Remove/etc  
> links are this way. Now, for sure they aren't very secure as-is, but  
> there are quite a few to change (a form widget update can fix many  
> of them perhaps, but that is complicated for multi forms as the  
> natural way would be to do nested forms which are a nice fantasy but  
> not supported in the real world ;) ).
>
> Anyway, I'm working on it, but it's a bit of a mess I've created  
> with this one...
>
> -David
>
>
> On Mar 10, 2009, at 4:43 PM, Adrian Crum wrote:
>
>> I don't have a problem with it. I wasn't sure what to do about it.  
>> Your other reply was helpful.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> I did write some message and sent them to this list, one to  
>>> propose these changes and another to communicate that they were in  
>>> place... :)
>>> Of course, now that people are seeing the downside to security,  
>>> maybe opinions won't be so in favor of it? ;)
>>> -David
>>> On Mar 10, 2009, at 4:28 PM, Adrian Crum wrote:
>>>> I encountered that error too.
>>>>
>>>> -Adrian
>>>>
>>>> Bruno Busco wrote:
>>>>> Hi,
>>>>> in the latest trunk (rev. 752277) I got this error whenever I  
>>>>> try to
>>>>> change the VisualTheme in the backoffice:
>>>>> The Following Errors Occurred:
>>>>> Error calling event: org.ofbiz.webapp.event.EventHandlerException:
>>>>> 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!
>>>>> -Bruno
>

[Bilgin Ibryam]

On Mar 11, 2009, at 9:43 AM, David E Jones wrote:

> So, until then...
>
> To get there with the form widget I think we'll need to introduce a  
> new field type, like a form-backed link that we can use instead of  
> the hyperlink field type that we currently use to pass parameters in  
> the URL.
>
> -David


Hi David,
I think this is good security rule and it would be good to have it in  
the framework.

Do you have any idea how to cope with "nested forms problem"

Also, there are links in the screens, which are used to invoke  
services. Should we replace these links with forms or add a new  
attribute to link element and render the link as a form with hidden  
fields containing all the request parameters ?

Bilgin

[David E Jones-3]

On Mar 11, 2009, at 4:53 AM, Bilgin Ibryam wrote:

>
> On Mar 11, 2009, at 9:43 AM, David E Jones wrote:
>
>> So, until then...
>>
>> To get there with the form widget I think we'll need to introduce a  
>> new field type, like a form-backed link that we can use instead of  
>> the hyperlink field type that we currently use to pass parameters  
>> in the URL.
>>
>> -David
>
>
> Hi David,
> I think this is good security rule and it would be good to have it  
> in the framework.
>
> Do you have any idea how to cope with "nested forms problem"

This isn't too hard, just takes a little work. You can always put  
forms with all hidden fields elsewhere in the page and then have a  
link submit them.

> Also, there are links in the screens, which are used to invoke  
> services. Should we replace these links with forms or add a new  
> attribute to link element and render the link as a form with hidden  
> fields containing all the request parameters ?

Yes, screens and other places will need this option too (a way to do  
mini-forms as an alternative to links for calling services). I'll be  
playing with these in the near future and figure out a good XML schema  
for it, probably a "formlink" or something with nested elements for  
the parameters to pass to it (which will all end up being hidden forms  
on the parameters).

Along with this I'm still thinking about doing unique keys for each  
form so that they are more protected, and to avoid duplicate  
submissions and such - those would initially only work by default for  
form widget forms that are handled by service type events.

-David

[Bruno Busco]

David,
I think I have found how it was possible to change the VisualTheme
even with the security issue we had on the demo at that time.
It also explains how an ecommerce theme was applied on the backoffice.
It should have be done using the ListPreferences form that I have now
fixed in rev. 754639.

-Bruno

2009/3/11 David E Jones <[hidden email]>:

>
> You could try looking at the Visit and ServerHit records for the user to get
> an idea of what may have done this.
>
> What caused this is a good question... the database is supposed to be
> cleaned out every day, and if it isn't working then something's up. One
> possibility is that the theme was changed through an insecure URL if there
> is one somewhere in some application, and that would work.
>
> -David
>
>
> On Mar 10, 2009, at 4:44 PM, Bruno Busco wrote:
>
>> Yes, I need to better dig into it but I supposed to be related to the
>> recent OFBiz strongest security constraint.
>> The strange thing (not strictly related to the security but to how
>> VisualThemes are set) is that even id this security issue is already
>> deployed to the demo server, there should be some way to change the
>> Visual Theme.
>> Until few minutes ago the backoffice was not working with admin/ofbiz
>> because the multiflex theme was selected (that is not supposed to be
>> used in the backoffice).
>> I logged in as demoadmin/ofbiz and found the bluelight theme in place
>> for this login.
>> Finally I logged in as flexadmin/ofbiz and manually deleted the
>> UserPreferences record that had admin stuck on multiflex.
>> Doing this now the demo is working again but...how people was able to
>> change the theme?
>>
>> I tried to use party/visits and webtools/logs in order to discover the
>> "hack" but no way.
>> I would be interesting to know how to track the user activity that
>> took to this. How to?
>>
>> -Bruno
>>
>> 2009/3/10 David E Jones <[hidden email]>:
>>>
>>> I did write some message and sent them to this list, one to propose these
>>> changes and another to communicate that they were in place... :)
>>>
>>> Of course, now that people are seeing the downside to security, maybe
>>> opinions won't be so in favor of it? ;)
>>>
>>> -David
>>>
>>>
>>> On Mar 10, 2009, at 4:28 PM, Adrian Crum wrote:
>>>
>>>> I encountered that error too.
>>>>
>>>> -Adrian
>>>>
>>>> Bruno Busco wrote:
>>>>>
>>>>> Hi,
>>>>> in the latest trunk (rev. 752277) I got this error whenever I try to
>>>>> change the VisualTheme in the backoffice:
>>>>> The Following Errors Occurred:
>>>>> Error calling event: org.ofbiz.webapp.event.EventHandlerException:
>>>>> 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!
>>>>> -Bruno
>>>
>>>
>
>

[David E Jones-3]

On Mar 11, 2009, at 10:52 AM, David E Jones wrote:

>
> On Mar 11, 2009, at 4:53 AM, Bilgin Ibryam wrote:
>
>>
>> On Mar 11, 2009, at 9:43 AM, David E Jones wrote:
>>
>>> So, until then...
>>>
>>> To get there with the form widget I think we'll need to introduce  
>>> a new field type, like a form-backed link that we can use instead  
>>> of the hyperlink field type that we currently use to pass  
>>> parameters in the URL.
>>>
>>> -David
>>
>>
>> Hi David,
>> I think this is good security rule and it would be good to have it  
>> in the framework.
>>
>> Do you have any idea how to cope with "nested forms problem"
>
> This isn't too hard, just takes a little work. You can always put  
> forms with all hidden fields elsewhere in the page and then have a  
> link submit them.
>
>> Also, there are links in the screens, which are used to invoke  
>> services. Should we replace these links with forms or add a new  
>> attribute to link element and render the link as a form with hidden  
>> fields containing all the request parameters ?
>
> Yes, screens and other places will need this option too (a way to do  
> mini-forms as an alternative to links for calling services). I'll be  
> playing with these in the near future and figure out a good XML  
> schema for it, probably a "formlink" or something with nested  
> elements for the parameters to pass to it (which will all end up  
> being hidden forms on the parameters).

Some of this is now implemented and in SVN, and used throughout the  
ProductForms.xml file.

This is implemented as an extension to the existing hyperlink and sub-
hyperlink elements. There is now an attribute called "link-type" and  
if it is set to "hidden-form" then it will create a hidden form and  
the link generated will just submit that form, causing the parameters  
to be encrypted in the body of the request instead of in plain text in  
the URL.

Of course, for them to be put into hidden form fields, they must be  
setup using the new "parameter" sub-element (under hyperlink or sub-
hyperlink). Anything left in the "target" attribute will remain in the  
form's URL (action), and be submitted unencrypted... so everything  
should be moved to parameter tags.

I haven't implemented this in the screen widget or in the menu or tree  
widgets yet either. Actually, after implementing it for the sub-
hyperlink element in the form widget I couldn't find any places where  
a request that calls a service was actually used, so it appears to not  
be needed there (that I can find yet). In other words, all of those  
links are for going to different places and not for submitting data to  
update in the database. Unless we run across other places that do this  
I'll probably table those for now.

-David

[Bilgin Ibryam]

>
>
> I haven't implemented this in the screen widget or in the menu or  
> tree widgets yet either. Actually, after implementing it for the sub-
> hyperlink element in the form widget I couldn't find any places  
> where a request that calls a service was actually used, so it  
> appears to not be needed there (that I can find yet). In other  
> words, all of those links are for going to different places and not  
> for submitting data to update in the database. Unless we run across  
> other places that do this I'll probably table those for now.
>
> -David
>

That's great, thanks David!


How to deal with menu item links invoking services?
These are few in invoice menu, used for setting the invoice statuses,  
and also in MyPortalMenus.xml - RemoveCommunicationEventRole,  
updateCommunicationEvent.

There might be more.

Bilgin

[David E Jones-3]

On Mar 16, 2009, at 3:03 AM, Bilgin Ibryam wrote:

>> I haven't implemented this in the screen widget or in the menu or  
>> tree widgets yet either. Actually, after implementing it for the  
>> sub-hyperlink element in the form widget I couldn't find any places  
>> where a request that calls a service was actually used, so it  
>> appears to not be needed there (that I can find yet). In other  
>> words, all of those links are for going to different places and not  
>> for submitting data to update in the database. Unless we run across  
>> other places that do this I'll probably table those for now.
>>
>> -David
>>
> How to deal with menu item links invoking services?
> These are few in invoice menu, used for setting the invoice  
> statuses, and also in MyPortalMenus.xml -  
> RemoveCommunicationEventRole, updateCommunicationEvent.

I have added to this in rev 755022. Please see my comments there.

On a side note: that particular menu bar is called a "Tab" bar, but  
really isn't since the links go to other places and do not stay within  
the tab set, and show a different pages causing the "tab" to  
highlight, etc.

Anyway, a bit more progress... now lots of help is needed to get this  
used throughout, and then we can turn on the more strict security to  
better protect things.

-David