如果从外部源获取,除字符串之外的其他数据类型是否可能有害?

时间:2009-03-30 14:55:03

标签: security string types code-injection

众所周知,您不能信任用户输入。如果未经过滤使用,这些输入甚至可能是安全问题。 XSS和SQL注入可能是来自使用未经过滤的用户输入(或输入,可由用户更改)的问题。

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

我所知道的问题都来自于被操纵的字符串。您是否知道来自外部影响操纵的整数,浮动等安全问题的例子?或者这种数据类型是否可以安全?

4 个答案:

答案 0 :(得分:4)

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

例如,如果在数字字段中放入非数字字符,则可能会出现解析错误。如果将零置于未预期的位置,则可以得到除零误差。如果你输入的值比预期的大得多,或者在不期望值或其他任何数量的情况下显示负值,则可能会出现某种错误。并且系统错误很可能泄漏超出您想要的信息。例如,在ASP.NET应用程序中,如果未打开自定义错误,则可以在默认错误消息中泄漏数据库连接信息,物理路径信息或站点使用的第三方库信息。

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

答案 1 :(得分:1)

不,您可以通过接受来自外部来源的号码而产生安全问题。如果外部源为您提供了一些您需要处理的数组中的元素,那么盲目信任的大量元素会通过分配足够的内存来导致缓慢或内存耗尽而导致拒绝服务。相反,如果您接受的数字太低而且盲目地继续读取比分配存储空间更多的元素,则可能导致堆栈或堆重写。

答案 2 :(得分:1)

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

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

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

答案 3 :(得分:1)

您绝不应相信任何跨越trust boundary的数据。

  

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

     

Threat Modeling, once again - 拉里奥斯特曼

正如The New Threat Modeling Process Microsoft Security Development Lifecycle (SDL)上的Blog所述,由Larry Osterman series of articles在威胁建模方面进行了扩展(更新{ {3}})并且由他的here证明,任何数据都跨越信任边界,您需要识别可能的威胁。