Support ⇒ Security ⇒ SQL injection attacks ⇒ Community Forums ⇒ CPG Dragonfly™ CMS
Forum IndexSecurity

SQL injection attacks Reply to topic


I've noticed a number of SQL injection attacks being attempted against one of my sites over the past 24 hours. I've taken the following steps:

- Banned the IPs involved
- Denied the user-agent of the automated tool used to carry out these attacks in htaccess
- Temporarily de-activated one of the modules (dfmaps) which seems to have been targetd
- Restricted access to registered users for another module (DF_Multimedia) which also seems to have been targeted

I'm not sure if those last two steps (module de-activation and access restriction) are effective in countering any potential threat, perhaps someone can clarify. Beyond that, is there anything else I should be doing to lock things down further?

Thanks in advance for any comments or suggestions.

Note: WWW Private Listing - Staff Only

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
linux/Apache 2.4.27/MySQL 10.1.26-MariaDB/PHP 5.2.17/Dragonfly 9.2.1


IPs and UAs can change, a disabled module does the job, a restricted one doesn't.

However if the modules are safe there is no need to be alarmed ... but that's the question are modules safe? Not sure about who wrote them either sorry.

If our basic standards have been followed, then it should be ok.

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.6 / PHP 5.6 / DCVS


Thanks Nano, appreciate the quick response (I can probably sleep a bit easier now!) Could I just ask for clarification on one thing? When you say:

NanoCaiordo wrote
a disabled module does the job, a restricted one doesn't


are you saying that disabling a module (in admin -> modules) removes any risk of it being exploited by such an attack, assuming the worst case scenario for the moment that it hasn't been properly coded and is indeed vulnerable.

Note: WWW Private Listing - Staff Only

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
linux/Apache 2.4.27/MySQL 10.1.26-MariaDB/PHP 5.2.17/Dragonfly 9.2.1


Hi Nano,

Sorry, the question is of topic.

NanoCaiordo wrote
IPs and UAs can change, a disabled If our basic standards have been followed, then it should be ok.


I looked the wiki and the documentation, but i found only fragments of security purposes.
Is there a whole description somewhere and i missed it ?

Movix

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux/Apache/MySQL 5.1.49/PHP 5.3.6/ DF 9.3.2.0


NanoCaiordo wrote
a disabled module does the job, a restricted one doesn't

macavity wrote
are you saying that disabling a module (in admin -> modules) removes any risk of it being exploited by such an attack, assuming the worst case scenario for the moment that it hasn't been properly coded and is indeed vulnerable.


Correct, the module isn't executed when disabled.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Fedora 25 / Apache 2.4.27 / MariaDB 10.1.26 / PHP 7.1.10 / Mercurial


@movix

There's a pretty reasonable guide here:
dragonflycms.org/Wiki/id=85/

DonationsPro for DragonflyCMS & SMF

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):


DJ Maze wrote
Correct, the module isn't executed when disabled.


Thank you DJ.

Note: WWW Private Listing - Staff Only

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
linux/Apache 2.4.27/MySQL 10.1.26-MariaDB/PHP 5.2.17/Dragonfly 9.2.1


NanoCaiordo wrote
However if the modules are safe there is no need to be alarmed ... but that's the question are modules safe?


Just been giving this some thought. If any DF expert (DJ? Nano? Phoenix? someone else?) is interested in reviewing the code of these modules to make sure they're compliant with the core security standards please drop me a line, I'll be more than happy to pay you for your time.

Note: WWW Private Listing - Staff Only

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
linux/Apache 2.4.27/MySQL 10.1.26-MariaDB/PHP 5.2.17/Dragonfly 9.2.1


Hi Phoenix,

Phoenix wrote
@movix
There's a pretty reasonable guide here:
dragonflycms.org/Wiki/id=85/


yes, i allready read htis one, btw i read the whole wiki, but i asked since i discovered another security check in this post, talking abour the validation of GET and POST vars source pages.

perhaps i gives another hint on security for macavity.

Mainly the code example
if (!Security::check_post()) { # posted data wasn't coming from our website, error cpg_error(_SEC_ERROR); }

The Security::check_post() method fails every_time in my module and i do not understand why.


Movix

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux/Apache/MySQL 5.1.49/PHP 5.3.6/ DF 9.3.2.0


movix wrote
perhaps i gives another hint on security for macavity.


Yes, at least as far as it confirms I need someone else to check these modules!! I'm way out of my depth Very Happy

Note: WWW Private Listing - Staff Only

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
linux/Apache 2.4.27/MySQL 10.1.26-MariaDB/PHP 5.2.17/Dragonfly 9.2.1


Sorry, i do not have the required level of knowledge on all of that security purposes to make some reliable check.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux/Apache/MySQL 5.1.49/PHP 5.3.6/ DF 9.3.2.0


I'm qualified and got some time, What you need

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
9.21


bulldog wrote
I'm qualified and got some time, What you need


I've replied to your PM.

Note: WWW Private Listing - Staff Only

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
linux/Apache 2.4.27/MySQL 10.1.26-MariaDB/PHP 5.2.17/Dragonfly 9.2.1


I've replied to your PM

Developer of Sports Handicapping Websites.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
9.21

All times are UTC


Jump to: