Question

只有一两个受信任的人拥有密码。 htpasswd在public_html目录之外。受保护文件夹中的脚本包含未清理的输入。没有密码，SQL注入是否可行？

Answer 1

SQL注入是否可行，没有密码？

假设您的.htaccess和.htpasswd实际上正在为您的用户名和密码设置屏幕，那么它是安全的。如果用户名和密码的组合无效，Apache将返回HTTP 403：Forbidden标头，这意味着该请求从未传递给PHP。这意味着如果没有有效的用户名和密码，就无法执行泄漏的脚本。

受保护文件夹中的脚本包含未清理的输入。

我认为您应该考虑对输入进行消毒，无论是否保护页面。

Answer 2

无论设置如何，您始终始终，始终处理数据，就好像它会随时跳出显示器而SQL注入您的心中。你不会问在x，y和z情况下是否可能，你总是认为它是默认的。

它甚至不需要是恶意的，如果处理不当，任何包含引号的用户输入都会弄乱您的查询，因此无论如何都需要转义输入。

Answer 3

只是消毒那些投入。我是认真的。一个系统与其最薄弱的环节一样强大;即使你信任那些你提供访问权限的人，也总会有其他人可以用来解决这个问题的攻击。一些可能性：

Answer 4

在htpasswd上无法进行SQL注入，但还有其他漏洞。你已经覆盖了一个将文件放在Web根目录之外，但你也应该通过将这个页面添加到你的htaccess来防止apache服务这些页面：

<Files ~ "^\.ht"> Order allow,deny Deny from all </Files>

Answer 5

SQL注入是不可能的，因为没有密码的攻击者无法在第一时间通过Apache。

但是，HTTP Basic Auth会受到中间人攻击，因为密码很容易被截获（如果是公共网站，您可能需要使用HTTPS）。

Answer 6

如果设置正确，我认为没有办法绕过受密码保护的目录。

使用基本身份验证时，密码以明文形式提交，因此如果您不使用https，并且您的人员正在使用代理，则可以在那里获取密码。用户还可以在其浏览器中保存密码。

Answer 7

SQL注入流程仍然只是受用户名/密码墙的保护。

您必须记住，如果您不使用SSL，密码/用户名将在网络上以明文形式传递。这意味着如果任何人可以嗅到该流量，他们将获得用户名/密码。

此外，这并不能保护您免受在您的应用程序上尝试SQL注入的合法用户的攻击。你必须记住，大多数攻击来自内部。

我会是你，我会把密码作为快速修复，但是当你有机会时修复SQL注入/输入卫生问题。

Answer 8

.htaccess不会让您免于注射。

想象一下，当您的一个受信任的人在他的PC上感染病毒时。病毒窃取他的密码并将其交给黑客。黑客通过SQL注入登录并删除数据库。

即使没有发生这种情况，也总是逃避查询，因此用户可以安全地在查询中使用“'”之类的字符。

SELECT `name` FROM `table` WHERE `name` = 'pub 'cosa blanca''; --SQL error