Security-Fault: change user-pw

[mike2009]

Hello,

is it a normal function that:

changing password,
after submitting the form, old-pw and new-pw is sent in url (via get-request?!?!)

Can anybody confirm this security fault ??

Mike

[crmsiva]

Could you make your question bit clear?

[mike2009]

Yes, sorry,
I paste the text in the form and missed 50% ...

I'm logged in as a normal user.
I enter My Account -> change password.

The form appears.
I enter old pw, twice new pw and press submit.

Now the popup-form disappears and the following "URL" in the browser (and was also tracked by the history):

://DOMAIN_FOR_SUGAR/index.php?old_password=testtest&is_admin=1&new_pas sword=abbaabba&confirm_new_password=abbaabba&butto n=++Speichern++

This can be reproduced: 29 attempts, 3 times this result

Used Browser: Firefox actual release, no extension/addons installed

Not confirmed with IE 7.x

I never see that, but I think, in case of security this should not happen.

I want to know:
can anyone else confirm this "fault" or maybe it is some system-specific reason.

Using:
DualPen Win XP Pro act. Patchlevel, default Win Firewall, Normnan Virus-Suite.
Nothing special in background active.

Mike

[crmsiva]

Which version of sugar you are using? Did the change password feature customized in the past?

[mvngti]

Mike the simple fact is that the new password must be sent to the server in cleartext for the server to save it.
So whether it is sent using GET (in the URL) or POST it IS going to go over the wire in cleartext - there is just no other way.

That is why the "wire" itself should be secured so at the very least you should be using https for accessing sugar (over a public network).

This "fault" seems unavoidable to me.

M

[mike2009]

I'm using Version 5.2.0c (Build 5505) , no customization at all.

If this "feature" is the default was to post pw to database, why it happens not during _every_ attempt to change password ?

[dtokeefe]

There is no way to avoid posting the password to the webserver? How else would the webserver know it has been changed? As noted, you should therefore use SugarCRM in the context of HTTPS, which encrypts the communication between the browser and the webserver.

Your test of the GET / POST seemed flawed somehow, but really it is irrelevant anyway. Web systems send data to web servers. This is the nature of the internet, not a design flaw in SugarCRM.

[mike2009]

Of course, I understand the technical flow by sending data via web.
Naturally sugar is used via https.

The question was:
why this method of sending data occured not _everytime_ ?

In more than 50% of all cases the data is sent coded in url.

So I think, if sth. is coded, it works in coded-behaviour. The reason for changing behaviour can imho be one these:
a) s.th. in my environment is the cause
b) s.th. in sugar works not _as it should_.

Am I wrong ?

[dtokeefe]

The popup passes values back to a hidden form on the User DetailView and causes it to POST.

<form action="index.php" method="post" name="DetailView" id="form">
<input type="hidden" name="module" value="Users">
<input type="hidden" name="record" value="24fnca6b-9c4c-456i-5018-424b38710429">
<input type="hidden" name="isDuplicate" value=false>
<input type="hidden" name="action">
<input type="hidden" name="user_name" value="davidokeefe">
<input type="hidden" name="password_change">
<input type="hidden" name="old_password">
<input type="hidden" name="new_password">
<input type="hidden" name="return_module">
<input type="hidden" name="return_action">
<input type="hidden" name="return_id">

To follow the flow, you should interrupt it before it goes on to the return action.

[dtokeefe]

You could put, for example:

print_r($_REQUEST);
die;

somewhere in /modules/Users/Save.php to stop the execution. That would show what was posted and how.