在 Web 开发过程中，我将有多少时间花在用户输入验证上? [英] What percentage of my time will be spent in user input verfication during web development?

问题描述

我是在网络上开发东西的新手.到目前为止，我花了很多时间(50% 左右)来尝试防止坏人将诸如 sql 注入之类的东西放入我的输入表单并在服务器端对其进行验证.这是正常的吗?

解决方案

@Jeremy - 一些 PHP 细节

当涉及到数据库查询时，总是尝试使用准备好的参数化查询.mysqli 和 PDO 库支持这一点.这比使用 mysql_real_escape_string 等转义函数要安全得多.

是的，mysql_real_escape_string 实际上只是一个字符串转义函数.它不是灵丹妙药.它所做的只是转义危险字符，以便在单个查询字符串中安全使用它们.但是，如果您不事先清理您的输入，那么您将容易受到某些攻击媒介的攻击.<​​/p>

想象以下 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 '<img src="' .htmlspecialchars($_GET['imagesrc']) .'"/>';

我们已经在一个 HTML 标签中，所以我们不需要 <或 > 做任何危险的事情.我们的攻击向量可能只是 javascript:alert(document.cookie)

现在生成的 HTML 看起来像

攻击直接通过.

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

echo "";

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

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

给我们

在这些情况下，没有灵丹妙药，您只需要自己清理输入即可.如果您尝试过滤掉坏字符，您肯定会失败.采取白名单方法，只让好的字符通过.查看 XSS 备忘单，了解向量的多样性示例

即使您在 HTML 标签之外使用 htmlspecialchars($string)，您仍然容易受到多字节字符集攻击向量的攻击.<​​/p>

最有效的方法是使用 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 使用率下降.

I'm new to developing things on the web. So far, I'm spending a lot of time (50% or so) to try and prevent bad people from putting things like sql injection into my input forms and validating it server side. Is this normal?

解决方案

@Jeremy - some PHP specifics

When it comes to database queries, always try and use prepared parameterised queries. The mysqli and PDO libraries support this. This is infinitely safer than using escaping functions such as mysql_real_escape_string.

Yes, mysql_real_escape_string is effectively just a string escaping function. It is not a magic bullet. All it will do is escape dangerous characters in order that they can be safe to use in a single query string. However, if you do not sanitise your inputs beforehand, then you will be vulnerable to certain attack vectors.

Imagine the following SQL:

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

You should be able to see that this is vulnerable to exploit.
Imagine the id parameter contained the common attack vector:

1 OR 1=1

There's no risky chars in their to encode, so it will pass straight through the escaping filter. Leaving us:

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

Which is a lovely SQL injection vector.

Whilst these functions are useful, they must be used with care. You need to ensure that all web inputs are validated to some degree. In this case, we see that we can be exploited because we didn't check that a variable we were using as a number, was actually numeric. In PHP you should widely use a set of functions to check that inputs are integers, floats, alphanumeric etc. But when it comes to SQL, heed most the value of the prepared statement. The above code would have been secure if it was a prepared statement as the database functions would have known that 1 OR 1=1 is not a valid literal.

As for htmlspecialchars(). That's a minefield of its own.

There's a real problem in PHP in that it has a whole selection of different html-related escaping functions, and no clear guidance on exactly which functions do what.

Firstly, if you are inside an HTML tag, you are in real trouble. Look at

echo '<img src= "' . htmlspecialchars($_GET['imagesrc']) . '" />';

We're already inside an HTML tag, so we don't need < or > to do anything dangerous. Our attack vector could just be javascript:alert(document.cookie)

Now resultant HTML looks like

<img src= "javascript:alert(document.cookie)" />

The attack gets straight through.

It gets worse. Why? because htmlspecialchars only encodes double quotes and not single. So if we had

echo "<img src= '" . htmlspecialchars($_GET['imagesrc']) . ". />";

Our evil attacker can now inject whole new parameters

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

gives us

<img src='pic.png' onclick='location.href=xxx' onmouseover='...' />

In these cases, there is no magic bullet, you just have to santise the input yourself. If you try and filter out bad characters you will surely fail. Take a whitelist approach and only let through the chars which are good. Look at the XSS cheat sheet for examples on how diverse vectors can be

Even if you use htmlspecialchars($string) outside of HTML tags, you are still vulnerable to multi-byte charset attack vectors.

The most effective you can be is to use the a combination of mb_convert_encoding and htmlentities as follows.

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

Even this leaves IE6 vulnerable, because of the way it handles UTF. However, you could fall back to a more limited encoding, such as ISO-8859-1, until IE6 usage drops off.

这篇关于在 Web 开发过程中，我将有多少时间花在用户输入验证上?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！