Question

我正在努力加强我的应用程序的安全性，我计划做的第一件事是通过SSL服务整个应用程序。我想知道这是多么安全，如果它是我采取的唯一保护应用程序的措施。

例如，假设我有以下前端代码：

<input id="password" value="my_password_value" />
<script>
    $(document).ready(function(){
        $('#password').blur(function(){
            location.href = 'my_backend_script.php?password=' + $('#password').val();
        });
    });
</script>

然后在我的后端脚本中我有：

$user_ID = 1;
$password = $_GET['password'];
$USER_edit = mysql_query("UPDATE USERS SET password='$password' WHERE id='$user_ID'");

如果上面的示例是在SSL连接下运行的，那么它是否可以免受任何SQL注入攻击？

注意： 我意识到准备好的语句是防止注入攻击的标准，并且最佳实践将被实现，但我只是对SSL作为一个独立解决方案的安全性感到好奇。

快速回答： 不，SSL不会任何来阻止SQL注入攻击。

Answer 1

SSL仅保护客户端和服务器之间的传输通道。但客户端仍然可以通过该安全通道发送恶意数据。

Answer 2

不，不是真的。 SQL注入与连接的安全性无关，而是与处理用户输入的安全性有关。使用预准备语句有助于防止故意错误输入的输入数据破坏您的SQL查询。

如果您的所有用户都是必须登录的受信任用户，则使用SSL可以提供一定程度的安全性来防止SQL注入，因为您更有信心进入您的应用程序的用户不会试图破解您的系统。

但SSL不能替代正确编写数据库访问代码。

Answer 3

SSL根本不能防止SQL注入攻击。准备好的语句，视图等是SQL注入的解决方案。

Answer 4

当我读到这个问题时，我想到的问题是：注射发生在哪里？

是注入流氓SQL的中间人还是登录用户？
使用SSL将确保（在适当的程度上）MITM不能将恶意数据（包括SQL）隐藏到我的数据包中。

那么，为什么有这么多人说SQL注入与SSL完全无关？
在我看来，使用SSL可以在很大程度上解决许多攻击。

例如，考虑一个现有的应用程序，其中不可能为SQL注入应用一个真正的解决方案：比如，Prepared语句，因为它将导致的代码流失量。
< / p>

您可以做些什么来轻松实现应用的更好安全性？
正如@JeffOlson所提到的，如果您的用户需要登录并且登录后您信任它们，那么SSL就是一个充分的解决方案（用于SQL注入和其他一些攻击）。

虽然您似乎已经同意SSL不会为每个应用程序解决SQL注入完全。

SSL是否会阻止SQL注入？

4 个答案: