If you run a Life Server you probably use extDB2. It is a wonderfully optimized and amazingly useful plugin used for Database connectivity. The problem with many life servers is they use SQL_RAW (mode 2), which take a string from SQF and executes it in the mySQL database. This inherently opens a security vulnerability on the majority of Life servers.

I am going to walk you through one major vulnerability that the server could be open to.

The Requirements

In order for this exploit to be used, your server must be vulnerable to a remote execution exploit. I've covered this topic before so I will not go into detail.
Basically, cheaters would need to be able to execute SQF code on your server through some exploit (be it createUnit or a more complicated remoteExec exploit)

The exploit

The first part of this exploit requires the cheater to establish their own connection to the extDB2 extension. The cheater would need to access your extDB2 sql id. Life servers store this in the life_sql_id variable. The cheater would run something like this:
DB_ID = (call life_sql_id);

Next the cheater would need to establish his own connection function. Something like:

And:

Finally the cheater would choose which exploit he would want to run. Similar to these:

Those exploits, by order of execution are:

  • Database Creation Spam
  • List all Databases
  • Delete all Databases

This is only the beginning of the rabbit whole. If you share your mySQL database with other important systems (think website), those could also be accessed. All user data from players could be accessed, manipulated, and deleted. Bad stuff.

The solutions

There are quite a few. I will be shilling for SQL_CUSTOM_V2 which allows you to only run pre-made SQL queries through extDB2, which solves this problem completely.
Another solution, however, is to edit the permissions of your mySQL user to only be allowed to execute what you need it to in the database you need it to.

The thing with SQL_CUSTOM_V2 is, this also prevents users from modifying the player data. The SQL user would need to have permissions to do this, which is why the second solution is imperfect.
SQL_CUSTOM_V2 is great. Altis Life already has some pre-made statements (view them here). This, if setup properly, can prevent this entire issue from effecting your server.

Tl;dr: Use SQL_CUSTOM_V2 in extDB2 to prevent your server from being vulnerable to database injection exploits.