OJS - Probable SQL injection is inserting users in Journals

Hi there.

I’ve had problems with some Journals, where there are a lot of users created.

According the image, this is a example which is happening: a lot of pages listing unknown users. For stop this action, I temporarily changed the setup of the journals, in management (4) > Access and Security settings > User registration, to registrations are made by the own managers.

Looking the error log in Apache, I´ve seen this once and again:

Now, my doubts are:

  1. In current version, how I can stopping the unknown users register? Are there some kind of “extension” to protect the OJS installation?
  2. How can I proceed to remove that users? Do you have a suggestion? I was thinking to do by sql commands.
  3. Is it possible the problem is solve on the next version (3.x)? I am planning update OJS soon.
  4. Are there some actions that I could do on Apache or in operacional system of the server?

Hi @Mauricio_Adriano,

Are you sure you’re thinking of an SQL injection? If they’re creating spam registrations, that wouldn’t be an SQL injection.

You can turn on ReCAPTCHA support in your config.inc.php to cut down on the amount of spam registration, but as Google recently retired their old ReCAPTCHA API, you’ll need to patch your OJS to support the new one. See reCaptcha V2 Manual upgrade steps - #2 by asmecher for details.

See How do I combat SPAM? for more details on spam registrations.

OJS 3.x already supports ReCAPTCHA v2 out of the box.

Alec Smecher
Public Knowledge Project Team

Hi Alec. I was thinking that could be sql injection because the captcha options are already activated in config.inc.


; Whether or not to enable Captcha features
captcha = On

; Whether or not to use Captcha on user registration
captcha_on_register = On

; Whether or not to use Captcha on user comments
captcha_on_comments = On

; Font location for font to use in Captcha images
font_location = “/usr/share/fonts/truetype/freefont/FreeSerif.ttf”

I’ll check the patch question as the “combat spam” link, thanks.

But, I still have to remove the users registration… Would you have a suggestion?

Hi @Mauricio_Adriano,

The options you’re looking for are called e.g. recaptcha – see config.TEMPLATE.inc.php for examples. I suspect you’ve got some options from an older config file.

To batch remove users, you’ll probably need to explore the database and determine a heuristic separating real users from spam registrants. Then use e.g. tools/mergeUsers.php to remove them.

Alec Smecher
Public Knowledge Project Team

Hi Alec.

I think the applied procedures have worked… But there are some users registrations in a journal… quite of them without “date_registered”… Besides, the volume is bigger than the others journals. Could be a specific problem wih some configuration of this journal?

*Since 2018-07-09:

Journal - registered / not registered
10 - 2 / 2
13 - 8 / 3
28 - 4 / 5
29 - 2 / 0
> 3 - 57 / 128
36 - 2 / 2

If I keep these records, will the system remove alone (inside the 14 days configured)? Or should I remove them hereafter (SQL scripts)?

And, in the config.inc file, now that the recaptcha is enabled, the parameter captcha must be changed to off?


captcha = On

captcha_on_register = On
captcha_on_comments = On

font_location = “/usr/share/fonts/truetype/freefont/FreeSerif.ttf”

recaptcha = on

recaptcha_version = 2

The attacks returned… I don´t know how I could to do.

I finished to implement the procedures, including honey pot, in March, 23; they worked until April, 29. After this, I’ve had 400 user’s injection, in average, per day (250 if we considered the disabled field in users table as “0”).

Furthermore, there are a lot of comments in articles ditto.

What can I do more?

PS: OJS now.