在Web开发期间,我在用户输入验证中花费的时间百分比是多少？

我刚开始在网上开发东西.到目前为止,我花了很多时间(50%左右)来尝试阻止坏人将sql注入等内容放入我的输入表单并验证服务器端.这是正常的吗？

@Jeremy - 一些PHP细节

在数据库查询方面,请始终尝试使用准备好的参数化查询.在mysqli和PDO库支持这一点.这比使用诸如mysql_real_escape_string之类的转义函数更安全.

是的,mysql_real_escape_string实际上只是一个字符串转义函数.它不是一个神奇的子弹.它所做的只是逃避危险的字符,以便在单个查询字符串中使用它们是安全的.但是,如果您事先没有对输入进行消毒,那么您将容易受到某些攻击媒介的攻击.

想象一下以下SQL:

$result = "SELECT fields FROM table WHERE id = ".mysql_real_escape_string($_POST['id']);

您应该能够看到这很容易被利用.
想象一下id参数包含常见的攻击向量:

1 OR 1=1

编码时没有冒险的字符,所以它会直接通过转义过滤器.离开我们:

SELECT fields FROM table WHERE id = 1 OR 1=1

这是一个可爱的SQL注入向量.

虽然这些功能很有用,但必须小心使用.您需要确保在某种程度上验证所有Web输入.在这种情况下,我们看到我们可以被利用,因为我们没有检查我们用作数字的变量,实际上是数字.在PHP中,您应该广泛使用一组函数来检查输入是整数,浮点数,字母数字等.但是当涉及到SQL时,请注意准备语句的大部分值.如果它是一个准备好的语句,上面的代码就是安全的,因为数据库函数已经知道了1 OR 1=1不是有效的文字.

至于htmlspecialchars().这是一个自己的雷区.

PHP中存在一个真正的问题,即它具有一系列与html相关的不同转义函数,并且没有明确指导哪些函数可以做什么.

首先,如果你在HTML标签内,你真的遇到了麻烦.看着

echo '';

我们已经在HTML标记内,因此我们不需要<或>做任何危险的事情.我们的攻击向量可能就是javascript:alert(document.cookie)

现在生成的HTML看起来像

攻击直接进行.

它变得更糟.为什么？因为htmlspecialchars只编码双引号而不是单引号.所以,如果我们有

echo "";

我们的邪恶攻击者现在可以注入全新的参数

pic.png' onclick='location.href=xxx' onmouseover='...

给我们

在这些情况下,没有灵丹妙药,你只需要自己调整输入.如果你试图过滤掉坏的角色,你肯定会失败.采取白名单的方法,只让通过好的字符.查看XSS备忘单,了解有关不同载体的示例

即使您在HTML标记之外使用htmlspecialchars($ string),您仍然容易受到多字节字符集攻击向量的攻击.

最有效的方法是使用mb_convert_encoding和htmlentities的组合,如下所示.

$str = mb_convert_encoding($str, ‘UTF-8?, ‘UTF-8?);
$str = htmlentities($str, ENT_QUOTES, ‘UTF-8?);

即使这样,IE6仍然容易受到攻击,因为它处理UTF的方式.但是,您可以回退到更有限的编码,例如ISO-8859-1,直到IE6使用率下降.

要防止SQL注入攻击,只需使用预准备语句进行查询(具体方法取决于您的平台).一旦你这样做,你将再也不必为这个特殊方面而烦恼.你只需要在任何地方使用它.

对于一般的输入验证,依靠公共基础来测试所需的字段,数字等总是好的.例如,ASP.Net的验证器非常容易使用.你应该遵循的一条经验法则是不要相信客户端(javascript)为你做这件事,因为它很容易解决它.始终先做服务器端.

当您允许引入可能包含html/javascript的丰富内容时,需要特别关注的一个特例是.这可能允许恶意用户在您的数据中注入javascript,这将触发您在呈现时无法控制的代码.千万不能尝试推出自己的验证代码.在网上搜索可以为您完成的免费,经过测试和修改的代码.杰夫在其中一个播客中有这方面的一些指示.

自动化输入验证代码后,执行此操作所花费的时间应与业务规则的复杂性直接相关.因此,作为一般规则:保持简单.