在用户提交的数据中，将& [英] Is there a security risk in leaving ampersands unescaped in user-submitted data?

问题描述

在显示用户生成/提交的信息时，是否有逃避其他特殊字符的安全风险，但不影响&符号？我想让我的用户自由地输入html实体，十六进制和十进制特殊字符，而不会对我的消毒剂增加不必要的复杂性。

解决方案

也就是说，输出/使用是重要的，而不是输入。

这一切都取决于最后使用数据。执行< input value =<？echo $ input？>对于任意输入，例如





现在一个<$ c $ c>& 通常比一些其他字符（例如'，， 或> ），但它可能会导致在某些情况下，某些工件（包括错误和未定义的行为），或者可能用于向URL添加额外的查询参数。

• ..但是如果在输出时URL不被编码合适，那么它不正确编码 ¹


• ..当然，如果一个& 被逐字写入XML / HTML流中，那么它不正确编码 ²


• ..如果程序以原始的& [从用户输入]传递给shell string-execute 那么它很有可能没有正确编码 ³


• ..这一切都归结为使用。

我倾向于不改变输入，除了使其符合业务规则，而这不包括上述案例！ （但是根本不能接受一个&符号可能是一个完全有效的商业规则。）

正确的转义（或者更好的是，不需要[手动]逃避）在适当的时候照顾其余的，并确保通过良好的编码使用，轻微的攻击或意外的失误被减轻。

实际上，我认为这种输入消毒表明对其他地方使用的方法/代码缺乏信任，并且可能会导致更多需要 / em>消毒。魔术引用任何人？

---

¹ 这是一个& 在用户输入中实际上可能会导致一种注入形式。想象一下：格式（http：// site / view = {0}，user_input），其中 user_input 1安培;购买= 1 。结果将是http：// site / view = 1& buy = 1。正确的方法是 URI编码（也称为Percent编码）的值，它将具有导致http：// site / view = 1％26buy％3D1。 （请注意，在正确编码的情况下只有一个查询参数，如果意图是允许原始输入被传递，则请仔细定义/分析允许的规则，并参见以下段落。 p>

² 虽然裸& 可以在HTML流用户输入中有效不应该被视为有效的HTML。也就是说，无论是定位XML还是HTML，都应该使用正确的输出/渲染转义机制。 （转义机制可能选择不编码裸& ，但这是次要关注。懒惰程序员将继续使用所有适用输出的相同的转义技术来获得一致，可靠和安全的输出。 / p>

³ 而不是使用一个shell-execute，它需要一个必须解析的参数字符串，在列表中使用exec-form的论据。后者通常防止产生一个shell和相关的shell-hack。而且，当然不要让用户手动指定可执行文件。

Is there any security risk in escaping other special characters but leaving ampersands untouched when displaying user-generated/submitted information? I'd like to let my user input html entities, hex, and decimal special characters freely without adding unnecessary complexity to my sanitizer.

解决方案

tldr; Leaving in ampersands (or other "special characters") is not a security issue if coded correctly. That is, the output/use is of importance, not the input.

It all depends on how the data is used in the end. Doing a <input value="<? echo $input ?>" /> is not correctly coded, for arbitrary input, for instance.

Now an & is often much less of a "problem" than some other characters (say ', ", < or >), but it could cause some artifacts (including errors and undefined behavior) in some situations, or perhaps be used for adding an extra query parameter to a URL

• .. but if the URL is not encoded as appropriate when output, then it's not correctly coded ¹
• .. and of course if a & is written verbatim into an XML/HTML stream, then it's not correctly coded ²
• .. and if the program is passing in raw & [from user input] to a "shell string-execute" then it's [very likely] not correctly coded ³
• .. it all comes down to use.

I tend to not alter the input, excepting to make it conform to business rules - and this does not include the above mentioned case! (But it may be a perfectly valid business rule to not accept an ampersand at all.)

Proper escaping (or, better yet, approaches that don't require [manual] escaping) at the appropriate times takes care of the rest and ensures that, through good coding of the usage, trivial attacks or accidental blunders are mitigated.

In fact, I would argue that this sort of "input sanitization" shows a lack of trust in the approaches/code used elsewhere and can lead to more problems with needing to undo the "sanitization". Magic quotes anyone?

---

¹ This is a case of where an & in the user input can actually cause a form of injection. Imagine: format("http://site/view={0}", user_input), where user_input contains 1&buy=1. The result will be "http://site/view=1&buy=1". The correct method is to URI-encode (aka Percent encode) the value, which would have resulted in "http://site/view=1%26buy%3D1". (Note that there is only one query parameter in the correctly coded case. If the intent is to be able to allow "raw" input to be passed through, then carefully define/analyze the permissible rules and see the following paragraph.)

² While a "bare" & can be valid in an HTML stream user input should not be relied upon as "being valid HTML". That is, regardless of targeting XML or HTML the correct output/rendering escaping mechanism should be used. (The escaping mechanism might choose to not encode "bare" &'s, but that is a secondary concern. The lazy programmer will continue to use the same escaping techniques for all applicable output to get consistent, reliable, and safe output.)

³ Instead of using a shell-execute that takes a single string of arguments that must be parsed, use an exec-form takes in a list of arguments. The latter [generally] prevents against spawning a shell and the associated shell-hacks. And, of course, never let the user manually specify the executable ..

这篇关于在用户提交的数据中，将&的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！