如果使用下拉菜单，是否必须防止SQL注入？

我知道您绝不应该信任表单中的用户输入，这主要是由于SQL注入的机会。

但是，这是否也适用于唯一输入来自下拉菜单的表单（请参见下文）？

我将其保存$_POST['size']到一个Session中，然后在整个站点中使用它来查询各种数据库（使用mysqliSelect查询），任何SQL注入肯定会损害（可能会删除）它们。

没有类型输入的用户输入可以查询数据库的区域，只有下拉列表。

<form action="welcome.php" method="post">
<select name="size">
  <option value="All">Select Size</option> 
  <option value="Large">Large</option>
  <option value="Medium">Medium</option>
  <option value="Small">Small</option>
</select>
<input type="submit">
</form>

您可以像以下示例一样简单地进行操作，以确保发布的大小符合您的期望。

$possibleOptions = array('All', 'Large', 'Medium', 'Small');

if(in_array($_POST['size'], $possibleOptions)) {
    // Expected
} else {
    // Not Expected
}

如果要使用的PHP> = 5.3.0版本，请使用mysqli_ *来保存结果。如果正确使用，这将有助于sql注入。

是的，您需要对此加以保护。

让我向您展示为什么使用Firefox的开发者控制台：

如果不清除此数据，则数据库将被破坏。（这可能不是一个完全有效的SQL语句，但我希望我已经明白了。）

仅仅因为您限制了下拉菜单中的可用选项，并不意味着您就限制了我可以发送给服务器的数据。

如果您试图在页面上进一步限制使用行为，那么我的选择包括禁用该行为，或者只是向服务器编写自定义HTTP请求，以模仿该表单提交。确实有一个叫做curl的工具，我认为无论如何要提交此SQL注入的命令如下所示：

curl --data "size=%27%29%3B%20DROP%20TABLE%20*%3B%20--"  http://www.example.com/profile/save

（这可能不是完全有效的curl命令，但是我希望我已经明白了。）

因此，我重申：

永远不要相信用户输入。始终保护自己。

不要以为任何用户输入都是安全的。即使通过表格以外的其他方式到达，也可能是不安全的。没有哪一个值得信赖，以至于不能保护自己免受SQL注入。

由于这个问题被标记为 sql注入，这是有关这种特殊攻击的答案：

正如您在评论中所告知的那样，您必须对涉及任何变量数据的每个查询使用准备好的语句，没有例外。

无论任何HTML内容！
必须理解，无论任何外部因素，无论是HTML输入还是其他任何因素，SQL查询都必须正确设置格式。

尽管您可以将其他答案中建议的白名单用于输入验证目的，但它不应影响任何与SQL相关的操作 -无论您是否验证HTML输入，它们都必须保持不变。这意味着在向查询中添加任何变量时，仍然必须使用准备好的语句。

在这里，您可能会找到详尽的解释，为何必须准备好的语句，如何正确使用它们以及在哪些情况下不适合使用它们以及在这种情况下应采取的措施：《 Hitchhiker SQL注入保护指南》

另外，这个问题被标记为 mysqli。我想大多数情况是偶然的，但是无论如何，我必须警告您，原始mysqli 不足以替代旧的mysq_ *函数。仅仅是因为如果以旧样式使用，它根本不会增加安全性。尽管对准备好的语句的支持是痛苦且麻烦的，但以至于普通的PHP用户根本无法使用它们。因此，如果没有ORM或某种抽象库可供选择，那么PDO是您唯一的选择。

是。

任何人都可以欺骗任何实际发送的值-

因此，对于验证下拉菜单，您只需检查以确保您正在使用的值在下拉菜单中-像这样的方式将是最好的（最疯狂的偏执）方式：

