我刚刚在客户端的实时站点上发现了一个注入漏洞。它看起来像这样：
$sql = "SELECT * FROM users_dl WHERE Username = '" . $Uname . "' AND Password = '" . $Pword . "'";
我使用维基百科示例成功地“破解”了它，所以它应该是一个非常糟糕的漏洞。
该网站多年来一直如此。
我知道如何修复它，但是由于我不太了解sql，所以我担心后门。
解决这个问题后我还会暴露吗？还能留下什么后门？
例如，攻击者是否已经获得了完全访问权限，例如 mysql 用户并通过，并且将来甚至不需要注入？我需要更改用户并通过吗？还有什么？
该数据库被多个站点使用，所以我很确定它启用了跨域。
正如@Adnan 所说，最糟糕的是“完全妥协和后门的存在。”。为什么？虽然单独使用 SQL 不会导致系统本身受到任何损害（只需从备份中重新加载数据库，您就应该进行设置），但使用 SQL 并与系统交互的程序具有更高的功能。
例如，您可能有一个包含 PHP 模板片段的表。攻击者可以对其进行编辑并添加恶意代码。如果正在执行 SQL 表中的任何内容（甚至转储到文件中——如果文件可以转储到 web 文件夹，那么攻击者可以使用它来注入和运行他自己的 PHP），那么您可能会遇到问题.
因此，找出表中所有数据的使用位置。如果在任何时候它被保存或执行，看看这是否是可利用的（在前者的情况下，这取决于攻击者是否可以使用它在 web 文件夹中放置任意文本。在后者的情况下，它是几乎总是一个问题）。如果是这样，则系统可能会受到威胁，您可能需要进行全新安装。
如果没有，那么只需在表格中查找问题并修复它们（如果存在）。确保更改您的用户名/密码（并检查流氓帐户）
需要注意的一个有趣的事情是，在 SQLite 中，ATTACH DATABASE可以使用该命令直接引入漏洞。
同样，如果注入允许执行多个SPOOL命令，则可以使用 SQL* Plus 中的命令。
如果您使用上述两种方法中的任何一种，那么无论数据如何使用，全新安装都会很好。
单独的 SQL 注入可能会导致整个系统受损。数据库有很多方法可以通过读写操作访问本地文件系统。让我们考虑数据库以“root”身份运行，那么读取 /etc/shadow 文件将是微不足道的。此外，假设您可以读取数据库的本地用户表（例如选择用户，从 mysql.users 传递），并且在破解简单的散列后，您可能能够使用相同的凭据通过 SSH 连接到主机（滥用密码重用） . 此外，可能更常见的是，您可以从数据库本身执行操作系统命令。Xp_cmdshell 可以在 SQL Server 上使用，用户定义的函数可以在 MySQL 上创建，并且在 Oracle 上有很多方法可以做到这一点 - 创建 Java 函数只是其中之一！
如果您的数据库已被入侵，并且您没有采取任何步骤将其锁定或加固，那么您可以假设最坏的情况 - 攻击者已将权限升级到操作系统本身。