WebGoat - A3 SQL Injection (mitigation) 2

(P1) 防止 SQL 注入的最佳防御措施，要么是静态查询，要么将数据视为绑定到列的单一实体，而不进行解释。仅在存储过程不生成动态 SQL 的情况下使用。 (P2)这是一个安全存储过程和可注入存储过程的例子，使用动态 SQL是危险的 (P3)查询参数要先经过校验。这里有个重点提示：这个例子里，假设传递的值是基于用户输入的。上面的例子不是正确使用预处理语句的方法，正确方法是下面这个，参数应通过 ps.set..() 设置 (P5)这个任务一起看下视频。 (P8)是否需要进行输入验证？ 我的查询已经无法被注入了，还需要验证输入吗？ 需要！可以防止其他类型的攻击被存储在数据库中，比如 * 防止存储型跨站脚本攻击（Stored XSS） * 防止信息泄露 * 防止逻辑错误——业务规则验证 * 防止 SQL 注入 数据库常常被视为可信任的环境。 (P9)看个2分半的视频。 （P11）预处理语句是否总能防止 SQL 注入？答案是不能。如果我们查看 SQL 语法的规范的定义，这意味着 orderExpression 可以是一个 selectExpression，而 selectExpression 也可以是一个函数。例如使用 case 语句，我们可能可以向数据库提出一些问题，比如： SELECT * FROM users ORDER BY (CASE WHEN (TRUE) THEN lastname ELSE firstname END) 我们可以在 when(… .) 部分替换任何类型的布尔操作。无论是否使用预准备语句，该语句都会正常工作，因为它是一个有效的查询。根据定义，order by 子句可以包含一个表达式。 缓解措施 如果您需要在 Web 应用程序中提供排序列，您应该实现一个白名单来验证 ORDER BY 语句的值。这个值应该始终限制在类似于“名字”或“姓氏”这样的选项。 （P13）最低权限原则包括几个方面：最小权限连接，应用程序应使用不同的凭据连接数据库，以区分信任级别。应用程序通常不需要对表或数据库具有删除权限。数据库账户应限制架构访问权限，为读取和读/写访问定义数据库账户，根据访问权限建立多个连接池，对于身份验证查询，应使用只读访问权限，对于数据修改查询，应使用读/写访问权限。对于存储过程调用，应使用执行权限