我正在使用 Security Shepherd 作为培训工具，现在我正面临挑战，SQL Injection Escaping Challenge。
挑战：
当我在 MySQL 的本地数据库中像上面那样进行查询（只是使用不同的表名）时，它工作得很好（我假设 Shepherd 在这个挑战中使用 MySQL，因为它是我唯一的 DBMS 类型面对直到现在）。
知道为什么上述查询可能无法作为 SQL 注入工作吗？
挑战提示中提到的后端使用的查询是：
SELECT * FROM customers WHERE customerId="1" OR "1"="1";
'该应用程序通过将其\'作为对 SQL 注入的保护来逃避任何攻击。它不会改变".
简短的回答：滥用他们的逃生方式。试试\' OR 1=1; --。
长答案：
它们的转义功能通过将 every 替换'为\'. 所有这些，包括前面已经有反斜杠的那些。这意味着如果他们看到\'，那最终会变成\\'- 一个转义的反斜杠，后跟一个未转义的单引号。
之后，就是标准的 SQL 注入了。OR 1=1获取数据库中的每一行，;终止语句，并将--其余的注释掉，以便它们的关闭引号、语句结尾、其他条件等被忽略。
我刚刚发现，如果有人在管理员配置文件中将模块布局更改为锦标赛模式，则会出现一个新的选项卡作弊。所以上面的答案是：\'or"1"="1"; --.
这些答案是不正确的。这个问题的正确答案是：
" or ""="
原因：聪明的黑客可能会通过在用户名或密码文本框中简单地插入“或”“=”来访问数据库中的用户名和密码。结果 SQL 有效。它将返回表 customers 中的所有行，因为 WHERE ""="" 始终为真。
上述答案都是正确的，因为它们都成功执行了注入，因为聪明的黑客正在寻找有效的注入。一旦黑客找到有效的注入，他们就不会继续寻找其他可能的查询，而是扩展有效的注入。也可以做计算逻辑得到同样的结果，如：“OR”1+1