mmeyer2k/laravel-sqli-guard

SQL injection prevention plugin for laravel

dev-master 2023-01-17 20:37 UTC

This package is auto-updated.

Last update: 2024-10-18 00:24:54 UTC


README

A Laravel plugin that forces usage of PDO parameterization and strongly protects against SQL injection attacks.

This package should not be used as a replacement for writing secure queries!!! See Caveats.

Install

composer require mmeyer2k/laravel-sqli-guard

Configuration

By default, this package's service provider is autoloaded

Usage

This plugin works by checking query strings for unsafe character sequences during the query preparation process.

The query below will throw an Illuminate\Database\QueryException due to the presence of the single quotation mark character in the query string.

DB::select("select * from users where id = '$unsafe'");

To make this query safe and avoid an exception, you must write the query as such:

DB::select("select * from users where id = ?", [$unsafe]);

Overriding Protection

To disable protection use the provided allowUnsafe function. Be careful, queries could be vulnerable anywhere down-stream of this command!

\Mmeyer2k\LaravelSqliGuard::allowUnsafe();

To re-enable protection after executing a dangerous query use blockUnsafe.

\Mmeyer2k\LaravelSqliGuard::blockUnsafe();

Forbidden Character Sequences

Caveats

Unfortunately, not all SQL injection scenarios can be blocked by this simple inspection.

Queries that blindly accept user input can still be manipulated to subvert your application, leak data, or cause denial of service.

A query that returns data can be manipulated to leak records. Consider this poorly written hypothetical API controller route:

function users()
{
    $id = request('id');

    return json_encode(DB::select("select * from users where id = $id"));
}

If the query string ?id=1 or id > 1 is given, all records will be returned. Depending on the context, this could be a major security issue.

Another concern is that some DDoS attacks are possible if the attacker knows, or can guess, information about the data schema. Again using the above function as an example, but now the query string id= (SELECT COUNT(*) FROM users A, users B, users C, ...) is sent. CPU exhaustion can occur if there are many rows in the specified table(s), or if the number of junctions is high. A similar attack is possible against information_schema, but it requires no knowledge.