if(in_array($_POST['ddMenu'], $dropDownValues){

    $valueYouUseLaterInPDO = $dropDownValues[array_search("two", $arr)];

} else {

    die("effin h4x0rs! Keep off my LAMP!!"); 

}

防止用户使用控制台更改下拉菜单的一种方法是仅在其中使用整数值。然后，您可以验证POST值是否包含整数，并在需要时使用数组将其转换为文本。例如：

<?php
// No, you don't need to specify the numbers in the array but as we're using them I always find having them visually there helpful.
$sizes = array(0 => 'All', 1 => 'Large', 2 => 'Medium', 3 => 'Small');
$size = filter_input(INPUT_POST, "size", FILTER_VALIDATE_INT);

echo '<select name="size">';
foreach($sizes as $i => $s) {
    echo '<option value="' . $i . '"' . ($i == $size ? ' selected' : '') . '>' . $s . '</option>';
}
echo '</select>';

然后，您就可以$size在查询中使用，知道它只会包含FALSE一个或一个整数。

其他答案已经涵盖了您需要知道的内容。但也许有助于澄清更多信息：

有两件事情你需要做的：

1.验证表单数据。

正如乔纳森·霍布斯（Jonathan Hobbs）的答案非常清楚地表明，为表单输入选择html元素不会为您做任何可靠的过滤。

验证通常以不会更改数据的方式进行，但是会再次显示该表单，其字段标记为“请更正此”。

大多数框架和CMS都有表单构建器来帮助您完成此任务。不仅如此，它们还有助于抵御CSRF（或“ XSRF”），这是另一种攻击形式。

2.在SQL语句中清理/转义变量。

..或让准备好的语句为您完成工作。

如果使用任何用户提供或不提供的变量构建（My）SQL语句，则需要转义并引用这些变量。

通常，您插入MySQL语句中的任何此类变量应为字符串，或者PHP可以可靠地转换为MySQL可以消化的字符串。如数字。

对于字符串，然后需要选择几种方法中的一种来对字符串进行转义，也就是说，替换在MySQL中可能产生副作用的任何字符。

• 在老式的MySQL + PHP中，mysql_real_escape_string（）可以完成这项工作。问题在于它太容易忘记了，因此您绝对应该使用准备好的语句或查询构建器。
• 在MySQLi中，您可以使用准备好的语句。
• 大多数框架和CMS提供查询构建器，以帮助您完成此任务。

如果要处理数字，则可以省略转义和引号（这就是准备好的语句允许指定类型的原因）。

重要的是要指出，您对SQL语句而不是数据库本身对变量进行了转义。数据库将存储原始字符串，但是该语句需要转义的版本。

如果您忽略其中之一，该怎么办？

如果您不使用表单验证，但是确实对SQL输入进行了清理，则可能会看到各种不良情况，但是您不会看到SQL注入！（*）

首先，它可以使您的应用程序进入您未计划的状态。例如，如果您要计算所有用户的平均年龄，但是一个用户输入了“ aljkdfaqer”作为年龄，则计算将失败。

其次，您可能需要考虑各种其他注入式攻击：例如，用户输入可能包含javascript或其他内容。

数据库仍然存在问题：例如，如果字段（数据库表列）限制为255个字符，并且字符串比该字符串长。或者，如果该字段仅接受数字，而您尝试保存一个非数字字符串。但这不是“注入”，而只是“崩溃应用程序”。

但是，即使您有一个自由文本字段，该字段允许所有输入都完全不进行验证，但如果在处理数据库语句时正确地将其转义，则仍然可以将其保存到数据库中。当您想在某个地方使用此字符串时，问题就来了。

（*），否则这将是真正的异国情调。

如果您没有为SQL语句转义变量，但是您确实验证了表单输入，那么您仍然可以看到不良情况的发生。

首先，您冒着将数据保存到数据库中并再次加载时的风险，即不再是相同的数据，即“翻译丢失”。

其次，它可能导致无效的SQL语句，从而使您的应用程序崩溃。例如，如果任何变量包含引号或双引号字符，则取决于您使用哪种引号类型，您将获得无效的MySQL语句。

第三，它仍然可能导致SQL注入。

如果您已经过滤/验证了来自表单的用户输入，则如果将您的输入简化为选项的硬编码列表，或者将其限制为数字，则可能不太可能进行故意的 SQl注入。但是，如果您没有正确地转义SQL语句中的变量，则任何自由文本输入都可以用于SQL注入。

即使根本没有任何形式的输入，您仍然可以从各种来源获得字符串：从文件系统读取，从Internet抓取等。没有人可以保证这些字符串是安全的。

您的Web浏览器不“知道”它正在接收来自php的页面，它看到的只是html。而http层所知道的甚至不止于此。您需要能够处理几乎可以跨越http层的任何类型的输入（幸运的是，大多数输入php已经给出了错误）。如果您试图防止恶意请求破坏您的数据库，则需要假定另一端的人知道他在做什么，并且他不限于在正常情况下在浏览器中可以看到的内容（更不用说您可以用浏览器的开发人员工具弄些什么了。因此，是的，您需要满足下拉菜单中的所有输入，但是对于大多数输入，您可能会出错。

您已将用户限制为仅使用特定下拉列表中的值这一事实是无关紧要的。技术用户可以捕获发送到服务器的http请求，然后再离开服务器，使用本地代理服务器之类的工具对其进行更改，然后继续进行。使用更改后的请求，他们可以发送不是您在下拉列表中指定的参数值。开发人员必须具有这样的心态：客户端限制通常是没有意义的，因为客户端上的任何内容都可以更改。客户端数据输入的每个点都需要服务器验证。攻击者在这唯一方面依赖开发人员的天真。

最好使用参数化查询，以确保防止SQL注入。在这种情况下，查询的外观将是这样的：

SELECT * FROM table WHERE size = ?

当您提供上述查询的文本未经完整性验证（输入未在服务器上经过验证）且包含SQL注入代码时，将被正确处理。换句话说，该请求将导致在数据库层中发生类似的事情：

SELECT * FROM table WHERE size = 'DROP table;'

这将简单地选择0结果作为返回值，这将使查询在实际上对数据库造成损害时无效，而无需白名单，验证检查或其他技术。请注意，负责任的程序员将进行分层的安全性，并且除了参数化查询外，还将经常进行验证。但是，从性能的角度来看，几乎没有理由不对您的查询进行参数化，并且这种做法所增加的安全性是使您熟悉参数化查询的一个很好的理由。

表单中提交的所有内容都会以文本形式发送到您的服务器。并没有阻止任何人创建机器人来模仿客户端或在终端机中键入（如果他们愿意的话）的机器人。永远不要以为，因为您对客户端进行了编程，所以它将像您认为的那样运行。这真的很容易欺骗。

当您信任客户时会发生什么事的示例。

通过使用Telnet发送请求，黑客可以完全绕过浏览器，包括Java脚本形式检查。当然，他将查看您html页面的代码以获取他必须使用的字段名称，但是从那时起，这对他来说就是“一切”。因此，您必须检查服务器上提交的所有值，就像它们不是源自html页面一样。