SQL read-only bypass vulnerabilities pose significant security risks to Model Context Protocol (MCP) servers, potentially leading to unauthorized data access, denial of service (DoS) attacks, and full SQL injection exploits. This article explores the nature of these vulnerabilities, how attackers exploit them, and best practices to mitigate such risks. By understanding the mechanisms and implementing robust security measures, developers can safeguard their MCP servers against these threats.

A Brief introduction to the Model Context Protocol (MCP)

Model Context Protocol (MCP) is a communication protocol designed to facilitate interactions between different components of a software system, often used in environments where model-driven architecture is prevalent. MCP servers typically handle data exchange and processing, making them integral to the system’s operation.

SQL Interfaces in Model Context Protocol (MCP) Servers

Common Uses of SQL Database Access in MCP Servers

MCP servers frequently interact with SQL databases to perform operations such as data retrieval, reporting, and analytics. These interactions are crucial for maintaining the system’s functionality and providing real-time data insights. However, improper handling of SQL queries can lead to vulnerabilities, including SQL read-only bypass.

What is SQL Read-Only Bypass?

SQL read-only bypass occurs when a system intended to restrict database access to read-only operations fails to enforce this restriction effectively. A common misconception is that checking if a query starts with “SELECT” is sufficient to ensure read-only access:

const trimmedQuery = query.trim().toLowerCase();
if (!trimmedQuery.startsWith('select')) {
  throw new Error('Only SELECT queries are allowed for security reasons');
}

This simplistic approach can be easily circumvented, leading to potential security breaches.

Common Scenarios Where SQL Read-Only Bypass Can Occur

1. Denial of Service (DoS) via Long-Running Query:

   SELECT pg_sleep(300); -- Sleep for 5 minutes

2. Accessing Sensitive Information via UNION:

   SELECT pid, usename, state, query, backend_start, state_change
   FROM pg_stat_activity
   WHERE state = 'active';

3. Escalation to Full SQL Injection via Multi-Statement Execution:

   SELECT * FROM users; DROP TABLE users; --

4. Shutting Down the Database Server Entirely:

   SELECT pg_terminate_backend(12345); -- PID can be retrieved from pg_stat_activity

Potential Risks and Impacts of SQL Read-Only Bypass

• Unauthorized Data Access: Attackers can access sensitive tables and database schema information.
• Denial of Service (DoS): Long-running queries or resource-intensive functions can be executed, consuming excessive resources.
• Full SQL Injection Attacks: Attackers can execute arbitrary SQL commands, including data modification and deletion.

How Attackers Exploit These Vulnerabilities

Attackers exploit these vulnerabilities by crafting SQL queries that bypass the simplistic read-only checks. By appending additional statements or using SQL functions, they can execute unauthorized operations.

Examples of SQL Read-Only Bypass Attacks

• Datadog Report: SQL read-only bypass in Anthropic PostgreSQL MCP server. Read more
• Liran Tal’s Report: SQL read-only bypass in PostgreSQL MCP server template. Read more

Best Practices to Prevent SQL Read-Only Bypass

SQL Injection Prevention Techniques

• Use Parameterized Queries or Prepared Statements: These techniques prevent SQL injection by separating SQL code from data.
• Validate and Sanitize All User Inputs: Ensure that all inputs are checked for malicious content before processing.

SQL Read-Only Bypass Specific Measures

1. Enforce Read-Only Queries Using Built-In Database Transaction Modes:

   BEGIN TRANSACTION READ ONLY;
   -- User input SELECT query here allowing only one single query to be executed (no multiple queries should be allowed)
   ROLLBACK;

2. Restrict Programmatic Database Interface to Single Queries:

   Ensure that only single queries are allowed, rejecting multiple queries to prevent attackers from appending malicious statements.

3. Use MCP Resources for Database Access:

   Leverage MCP’s built-in Resources mechanism to specify the database schema and table. This works because it limits the entropy of free-text table names for the SQL query and relies on a more structured and controlled approach to database access.

   Consider the following example:

   server.setRequestHandler(ReadResourceRequestSchema, async (request) => {
   const resourceUrl = new URL(request.params.uri);
   const pathComponents = resourceUrl.pathname.split('/');
   const schema = pathComponents.pop();
   const tableName = pathComponents.pop();
   if (schema !== SCHEMA_PATH) {
      throw new Error('Invalid resource URI');
   }
   const client = await pool.connect();
   try {
      const result = await client.query(
         'SELECT column_name, data_type FROM information_schema.columns WHERE table_name = $1',
         [tableName]
      );
      return {
         contents: [
         {
            uri: request.params.uri,
            mimeType: 'application/json',
            text: JSON.stringify(result.rows, null, 2)
         }
         ]
      };
   } finally {
      client.release();
   }
   });

4. Force Single-Query with pg Client:

   While the pg npm package only exposes a query method that can execute multiple queries, you can force a single query by forcing a prepared statement using the following syntax:

      const result = await client.query({
        name: "single-query",
        text: sql,
        values: [],
      });

5. Allow Queries Only to Specific Allow-List Tables:

   Implement an allow-list of permissible tables, potentially using an ORM or dialect-specific query builder.

6. Maintain a Closed Allow-List of Permissible SQL Functions:

   const ALLOWED_FUNCTIONS = new Set([
     'count', 'sum', 'avg', 'min', 'max',
     'upper', 'lower', 'length', 'substring',
     'date_part', 'now', 'current_timestamp', 'current_date',
     'coalesce', 'greatest', 'least'
   ]);

7. Maintain a Closed Deny-List of SQL Keywords and Patterns:

   const dangerousPatterns = [
     /pg_\w+\(/i,           // PostgreSQL system functions
     /\bcopy\b/i,           // COPY command
     /\binto\s+outfile/i,   // File operations
     /\bload_file\b/i,      // File loading
     /\beval\b/i,           // Code evaluation
     /\bexecute\b/i,        // Dynamic execution
     /\bsleep\b/i,          // Sleep execution
   ];

Implement Strict Access Controls

• Enforce Least Privilege Principle for Database Users: Limit user permissions to only what is necessary.
• Regularly Review and Update Access Permissions: Ensure that permissions are up-to-date and reflect current security policies.
• Use Database Roles and Permissions Effectively: Leverage roles to manage user access efficiently.

References

• GitHub Kanban MCP Server found vulnerable to command injection: https://github.com/advisories/GHSA-6jx8-rcjx-vmwf
• iOS Simulator MCP Server found vulnerable to command injection: https://github.com/advisories/GHSA-6f6r-m9pv-67jw
• Liran’s Node.js Secure Coding for educational materials on injection attacks and secure coding practices: https://www.nodejs-security.com/book/command-injection
• How to Bypass Access Control in PostgreSQL in Simple PSQL MCP Server for SQL Injection

For more insights and updates on security best practices, follow me on Twitter and explore my work on GitHub.