3

这是一个众所周知的事实,您不能信任用户输入。如果这些输入未经过滤使用,它们甚至可能是一个安全问题。XSS 和 SQL 注入是使用未经过滤的用户输入(或输入,可以由用户更改)可能出现的问题。

为避免此类问题,您必须控制所有可能受外部资源影响的字符串。Perl 通过它的 'Taint-mode' 支持这一点。

我所知道的问题都是由操纵的字符串引起的。你知道来自外部影响操纵的整数、浮点数等安全问题的例子吗?或者可以假设这种数据类型是安全的吗?

4

4 回答 4

4

最终,无论您最终是否转换它们,所有值都作为字符串传递给您的程序。所有这些都应该被视为潜在的有害因素,而不仅仅是这个原因。

例如,如果将非数字字符放在数字字段中,则会出现解析错误。如果你在没有预料到的地方放了一个零,你可能会得到除以零的错误。如果您输入的值比预期的要大得多,或者在未预期的情况下输入负数,或者其他任何数量的东西,您可能会得到某种错误。系统错误很可能会泄露比您想要的更多的信息。例如,在 ASP.NET 应用程序中,如果未打开自定义错误,则您的站点使用的数据库连接信息、物理路径信息或有关第三方库的信息可能会在默认错误消息中泄露。

字符串可能比其他值更容易出现问题,但所有用户输入都应该被视为潜在有害的。

于 2009-03-30T15:08:18.310 回答
1

不,您可能会因接受来自外部来源的号码而遇到安全问题。如果外部源在(比如说)一个数组中为您提供了您需要处理的许多元素,那么大量、盲目信任的元素可能会通过分配足够的内存导致速度减慢或内存耗尽而导致拒绝服务。相反,如果您接受过低的数字并盲目地继续读取比分配存储空间更多的元素,则可能导致堆栈或堆覆盖。

于 2009-03-30T15:09:06.560 回答
1

安全与否的不是数据类型——而是下面的代码决定了这一点。

也就是说,字符串通常会由于缓冲区溢出或针对某些底层解释器(SQL 或某些脚本语言)的注入式攻击而引起问题。显然,您不会从数字类型变量中看到这类问题。

可能会发生与不良外部值相关的错误,这些错误可能会导致诸如拒绝服务攻击之类的事情。

于 2009-03-30T15:09:06.653 回答
1

你永远不应该相信任何跨越trust boundary.

当一个组件不信任边界另一侧的组件时,就会出现信任边界。运行在不同特权级别的元素之间总是存在信任边界,但有时运行在相同特权级别的不同组件之间存在信任边界。

威胁建模,再一次- 拉里奥斯特曼

Microsoft 安全开发生命周期 (SDL)博客上的新威胁建模过程中所述,Larry Osterman关于威胁建模的系列文章(在此处更新)进行了扩展,并通过他的威胁建模再次演示,展示 PlaySound 威胁模型帖子,任何地方数据跨越了识别可能威胁所需的信任边界。

于 2009-03-30T17:32:55.527 回答