restrict_senders caching issue
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
restrict_senders caching issue
by Bryan Loniewski
::
Rate this Message:
We've discovered a slight problem with the restrict_senders plugin
involving instances where a spammer can get around the 'todays_email_count' an administrator has set by logging in multiple times (via different computers or different browsers or both). As far as I can tell this is specific to environments (like ours) that have multiple webmail machines. The issue comes down to the way user preferences are get (and set) and the caching that takes place. I can remedy the issue by explicitly doing a call to the backend (in our case mysql), something like: // $emailCount = getPref($data_dir, $username, 'todays_email_count', 0); $dbh = DB::connect($prefs_dsn, true); $query = sprintf("SELECT prefval FROM userprefs WHERE prefkey='todays_email_count' AND user = '$username'"); $res = $dbh->query($query); while ($row = $res->fetchRow(DB_FETCHMODE_ASSOC)) { $emailCount = $row['prefval']; } in order to retrieve the "real" emailCount and not the cached one. Has anyone discovered this issue before (I realize this is a fairly new plugin)? Is there a more (there must be?) intelligent way of remedying the issue? There may be other variables specific to this plugin and perhaps others that are "count" sensitive and would falter if a user (spammer) has multiple webmail instances going... PS: This plugin as well as many others we use are very helpful and very much appreciated by us and our users. __________________________ Bryan Loniewski Rutgers University CSS - System Administrator ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ----- squirrelmail-plugins mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-plugins@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins |
|
|
Re: restrict_senders caching issue
by Paul Lesniewski
::
Rate this Message:
On Mon, Jun 16, 2008 at 11:16 AM, Bryan Loniewski
<brylon@...> wrote: > We've discovered a slight problem with the restrict_senders plugin > involving instances where a spammer can get around the > 'todays_email_count' an administrator has set by logging in multiple > times (via different computers or different browsers or both). *at the same time*? > As far > as I can tell this is specific to environments (like ours) that have > multiple webmail machines. The issue comes down to the way user > preferences are get (and set) and the caching that takes place. I don't think it's specific to your setup - I can reproduce it if I log in on a local test server under two different browsers at the same time before I start sending messages. Then I get the full $restrictNumberOfEmailsPerDay number of emails in BOTH browsers. This is caused by the fact that SM uses a cache of the user prefs in the PHP session. > I can > remedy the issue by explicitly doing a call to the backend (in our > case mysql), something like: > > // $emailCount = getPref($data_dir, $username, 'todays_email_count', 0); > $dbh = DB::connect($prefs_dsn, true); > $query = sprintf("SELECT prefval FROM userprefs WHERE > prefkey='todays_email_count' AND user = '$username'"); > $res = $dbh->query($query); > while ($row = $res->fetchRow(DB_FETCHMODE_ASSOC)) { > $emailCount = $row['prefval']; > } > > in order to retrieve the "real" emailCount and not the cached one. > > Has anyone discovered this issue before (I realize this is a fairly > new plugin)? Never heard of it. Thanks for finding it! 2003 isn't that "new". > Is there a more (there must be?) intelligent way of > remedying the issue? Not really, except, of course, to abstract the code more - but the solution ends up being the same - the SM prefs cache has to be destroyed and reloaded. Because this code is run in a high-impact part of SM, I'm hesitant to do that, but I don't think there is any other solution. So what I'll do is make it configurable and give you the choice. > There may be other variables specific to this > plugin and perhaps others that are "count" sensitive and would falter > if a user (spammer) has multiple webmail instances going... I think only $restrictSubsequentMassEmails is relevant here, and I think it'd be less likely to be a target because if a spammer is hitting up against it already,. they'd have to have at least tens of connections open at once to get the speed they want out of it (without still having to wait). I will implement the needed solution, however, such that it fixes any possible exploit here, too. > PS: This plugin as well as many others we use are very helpful and > very much appreciated by us and our users. Great to hear. I will send a copy of the proposed fix to you offlist. Anyone else feel free to ask for a copy offlist. - Paul ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ----- squirrelmail-plugins mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-plugins@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins |
|
|
Re: restrict_senders caching issue
by Paul Lesniewski
::
Rate this Message:
On Mon, Jun 16, 2008 at 12:50 PM, Paul Lesniewski <paul@...> wrote:
> On Mon, Jun 16, 2008 at 11:16 AM, Bryan Loniewski > <brylon@...> wrote: >> We've discovered a slight problem with the restrict_senders plugin >> involving instances where a spammer can get around the >> 'todays_email_count' an administrator has set by logging in multiple >> times (via different computers or different browsers or both). > > *at the same time*? > >> As far >> as I can tell this is specific to environments (like ours) that have >> multiple webmail machines. The issue comes down to the way user >> preferences are get (and set) and the caching that takes place. > > I don't think it's specific to your setup - I can reproduce it if I > log in on a local test server under two different browsers at the same > time before I start sending messages. Then I get the full > $restrictNumberOfEmailsPerDay number of emails in BOTH browsers. > > This is caused by the fact that SM uses a cache of the user prefs in > the PHP session. > >> I can >> remedy the issue by explicitly doing a call to the backend (in our >> case mysql), something like: >> >> // $emailCount = getPref($data_dir, $username, 'todays_email_count', 0); >> $dbh = DB::connect($prefs_dsn, true); >> $query = sprintf("SELECT prefval FROM userprefs WHERE >> prefkey='todays_email_count' AND user = '$username'"); >> $res = $dbh->query($query); >> while ($row = $res->fetchRow(DB_FETCHMODE_ASSOC)) { >> $emailCount = $row['prefval']; >> } >> >> in order to retrieve the "real" emailCount and not the cached one. >> >> Has anyone discovered this issue before (I realize this is a fairly >> new plugin)? > > Never heard of it. Thanks for finding it! 2003 isn't that "new". > >> Is there a more (there must be?) intelligent way of >> remedying the issue? > > Not really, except, of course, to abstract the code more - but the > solution ends up being the same - the SM prefs cache has to be > destroyed and reloaded. Because this code is run in a high-impact > part of SM, I'm hesitant to do that, but I don't think there is any > other solution. So what I'll do is make it configurable and give you > the choice. > >> There may be other variables specific to this >> plugin and perhaps others that are "count" sensitive and would falter >> if a user (spammer) has multiple webmail instances going... > > I think only $restrictSubsequentMassEmails is relevant here, and I > think it'd be less likely to be a target because if a spammer is > hitting up against it already,. they'd have to have at least tens of > connections open at once to get the speed they want out of it (without > still having to wait). I will implement the needed solution, however, > such that it fixes any possible exploit here, too. On a related note, a spammer could use the Reset User Preferences plugin to evade these "counter" type settings by simply resetting their user preferences once they hit the limit. The new version I am working on will have a fix for this as well. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ----- squirrelmail-plugins mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-plugins@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins |
|
|
|
|
|
Re: restrict_senders caching issue
by Paul Lesniewski
::
Rate this Message:
On Mon, Jun 23, 2008 at 10:22 AM, Bryan Loniewski
<brylon@...> wrote: > On Mon, Jun 16, 2008 at 12:50 PM, Paul Lesniewski <paul@...> wrote: >>> On Mon, Jun 16, 2008 at 11:16 AM, Bryan Loniewski >>> <brylon@...> wrote: >>>> We've discovered a slight problem with the restrict_senders plugin >>>> involving instances where a spammer can get around the >>>> 'todays_email_count' an administrator has set by logging in multiple >>>> times (via different computers or different browsers or both). >>> >>> *at the same time*? > > Yes. > >>> >>>> As far >>>> as I can tell this is specific to environments (like ours) that have >>>> multiple webmail machines. The issue comes down to the way user >>>> preferences are get (and set) and the caching that takes place. >>> >>> I don't think it's specific to your setup - I can reproduce it if I >>> log in on a local test server under two different browsers at the same >>> time before I start sending messages. Then I get the full >>> $restrictNumberOfEmailsPerDay number of emails in BOTH browsers. >>> >>> This is caused by the fact that SM uses a cache of the user prefs in >>> the PHP session. >>> >>>> I can >>>> remedy the issue by explicitly doing a call to the backend (in our >>>> case mysql), something like: >>>> >>>> // $emailCount = getPref($data_dir, $username, 'todays_email_count', 0); >>>> $dbh = DB::connect($prefs_dsn, true); >>>> $query = sprintf("SELECT prefval FROM userprefs WHERE >>>> prefkey='todays_email_count' AND user = '$username'"); >>>> $res = $dbh->query($query); >>>> while ($row = $res->fetchRow(DB_FETCHMODE_ASSOC)) { >>>> $emailCount = $row['prefval']; >>>> } >>>> >>>> in order to retrieve the "real" emailCount and not the cached one. >>>> >>>> Has anyone discovered this issue before (I realize this is a fairly >>>> new plugin)? >>> >>> Never heard of it. Thanks for finding it! 2003 isn't that "new". > > I did not realize this plugin was that old, sorry about that. I guess > I thought it was "new" since I don't recall seeing it over the last > few years. > >>> >>>> Is there a more (there must be?) intelligent way of >>>> remedying the issue? >>> >>> Not really, except, of course, to abstract the code more - but the >>> solution ends up being the same - the SM prefs cache has to be >>> destroyed and reloaded. Because this code is run in a high-impact >>> part of SM, I'm hesitant to do that, but I don't think there is any >>> other solution. So what I'll do is make it configurable and give you >>> the choice. > > How much code would need to be tweaked to just destroy *only* certain > prefkey values (e.g., todays_email_count)? OR not cache them at all? > Is that even something worth investigating in the 1.4.x branch? Good point. It would be difficult to do it in the SM core, and certainly wouldn't make it into our stable stream (1.4.x), but there does happen to be a hook that lets you override the desired pref value. That hook is *only* in the file prefs backend, but that can be considered a bug, so we can add it to the DB backend. However, that would leave the plugin to know how to fetch a preference value on its own for each backend type, which I'm not too fond of. If the plugin were to pull its own single user preference value, I'd rather tie it specifically to a value stored in a file in the data directory, even if you are using DB-backed prefs. That may not work very well, for example, in an environment like yours. >>>> There may be other variables specific to this >>>> plugin and perhaps others that are "count" sensitive and would falter >>>> if a user (spammer) has multiple webmail instances going... >>> >>> I think only $restrictSubsequentMassEmails is relevant here, and I >>> think it'd be less likely to be a target because if a spammer is >>> hitting up against it already,. they'd have to have at least tens of >>> connections open at once to get the speed they want out of it (without >>> still having to wait). I will implement the needed solution, however, >>> such that it fixes any possible exploit here, too. > > Thanks. > >> >> On a related note, a spammer could use the Reset User Preferences >> plugin to evade these "counter" type settings by simply resetting >> their user preferences once they hit the limit. The new version I am >> working on will have a fix for this as well. > > We thought about that too and look forward to testing out this plugin. > Recently, there has been an increasing need for a plugin like this. I sent you a copy of Restrict Senders offline - do you have any feedback on how the solution worked? Do your comments above indicate that the full preferences cache reset are dragging down performance? I will also send you the newer Reset User Preferences plugin release candidate. I'd like to address the issues above, but I'm not sure I see any better solution. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ----- squirrelmail-plugins mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-plugins@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins |
|
|
|
|
|
Re: restrict_senders caching issue
by Paul Lesniewski
::
Rate this Message:
On Mon, Jun 23, 2008 at 12:19 PM, Bryan Loniewski
<brylon@...> wrote: >> On Mon, Jun 23, 2008 at 10:22 AM, Bryan Loniewski >> <brylon@...> wrote: >>> On Mon, Jun 16, 2008 at 12:50 PM, Paul Lesniewski <paul@...> wrote: >>>>> On Mon, Jun 16, 2008 at 11:16 AM, Bryan Loniewski >>>>> <brylon@...> wrote: >>>>>> We've discovered a slight problem with the restrict_senders plugin >>>>>> involving instances where a spammer can get around the >>>>>> 'todays_email_count' an administrator has set by logging in multiple >>>>>> times (via different computers or different browsers or both). >>>>> >>>>> *at the same time*? >>> >>> Yes. >>> >>>>> >>>>>> As far >>>>>> as I can tell this is specific to environments (like ours) that have >>>>>> multiple webmail machines. The issue comes down to the way user >>>>>> preferences are get (and set) and the caching that takes place. >>>>> >>>>> I don't think it's specific to your setup - I can reproduce it if I >>>>> log in on a local test server under two different browsers at the same >>>>> time before I start sending messages. Then I get the full >>>>> $restrictNumberOfEmailsPerDay number of emails in BOTH browsers. >>>>> >>>>> This is caused by the fact that SM uses a cache of the user prefs in >>>>> the PHP session. >>>>> >>>>>> I can >>>>>> remedy the issue by explicitly doing a call to the backend (in our >>>>>> case mysql), something like: >>>>>> >>>>>> // $emailCount = getPref($data_dir, $username, 'todays_email_count', 0); >>>>>> $dbh = DB::connect($prefs_dsn, true); >>>>>> $query = sprintf("SELECT prefval FROM userprefs WHERE >>>>>> prefkey='todays_email_count' AND user = '$username'"); >>>>>> $res = $dbh->query($query); >>>>>> while ($row = $res->fetchRow(DB_FETCHMODE_ASSOC)) { >>>>>> $emailCount = $row['prefval']; >>>>>> } >>>>>> >>>>>> in order to retrieve the "real" emailCount and not the cached one. >>>>>> >>>>>> Has anyone discovered this issue before (I realize this is a fairly >>>>>> new plugin)? >>>>> >>>>> Never heard of it. Thanks for finding it! 2003 isn't that "new". >>> >>> I did not realize this plugin was that old, sorry about that. I guess >>> I thought it was "new" since I don't recall seeing it over the last >>> few years. >>> >>>>> >>>>>> Is there a more (there must be?) intelligent way of >>>>>> remedying the issue? >>>>> >>>>> Not really, except, of course, to abstract the code more - but the >>>>> solution ends up being the same - the SM prefs cache has to be >>>>> destroyed and reloaded. Because this code is run in a high-impact >>>>> part of SM, I'm hesitant to do that, but I don't think there is any >>>>> other solution. So what I'll do is make it configurable and give you >>>>> the choice. >>> >>> How much code would need to be tweaked to just destroy *only* certain >>> prefkey values (e.g., todays_email_count)? OR not cache them at all? >>> Is that even something worth investigating in the 1.4.x branch? >> >> Good point. It would be difficult to do it in the SM core, and >> certainly wouldn't make it into our stable stream (1.4.x), but there >> does happen to be a hook that lets you override the desired pref >> value. That hook is *only* in the file prefs backend, but that can be >> considered a bug, so we can add it to the DB backend. However, that >> would leave the plugin to know how to fetch a preference value on its >> own for each backend type, which I'm not too fond of. If the plugin >> were to pull its own single user preference value, I'd rather tie it >> specifically to a value stored in a file in the data directory, even >> if you are using DB-backed prefs. That may not work very well, for >> example, in an environment like yours. > > I'm not sure yet whether I like that solution (for us at least). To be clear, my opinion is that this is NOT a good solution. Because it's the only one I can see, my current inclination is to go with the "reset everything" approach, as disappointing as that is. >>>>>> There may be other variables specific to this >>>>>> plugin and perhaps others that are "count" sensitive and would falter >>>>>> if a user (spammer) has multiple webmail instances going... >>>>> >>>>> I think only $restrictSubsequentMassEmails is relevant here, and I >>>>> think it'd be less likely to be a target because if a spammer is >>>>> hitting up against it already,. they'd have to have at least tens of >>>>> connections open at once to get the speed they want out of it (without >>>>> still having to wait). I will implement the needed solution, however, >>>>> such that it fixes any possible exploit here, too. >>> >>> Thanks. >>> >>>> >>>> On a related note, a spammer could use the Reset User Preferences >>>> plugin to evade these "counter" type settings by simply resetting >>>> their user preferences once they hit the limit. The new version I am >>>> working on will have a fix for this as well. >>> >>> We thought about that too and look forward to testing out this plugin. >>> Recently, there has been an increasing need for a plugin like this. >> >> I sent you a copy of Restrict Senders offline - do you have any >> feedback on how the solution worked? > > The solution worked. I was away on vacation for a few days, hence the > delayed response back. > >> Do your comments above indicate that the full preferences cache reset >> are dragging down performance? > > I've not tested that, but I am concerned about it. That was my > motivation for the comments above. I'm a bit confused about the flow. > Is the cache blown away and reloaded *only* when composing mail (i.e., > where the restrict senders code hooks in)? Or is it blown away for > life of the webmail session? It is blown away by the plugin (only if you have $rs_clear_prefs_cache_on_send turned on in the config file) when the user clicks send and immediately reloaded when the plugin asks for the count of emails for the day. >> I will also send you the newer Reset User Preferences plugin release >> candidate. I'd like to address the issues above, but I'm not sure I >> see any better solution. >> ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ----- squirrelmail-plugins mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-plugins@... List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins |
| Free Forum Powered by Nabble | Forum Help |