IDORvsSQLi

IDOR

IDOR 是最简单但最常见的权限漏洞——把 URL 中的 user_id=123 改成 user_id=124，就能看到别人的数据。Bug Bounty 中 IDOR 的报告量常年排名前三。

SQLi

SQLi 通过在用户输入中注入恶意 SQL 代码来操纵数据库查询，可以绕过认证、窃取数据甚至删除整个数据库。虽然是最古老的 Web 漏洞之一，但至今仍然常见。

IDOR

• 最简单的漏洞类型之一，但危害可能很大
• 核心问题：缺少服务端权限校验
• Bug Bounty 中最常见的漏洞类型之一

SQLi

• OWASP Top 10 的常客，历史最悠久的 Web 漏洞
• 参数化查询是最有效的防御手段
• ORM 框架大幅降低了 SQLi 风险但未完全消除

IDOR

应用程序使用用户可控的标识符直接访问后端对象但未验证访问权限的安全漏洞

SQLi

通过在应用程序输入中注入恶意 SQL 代码来操纵后端数据库的攻击技术

IDOR

• API 安全测试
• 权限模型的完整性验证
• Bug Bounty 漏洞挖掘

SQLi

• Web 应用安全测试
• 数据库安全评估
• 安全编码培训

IDOR

IDOR 发生在应用程序使用用户可控的标识符（如 ID、文件名）直接访问后端对象，但未验证当前用户是否有权访问该对象。攻击者只需遍历或猜测标识符就能访问其他用户的数据。防御方法包括：服务端权限校验、使用不可预测的标识符（UUID）、以及基于会话的访问控制。IDOR 看似简单，但在大型应用中很容易遗漏，特别是在 API 端点和批量操作中。

SQLi

SQL 注入是 Web 安全中最经典的攻击类型，通过将恶意 SQL 代码插入应用程序的输入字段来操纵后端数据库。攻击类型包括：联合查询注入、布尔盲注、时间盲注和带外注入。防御的黄金法则是使用参数化查询（Prepared Statements），永远不要拼接用户输入到 SQL 语句中。现代 ORM 框架（如 Drizzle、Prisma）默认使用参数化查询，大幅降低了 SQLi 风险，但原生 SQL 查询和存储过程仍是潜在风险点。