Important! There's no privacy??

Hey

I found out a big problem about Dolphin private messaging.

I track statistics with statcounter and there you can see weblinks of recent activity.

If I click on "http://www.mysite.com/compose.php?ID=654&messageID=9876" I can read the private message!!!

And if I change the ID's I can see all private messages of users!! And that's without being logged as admin - just as a normal user!

Please tell me that this can be fixed - that nobody can't see private messages just by visiting the url

thanks for help, I hope it'll bring some worries to all of you :shock

Quote · 4 Feb 2009

Strange that nobody noticed this before me. But it's very scarry brrr

Can you imagine that registered users notice this? Our sites can say bye bye then

please inform me if there'll be any reply

or if anyone knows how to set this in php

Quote · 4 Feb 2009

Ha - great.  I use Statcounter too - and kept it public which probably makes it even less secure.  Thanks for bringing this to our attention Kero, and reporting it Sammie.

-

Rob

Quote · 4 Feb 2009

Hello everybody!

Yes, this trouble exists in 6.1.4 - so if someone knows exact message for anotehr users id so he can read it in outbox.

You can apply this fix:

Find in message_outbox.php this string with query -

$message_sql= "SELECT m.`Text`, m.`Subject`, DATE_FORMAT( m.`Date`, '%Y-%m-%d' ) AS `Date`, p.Status FROM `Messages` AS m LEFT JOIN Profiles AS p ON m.Recipient = p.ID WHERE m.`ID` = '$messageID'";

and replace it with this one:

$message_sql= "SELECT m.`Text`, m.`Subject`, DATE_FORMAT( m.`Date`, '%Y-%m-%d' ) AS `Date`, p.Status FROM `Messages` AS m LEFT JOIN Profiles AS p ON m.Recipient = p.ID WHERE m.`ID` = '$messageID' AND `Recipient` = '$senderID'";

It works (checked at boonex.us).

Regard

Quote · 5 Feb 2009

hm... I changed the code but I can still see the messages

so it must be something else... Cry

Quote · 5 Feb 2009

Maybe you forgot to upload changed file back to server? or you check this at own profile ?

seems it must help

Quote · 5 Feb 2009

I changed it directy on server file, delete cache,... still the same

Again: I can read this messages while I'm logged in as a normal member.

we have to find a solution

Quote · 5 Feb 2009

Hello kero!

Provide me then via Unity mail your FTP & CPanel access and i'll check it in your side.

Regard

Quote · 6 Feb 2009

Hello kero!

Provide me then via Unity mail your FTP & CPanel access and i'll check it in your side.

Regard

Leonid, thanks for your intention to help but I really can't provide you passwords because I've got too many other important data on server.

sammie, eventhough you don't see the sender and receipient there are many personal data in these messages (like mobile phone numbers, emails, adresses,...)

c'mon somebody has to know how to fix this; it's a basic secure issue! Strange that more people aren't conserd about thi

Quote · 6 Feb 2009

Wow. That is a terrible privacy breach, with the message_outbox.php especially. Emergency patch?

Quote · 7 Feb 2009

Ok peeps. The message_outbox.php security fix:

1. Open up message_outbox.php and find this line:

$message_sql= "SELECT m.`Text`, m.`Subject`, DATE_FORMAT( m.`Date`, '%Y-%m-%d' ) ..... [a bunch more gubbledeegook]

In my file for v6.1.4 it's line 76. Change it to:

$message_sql= "SELECT m.`Text`, m.`Subject`, `Sender`, DATE_FORMAT( m.`Date`, '%Y-%m-%d' ) ....

