.Sql注入，举个例子用户登录，用户名填写admin，密码输入框填写什么可以绕过登录认证？（场景）

其核心就是将我们的where 条件变成true 即可 ！！！ 就是在我们的密码框里面输入一些特殊符号，字符串来实现sql 拼接，改变我们的原始sql语句条件 核心就是我们的输入参数可以和原始sql 拼接会混淆原始sql ，会改变原始sql语句结构：

避开方式：就是将我们SQL语句结构和我们的用户输入的参数来避开

列子 :

sql

SELECT * FROM users WHERE username = '输入的用户名' AND password = '输入的密码'

如果用户名填写admin，密码填写' OR '1'='1，那么整个SQL语句会变成：

sql

SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1'

由于'1'='1'总是为真，所以这个查询会返回用户表中所有记录，通常这意味着查询成功，因此可能绕过登录认证。

但是，这取决于代码如何处理查询结果。如果代码只是检查是否有返回行，那么就有可能绕过。如果代码检查返回的行数是否恰好为1，并且用户名匹配，那么可能不行。但在这个例子中，我们假设代码只是检查是否有返回行。

另一种常见的注入是在密码框中输入：' OR 1=1 --（注意后面有一个空格，--是SQL中的注释符，可以注释掉后面的语句）。这样SQL语句可能变成：

sql

SELECT * FROM users WHERE username = 'admin' AND password = '' OR 1=1 -- '

这样，条件变成了username = 'admin'和(password = '' OR 1=1)，而1=1总是真，所以只要存在用户名为admin的用户，就会返回该行，并且后面的部分被注释掉，不会造成语法错误。

但是，实际应用中，我们应当使用参数化查询来避免SQL注入，而不是拼接字符串。

注意：不同的数据库系统可能有不同的注释符号，例如MySQL使用--（注意有一个空格）或#，Oracle和SQL Server使用--。

因此，对于这个场景，密码输入框可以填写：' OR '1'='1 或 ' OR 1=1 --（注意空格）等。

但是，具体能否成功取决于后端的代码和数据库类型。以上是经典的例子，但现代应用应该已经通过使用预处理语句等方式避免了这种漏洞。

：预处理 可以参考 #{} 于 ${} 文章