this looks like robot registration. You can use a regidtration via email confirm, or image with string on it.

I have a similar problem and it is occurring on two separate servers on all ez sites on those servers. The problem is happening on versions from 3.9 to 3.9.3 inclusive. Some of the username submitted have also included php scripts as usernames. Definately a robot attack.

These started to appear on my sites on the 25/01/08. What can we do about this with out disabling the registration?

i think the way to avoid this is an independ from your CMS. it may be anithing (include eZ Publish). You may validate an username and password for range of accepted characters (avoid, for example, PHP script as username, because characters "?", "<" and ">" are not valid in username). Also you can use a "CAPCHA" system as a part of registration (see http://en.wikipedia.org/wiki/CAPTCHA). You may use a confirmation of registration by email. So, there are a numbers of ways.

http://ez.no/content/advancedsear...;SearchDate=-1&SearchPageLimit=4

Many thanks to all
trying to install "CAPCHA" now

Greetings,

We have such a problem of robot attack using the registering process... despite our using the antispam extension.

Has anyone had the same kind of problem ? And if you were able to solve it... how ?

Thanks !

Which antispam extension do you use and what's the result of the attack exactly?

I've been getting a few of these too, on alec.org.au (running 3.9.1). I'm not sure if I can really see the point - most just fill out the form and don't confirm so don't get activated - but a couple have. I suspect that someone somewhere is paying a fee per registration for people to sign up to anything possible and add spam links.

I've added reCAPTCHA, but I can't see that that is going to make any difference if the spammer is human.

Paul,

I can't agree with you. Of course, almost any human being can complete the registration process, but I believe we are talking bots here and these are two completely separate topics in my opinion. While couple of human registrations should not do much harm, couple of thousand automatic ones will definitely do.

As to the CAPTCHA solutions, make sure the one you're using cannot be omitted (the datatype cannot return 'accept' upon validation if its data is missing, which has been the default behavior of many datatypes so far). This has been discussed several times, I'm sure you can find information on that here in the forum as well as at http://issues.ez.no

Cheers,
Piotrek

FYI: the issue Piotrek refers to: http://issues.ez.no/10655

Hi Piotrek, Paul,
The extension we use is Antispam : http://ez.no/developer/contribs/datatypes/antispam
The captcha field is required and cannot - as far as my knowledge goes - be omitted.
Anyway, thanks for your answers, I'll check http://issues.ez.no

[Edit] And thanks Kristof !

Modified on Thursday 15 May 2008 10:24:18 am by Patrick Renaud

Hi Patrick

Unfortunately I must say that at first sight this datatype indeed has the problem Piotrek mentioned:

function validateAttributeHTTPInput( &$http, $base, &$objectAttribute, $isInformationCollector = false )
    {
        $classAttribute =& $objectAttribute->contentClassAttribute();
        $classparam = SckAntiSpamType::classAttributeContent( $classAttribute );
        $is_required = $objectAttribute->validateIsRequired();
        $must_validate = ($isInformationCollector == $classAttribute->attribute( 'is_information_collector' ) );
        
        if( $http->hasPostVariable( $base . '_sckantispam_answer_' . $objectAttribute->attribute( 'id' ) ) )
        {
            if( $is_required === true && $must_validate === true )
            {
                $answer =& $http->postVariable( $base . '_sckantispam_answer_' . $objectAttribute->attribute( 'id' ) );

                if( $answer != $objectAttribute->content() )
                {
                    $objectAttribute->setValidationError( "Antispam code is incorrect." );
                    return EZ_INPUT_VALIDATOR_STATE_INVALID;
                }
            }
        }

        return EZ_INPUT_VALIDATOR_STATE_ACCEPTED;
    }

As you can see, when the post variable is not present the validation method will return EZ_INPUT_VALIDATOR_STATE_ACCEPTED. So omitting the post variable is enough to bypass the check.

However, it should usually be quite easy to modify the attribute validation method to secure it. All you need to do is to arrange it to fit the following closed-system pattern:

if( ok )
{ 
   return EZ_INPUT_VALIDATOR_STATE_ACCEPTED;
}
return EZ_INPUT_VALIDATOR_STATE_INVALID;

instead of open one:

if( !ok )
{ 
   return EZ_INPUT_VALIDATOR_STATE_INVALID;
}
return EZ_INPUT_VALIDATOR_STATE_ACCEPTED;

Usually it would take no more than 10 minutes.
Good luck,
Piotrek

PS. If this doesn't help, there might be something wrong with your CAPTCHA extension...

Modified on Thursday 15 May 2008 12:38:40 pm by Piotr Karaś