(you're basically adding `Sender` right before DATE_FORMAT )

2. Two lines down, after    $message_arr= db_arr($message_sql); add this:

check_login($message_arr['Sender'], $_COOKIE['memberPassword']);

What that does is it grabs the ID of the person who sent the message originally, then the password from the cookie stored on your computer that you normally would have after logging in, and feeds that into the check_login() function. If all is good then the ID of the sender should match the user ID stored in the cookie on your machine and check_login should return 'true'. If not though, check_login() will spit out a login form and a notice that you don't have access to read the message. Voila.

Quote · 7 Feb 2009

hey earpick

Thank you for your efford. In theory your solution maybe works but I can still see the messages. I deleted all cookies, cache,... but still the same.

Can somebody else tell me if this fixes work on your pages?

try smth like "http://www.yoursite.com/compose.php?ID=2&messageID=2"

Quote · 8 Feb 2009

Yeah, my fix is for the big security hole in messages_outbox.php. I'll look into compose.php right now, but so far I haven't been able to replicate the problem on my Dolphin install.

UPDATE: There is no code in my compose.php that would pull up the contents of a message. What version of Dolphin do you have? Perhaps it's an older one and that bug has eliminated there?

Quote · 8 Feb 2009

Oh brother, how many more holes are there? Just found another one.

Try this. http://yoursite.com/messages_inbox.php?action=delete&message=10

Where it says message type in the ID of any message you want. And guess what - you can delete any message regardless or whether it was written by you or not. Wonderful!

Quote · 8 Feb 2009

I'm using 6.1.4

OMG - you are right with deleting messages

please find some time to fix this bugggs :grateful

Quote · 9 Feb 2009

I'm using 6.1.4

OMG - you are right with deleting messages

please find some time to fix this bugggs :grateful

You bet I will.

And I'm using 6.1.4 as well, and once again, cannot view messages through compose.php. There is simply nothing in compose.php that will look up based on 'messageID' in the URL. That is I believe later used to show the sender of the original message which message exactly it is you're replying to. Otherwise, there is nothing in compose.php that pulls up the text of the original message.

The only thing I can think of is that you, perhaps, upgraded from earlier versions of Dolphin as time went on, and did not overwrite compose.php. Get the latest .zip of Dolphin off BaBoonEx, back up your compose.php and upload the newest version.

Quote · 9 Feb 2009

jeaaah, I found out why this was happening!


Some weeks ago I made a customisation of compose.php by this instructions: http://www.boonex.com/unity/forums/?action=goto&topic_id=private-message-on-reply

This changes were working OK, because it's a great fix that you can see the message you're replying to.

Now I removed this from compose.php and I can't see messages of users anymore.

Obviously the problem is in compose.php and not in messages_outbox.php

So earpick, now you can just figure it out how to fix this in compose.php.  Maybe we can use similar code that you posted for messages_outbox? Something related to IP's... ?  Because I would really like to use that fix about showing received message (otherwise you have to click back in browser to see the text)

Quote · 10 Feb 2009

earpick r u here?

Quote · 12 Feb 2009

Indeed a great fix but a faulty one, isn't it.

Try finding this line:

$message_sql= "SELECT `Text`, `Subject`, `Date` FROM `Messages` WHERE `ID` = '$messageID'";

and changing it to this:

$sender = (int)$_COOKIE['memberID'];

$message_sql= "SELECT `Text`, `Subject`, `Date` FROM `Messages` WHERE `ID` = '$messageID', `Sender` = '{$sender}'";

Haven't tested it but should work.

Quote · 13 Feb 2009

hja... I did this change. It works partially

If I enter that URL (posted in first post) I get the "Database query error" - so no one can see the message

But now there's new problem... you can't reply to message - you also get "Database query error" here

Quote · 16 Feb 2009

Is there  a fix to stop messages being deleted yet?

Quote · 16 Feb 2009

To fix the hole that allows users to delete messages that are not their own...

 

Open messages_inbox.php

then

 

REPLACE:

 

if( $_GET['action'] == 'delete' )
{
 $mes_id = (int)$_GET['message'];
 $delete_query = "DELETE FROM `Messages` WHERE `ID` = '$mes_id'";
 if(db_res($delete_query))
 {
  $_page_cont[$_ni]['page_main_code'] = DesignBoxContent( '', _t( '_Message successfully deleted' ), $oTemplConfig -> PageMessagesInboxMessageDeleted_db_num );
 }
}

elseif($_GET['message'] != 0)

 

 

WITH:

 

if( $_GET['action'] == 'delete' )
{
 $mes_id = (int)$_GET['message'];
  $memberID = (int)$_COOKIE['memberID'];
 $delete_query = "DELETE FROM `Messages` WHERE `ID` = '$mes_id' and `Recipient`=$memberID";
 $sqlRes = db_res( $delete_query );
  $delete_query_check=mysql_affected_rows();
 
 if($delete_query_check!=0)
 {
  $_page_cont[$_ni]['page_main_code'] = DesignBoxContent( '', _t( '_Message successfully deleted' ), $oTemplConfig -> PageMessagesInboxMessageDeleted_db_num );
 }
 else
 {
  $_page_cont[$_ni]['page_main_code'] = DesignBoxContent( '','Error Deleting Message', $oTemplConfig -> PageMessagesInboxMessageDeleted_db_num );
  }
}

elseif($_GET['message'] != 0)

 

 

I hope that this helps!

Quote · 16 Feb 2009

Does this work? Has anyone tried it?

--

To fix the hole that allows users to delete messages that are not their own...

Open messages_inbox.php

then

REPLACE:

if( $_GET['action'] == 'delete' )
{
$mes_id = (int)$_GET['message'];
$delete_query = "DELETE FROM `Messages` WHERE `ID` = '$mes_id'";
if(db_res($delete_query))
{
$_page_cont[$_ni]['page_main_code'] = DesignBoxContent( '', _t( '_Message successfully deleted' ), $oTemplConfig -> PageMessagesInboxMessageDeleted_db_num );
}
}

elseif($_GET['message'] != 0)

WITH:

if( $_GET['action'] == 'delete' )
{
$mes_id = (int)$_GET['message'];
$memberID = (int)$_COOKIE['memberID'];
$delete_query = "DELETE FROM `Messages` WHERE `ID` = '$mes_id' and `Recipient`=$memberID";
$sqlRes = db_res( $delete_query );
$delete_query_check=mysql_affected_rows();

if($delete_query_check!=0)
{
$_page_cont[$_ni]['page_main_code'] = DesignBoxContent( '', _t( '_Message successfully deleted' ), $oTemplConfig -> PageMessagesInboxMessageDeleted_db_num );
}
else
{
$_page_cont[$_ni]['page_main_code'] = DesignBoxContent( '','Error Deleting Message', $oTemplConfig -> PageMessagesInboxMessageDeleted_db_num );
}
}

elseif($_GET['message'] != 0)

I hope that this helps!

Quote · 17 Feb 2009

hja... I did this change. It works partially

If I enter that URL (posted in first post) I get the "Database query error" - so no one can see the message

But now there's new problem... you can't reply to message - you also get "Database query error" here

Ok, this is weird.. I know I've replied to this topic already but here goes..

@kero - try removing the squiggly brackets from the

$message_sql= "SELECT `Text`, `Subject`, `Date` FROM `Messages` WHERE `ID` = '$messageID', `Sender` = '{$sender}'"; so it's just $sender at the end there. Should work now.

@dolphintester - looks good except I'm not sure why you're looking up the recepient column in the SQL query and not the sender. Also, both of your fix for message_inbox, Leonid's and my suggestion for compose.php are fairly loose security measures since neither one checks if the user supplied in the cookie exists - it is quite trivial to forge up a cookie with a desired user ID and the browser will happily eat it up and instruct PHP to pull the mail of the user with ID of memberID cookie value. We need to first run both the user and pass from the cookie through the check_login() function to make sure they're legit.

I hate how Orca won't double space the lines when I hit enter twice. Ugh!

Quote · 17 Feb 2009

Hi everyone, these are worrying glitches. Thanks to everyone who is offering  a solution. I will have to keep an eyee on this thread to see what comes up. Hope Boonex comes up with a patch though.

Quote · 18 Feb 2009

Hi everyone, these are worrying glitches. Thanks to everyone who is offering  a solution. I will have to keep an eyee on this thread to see what comes up. Hope Boonex comes up with a patch though.

Yeah, right after Dolphin 7... That is right after pigs catapult themselves into space and smoking from a pipe will be groovy again. Though that might actually happen, so that's a bad comparison.

Quote · 18 Feb 2009

Yeah, right after Dolphin 7... That is right after pigs catapult themselves into space and smoking from a pipe will be groovy again. Though that might actually happen, so that's a bad comparison.

Yeah, well, that's me: the ultimate optimist. :) Seriously though, I think Dolphin is great. If you've never tried anything else I can see how it might look difficult though.

Quote · 18 Feb 2009

Are these security fixes necessary on sites that don't use Statcounter?  Which of these fixes is recommended?

-

Rob

Quote · 19 Feb 2009

Rob, it's not related to Statcounter. Statcoutner just helped me find out this problem.

If someone knows about this security issues on your site, he can read or/and delete all site's message

Quote · 23 Feb 2009

.

Whenever the final "ultimate patch" becomes available in order to correct this massive security issue, I sincerly hope that it will have nothing to do with user I.P. checking .... because here in Germany (perhaps many other Countries too) most internet users have revolving I.Ps and not fixed I.P. numbers. Sure, servers and TLDs have fixed IPs, but not the internet account holders. There can be as many different I.P. numbers as 10 or 12 within one small specific region which are assigned to several dozen, and perhaps even hundreds of different users. I don't know exactly how that works or why, but I do know that that is the case for most DSL account holders here. My stats reflect this too. When I check the stats on my site, I end up with double sets of numbers ... those from dedicated IPs, and those from everyone else. The stats from everyone else are about 4 to 8 times higher than the stats from the dedicated IPs (depending on the amount of traffic for that particular month).

.

.

Greetings from Germany

Quote · 25 Feb 2009

BUMP

Official Final fix from Boonex created yet??

Quote · 6 Mar 2009
 
 
Below is the legacy version of the Boonex site, maintained for Dolphin.Pro 7.x support.
The new Dolphin solution is powered by UNA Community Management System.