Why Laravel is the Secured Framework For SQL Injection?

Morris Muriuki Muthigani
51
0
laravel

06/29/2023 (10 months ago)


What Is SQL Injection?

SQL Injection is a type of cyber attack that makes it possible to execute criminal SQL statements. These statements control the database server behind any web application. Hackers can use SQL Injection vulnerabilities to destroy application security measures. They can go around authentication of a web page and retrieve the content of the whole SQL database. They can also use SQL Injection to add, delete and modify records in the database. The best cyber security company  that you approach will always provide the best to protect your database from SQL injection and attacks.

An SQL Injection vulnerability may affect any website that uses an SQL database such as MySQL, Oracle, or others. Criminals may use it to gain unauthorized access to your personal and highly important data like:

  • Customer information
  • Personal data
  • Trade secrets
  • Intellectual property and more

SQL Injection attacks are one of the oldest and very dangerous web application vulnerabilities. Cyber security service providers will help you with this serious problem.

Why Laravel Framework?

Laravel is a web app development framework with expressive and royal syntax that makes the entire web development process faster, simple, and more enjoyable for developers by eliminating all the pain points associated with handling the most complex PHP code.

It simplifies some of the mostly executed tasks like routing, authentication, sessions, caching, and others so that developers can focus on building most business-related features of the web application. Laravel protects the web apps from SQL injection as long as you're using the fluent query builder.

Laravel does this by making secured and prepared statements that are going to escape any user input that may come in through the apps. If attackers add a new input to a form, they may try to insert a query and then run their own SQL query to damage your application database. However, this won't work while you are using Eloquent. Eloquent is going to protect from this SQL query and the invalid query will just be saved as text into your database.

What Are The Types Of SQL Injection Attack Vectors That Laravel Can’t Protect?

Developers usually make mistakes by thinking Laravel protects from all SQL injections and attacks, while there are some attack points that Laravel cannot protect, here are the most common causes of SQL injections that we saw in the latest Laravel applications during our security Checks.

SQL Injection via column name

The first common mistake that we see is that a lot of people think that Laravel would escape any dimension that is passed to Query Builder or Eloquent. But in reality, it’s not that safe to pass user-controlled column names to the query builder.

It’s important to mention that the demonstrated attack point is fixed on the Laravel versions, but still, Laravel warns developers even in the new documentation to not pass user-controlled column names to Query Builder without whitelisting.

Commonly, even if there is no chance to turn a custom column into an injected SQL string, we still do not recommend allowing to sort the data by any user-provided column name, since it can introduce a dangerous security issue.

SQL Injection via validation rules

Let’s take a look at the following simplified validation code:

$id = $request->route('id');
$rules = [ 'username' => 'required|unique:users,name,' . $id,];
$validator = Validator::make($request->post(), $rules);

Whether Laravel uses $id here to command that database and $id is not escaped, it will allow a hacker to perform an SQL injection.

How to prevent SQL injection in Laravel?

Laravel’s Eloquent ORM uses PDO binding that protects web apps from SQL injections. This relevant feature ensures that no client could modify the intent of the SQL queries.

Consider the example of the form used to collect users’ email addresses from a database. the form will search for an email address, for instance, “abc@example.com”. Now imagine that the SQL query is modified to:

SELECT * FROM users WHERE email = 'abc@example.com' or 1=1

In the above example, 1=1 is a simple expression that always evaluates to be true. If it is attached to the above query with the OR condition, the query will fetch all records from the table because the SELECT condition will evolve to be always true.

Now consider another direction of the attack in which the query is modified directly to the command “drop table users” and instead of the email address, “abc@example.com” is written. The query will look like this:

SELECT * FROM users WHERE email = 'abc@example.com'; drop table users;

When this query is executed, the table “users” will be deleted from the database.

When the PDO parameter binding is in place, the input is in quotes and the query will look like this:

SELECT * FROM users WHERE email = 'ancy@example.com or 1=1'

Since no records will match with either the email or the “1=1”, the query will not be returning anything.

This framework provides other ways of talking to databases, such as raw SQL queries. Yet, Eloquent remains one of the most popular options.

Laravel framework uses PDO binding to prevent SQL injection attacks because no variable gets to the database without validation.

If this is the case, one should always use prepared SQL queries to prevent misplacement. Consider the following statement that looks ripe for SQL injection:

Route::get('this-is-prone-to-sql-injection', function() {
$name = "'ancy' OR 1=1";
return DB::select(
DB::raw("SELECT * FROM users WHERE name = $name"));});

Here the statement 1=1 used in the OR condition will result in returning all the rows in the user’s table. This can be prevented by using the following code instead:

Route::get('safe-from-sql-injection', function() {
$name = "'ancy' OR 1=1";
return DB::select(
DB::raw("SELECT * FROM users WHERE name = ?", [$name]));});

Laravel replaces the question marks with the query, automatically escaping the input variables. This protects the query from SQL injection attacks.

Discussion (0)

Recent Blogs

Our Recent Blogs