POST or action limit to increase security

[Alisa]

Hello reader.

My tiny coppermine 1.3 was hit by an human made spam.
The comment-spammer wrote many nasty comments in few minutes.

I would like to have time limits for comments to avoid human and robot made spam.
I mean 1 comment for IP+HOST in a minute (time should be configureable).
For now I have the following code which is working in my other app.:

This code makes the ID = $id of sender. File name id.php, which ment to be a class-file

Code Select Expand


<?php
function ip() //should return an IP
{
if(getenv("HTTP_X_FORWARDED_FOR")) return getenv("HTTP_X_FORWARDED_FOR");
elseif(getenv("HTTP_CLIENT_IP")) return getenv("HTTP_CLIENT_IP");
elseif(getenv("REMOTE_ADDR"))  return getenv("REMOTE_ADDR");
else return 0;
}
$ip=ip();
$host=getenv("REMOTE_HOST");
$id=$ip.$host;
$id=md5($id); //md5 is not the best solution I guess, but it makes IDs even if there are no IP or HOST
return $id;
?>


This code is for checking IDs and manage them. File name idlog-class.php, which ment to be a class-file

Code Select Expand


<?php
//-Input $logfile, $duration, $id

class idlog{
var $exists = 0; //var for the existense of ID in a log
function idcheck($logfile, $duration, $id){
if(!is_writable($logfile)) die("Logfile not ready"); //file-check
$idarray = file($logfile);
$idarray2 = array();

//-ID-check, clean-up = managment
foreach($idarray as $line)
{
$idpart = explode(":", $line);
if(($idpart[0]+$duration)>time())
{
if(trim($idpart[1])==$id) $exists = 1; //-ID-check
$idarray2[]=trim($line)."\n";
}
}

//-makes a new clean id.log-file with fresh ID
$ramfile = fopen($logfile, "w");
if(!$exists) fwrite($ramfile, time().":".$id."\n");
foreach($idarray2 as $line) {fwrite($ramfile, trim($line)."\n");}
fclose($ramfile); //Save the new id.log-file
return $exists;
}
}
?>


This code is in the main file. It combines all the previous code and runs it. File name e.g. comment.php for saving comments

Code Select Expand


//
//violence check
ini_set('include_path', dirname(__FILE__));
$id=require_once("id.php"); $id or die("could not make the id");
require_once("idlog-class.php");
if(idlog::idcheck("/tmp/id.log", 60, $id)) die("Nothing send, wait 60 Seconds");
//
//-if the ID was new or fresh the code would go on.
//


ATTENTION: this code might contain bugs, because I just translated it from my native language.
NOTE: it was clean and working before translation.

I don't know where to implement this code or if it would work in coppermine 1.3.
Give me some advice or at least your oppinion about POST-limits for comments in coppermine.
NOTE: This is also feature request.

[Joachim Müller]

This is a very valid point and a good idea, with comment spam being on the rise.

Joachim

[Alisa]

As I see this request is marked with "valid".

There are some details to discuss before someone starts to implement the feature.

1. should the ID's be saved in files (as I did) or in a database ?
2. should the ID's stay as they are ( time+ip+host ) or converted with md5 ( as I did ) ?
3. default time for ID to remain in a log. 60 seconds or less ?
4. should this post-/-action-time-limit-feauture only be used for comments or be a class that could be used
to limit upload, registration, rating etc. ?

Post your proposals or oppinion on this feauture !

[Alisa]

I have a new name for this possible feature.

It could be named as POST-flood protection or just flood protection.

And if this feature is going to be used to limit time periods to wait for failed login attempts, (UNIX-like)
it could be named as brute-force protection.

Or have someone any other proposals ?

[Joachim Müller]

there already is some "flood protection" in place in other parts of coppermine's code. Anyway, names don't matter - let's see some actual code.

Joachim

[Alisa]

names don't matter - let's see some actual code.

I am so sorry. I must have been misleading you.
I am not working on the implementation of the code from the first post.

I just wanted to give some hints on the feature request by providing a possible solution.
The name should make it easier to understand the agenda in this request.

Never mind!
The given code would work, if all files would be in same path with a writable "/tmp"-folder.
The logfiles have not to be created manually.
All you need is to call the given code before you process the $_POST-request.

But it would not be a real native implementation in coppermine,
or would it be so easy ?

[Joachim Müller]

Reviewing this old thread I figured that it has a serious drawback: the environment vars the mod checks may not be populated in every scenario. Particularly spam bots probably won't populate them. Needs more looking into.
However, some other features have been added to the core code in the devel branch to reduce comment spam.

[Stramm]

Flood protection by IP has some drawbacks. First to name is IP spoofing and secondly one may have legit surfers having the same IP (once all the AOL surfers). I remeber visitor stats where 5-10% of my surfers had the same IP address(es).

Best is to use flood protection only for registered users (if webmasters are afraid of comment spam they should allow commenting only for registered users anyways). Then before a user is allowed to comment the script grabs the timestamp from his last comment, compares it with the actual time and allows/ denies commenting depending on a certain value set in config. That's the easiest and most secure way and what I use for the PM script.

[Joachim Müller]

So do you think that the suggested feature should be implemented in cpg1.5.x (with the subsequent database changes needed) in addition to the other comment improvements we have added so far?
I have no idea about the numbers of comment spam performed by registered users. As far as I can see, comment spammers will use the easiest way to drop their comments, which is attacking sites that allow guest comments.
In my personal gallery (intermediate-sized with 12k+ pics that is based on cpg1.4.x with guest comments turned off) I never had issues with comment spam by registered users.
Imo we (coppermine devs) should focus on other features instead and subsequently move this thread from the "Scheduled for cpg1.5.x" sub-board back to feature requests.

Joachim

[Stramm]

On my gallery only registered users were allowed to comment and those behaved pretty well. Therefore even the already added comment features would be overkill for my needs.

I'd say it's a nice mod if one really needs that feature. Done with a max of 10 lines of code and a config and a lang file entry.

So I won't mind if you move the thread back to the feature requests. Don't know what the others think about it though.