众所周知，您不能信任用户输入。 如果这些输入未经过滤而使用，甚至可能会带来安全问题。 XSS 和 SQL 注入可能是由于使用未经过滤的用户输入（或可以由用户更改的输入）而产生的问题。
为了避免此类问题，您必须控制所有可能受外部资源影响的字符串。 Perl 通过“污点模式”来支持这一点。
我所知道的问题都是由操纵字符串引起的。 您是否知道由外部影响操纵的整数、浮点数等引起的安全问题的示例？ 或者这个数据类型可以被认为是安全的吗？
It's a well known truth, that you don't can trust user inputs. These inputs can be even an security-problem, if they are used unfiltered. XSS and SQL-injections are possible problems coming from using unfiltered user-input (or input, that can be changed by the user).
To avoid such problems, you have to control all strings, that can be influenced by external resources. Perl supports this with it's 'Taint-mode'.
The problems I know about, all are arising from manipulated Strings. Are you know examples of security-problems coming from ints, floats etc. manipulated by external influences? Or can this datatypes assumed to be safe?
发布评论
评论（4）
最终，所有值都会作为字符串传递到您的程序，无论您最终是否转换它们。 所有这些都应该被视为潜在有害，而不仅仅是因为这个原因。
例如，如果您在数字字段中放入非数字字符，则可能会出现解析错误。 如果您在意想不到的地方输入零，则可能会出现被零除的错误。 如果您输入的值比预期大得多，或者在未预期时输入负值，或者任何其他情况，您可能会收到某种错误。 系统错误很可能会泄露比您想要的更多的信息。 例如，在 ASP.NET 应用程序中，如果未打开自定义错误，则站点使用的数据库连接信息、物理路径信息或第三方库的信息可能会在默认错误消息中泄漏。
字符串可能比其他值更有可能出现问题，但所有用户输入都应被视为潜在有害。
Ultimately, all values are passed as strings to your program, whether you eventually convert them or not. All should be seen as potentially harmful, and not just for this reason.
For example, if you put non-numeric characters in a number field, you can get a parsing error. If you put a zero in where it isn't anticipated, you can get a divide by zero error. If you put a much larger value in than is expected, or a negative when not expected, or any number of other things, you can get an error of some sort. And it is quite possible for system errors to leak more information than you want. For instance, in an ASP.NET application, if custom errors aren't turned on, then database connection information, physical path information or information on third part libraries that your site uses can be leaked in the default error messages.
Strings are probably more likely to be problems than other values, but all user input should be treated as potentially harmful.
不，您可能会因接受外部来源的号码而产生安全问题。 如果外部源为您提供了需要处理的（例如）数组中的多个元素，则盲目信任的大量元素可能会通过分配足够的内存来导致速度减慢或内存耗尽，从而导致拒绝服务。 相反，如果您接受太低的数字并盲目地继续读取超出分配存储空间的元素，则可能会导致堆栈或堆覆盖。
No, you can have security problems arising from accepting numbers from an external source. If an external source gives you a number of elements in (say) an array that you will need to process, a large number, trusted blindly, can cause denial of service by allocating enough memory to cause slow-down or memory exhaustion. Conversely, if you accept too-low a number and blindly continue reading more elements than you've allocated storage for, you can cause stack or heap over-writes.
数据类型是否安全并不重要——而是底层的代码决定了这一点。
也就是说，字符串通常会由于缓冲区溢出或针对某些底层解释器（SQL 或某些脚本语言）的注入式攻击而导致问题。 显然，您不会从数字类型变量中看到此类问题。
可能发生的是与不良外部值相关的错误，这些错误可能导致拒绝服务攻击等攻击。
It's not the datatypes that would be safe or not -- it's the code underneath that determines this.
That said, strings generally cause problems because of either buffer overruns or injection-style attacks against some underlying interpreter (SQL or some scripting language). You won't see these kinds of problems from numeric-type variables, obviously.
What you can have happen are bugs relating to bad external values which could lend themselves to something like a denial-of-service attack.
您永远不应该信任任何跨越
信任边界的数据。如 ="nofollow noreferrer">Microsoft 安全开发生命周期 (SDL) 博客，扩展于作者：Larry Osterman 的系列 有关威胁建模的文章（已更新 此处）并由他的 再次进行威胁建模，展示 PlaySound 威胁模型帖子，任何数据跨越信任边界，您需要识别可能的威胁。
You should never trust any data that crosses a
trust boundary.As described in The New Threat Modeling Process on the Microsoft Security Development Lifecycle (SDL) Blog, expanded on by Larry Osterman's series of articles on threat modeling (updated here) and demonstrated by his Threat Modeling Again, Presenting the PlaySound Threat Model post, anywhere data crosses a trust boundary you need to identify the possible threats.