HTML:我应该编码大于还是不编码? (>>)

发布于 2024-12-29 06:24:21 字数 476 浏览 1 评论 0原文

当编码可能不安全的数据时,是否有理由编码 >

  • 无论哪种方式,它都会验证
  • 浏览器对这两种方式的解释都是相同的(在 attr="data"attr='data'data的情况下) ;

我认为有人这样做的原因是

  • 为了简化基于正则表达式的标签删除。 <[^>]+>?(罕见)
  • 非引号字符串attr=data:-o(没有发生!)
  • 代码中的美感。 (那又怎样?)

我错过了什么吗?

When encoding possibly unsafe data, is there a reason to encode >?

  • It validates either way.
  • The browser interprets the same either way, (In the cases of attr="data", attr='data', <tag>data</tag>)

I think the reasons somebody would do this are

  • To simplify regex based tag removal. <[^>]+>? (rare)
  • Non-quoted strings attr=data. :-o (not happening!)
  • Aesthetics in the code. (so what?)

Am I missing anything?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

北笙凉宸 2025-01-05 06:24:21

严格来说,要防止 HTML 注入,只需将 < 编码为 < 即可。

如果要将用户输入放入属性中,请将 " 编码为 "

如果您正确执行操作并使用正确引用的属性,则不需要不必担心 > 但是,如果您不确定这一点,您应该对其进行编码,以确保安心 - 它不会造成任何损害。

Strictly speaking, to prevent HTML injection, you need only encode < as <.

If user input is going to be put in an attribute, also encode " as ".

If you're doing things right and using properly quoted attributes, you don't need to worry about >. However, if you're not certain of this you should encode it just for peace of mind - it won't do any harm.

铁憨憨 2025-01-05 06:24:21

HTML4 规范在其第 5.3.2 节中表示

作者应在文本中使用“>”(ASCII 十进制 62)而不是“>”

所以我相信您应该将较大的>符号编码为>(因为您应该遵守标准)。

The HTML4 specification in its section 5.3.2 says that

authors should use ">" (ASCII decimal 62) in text instead of ">"

so I believe you should encode the greater > sign as > (because you should obey the standards).

往事风中埋 2025-01-05 06:24:21

当前浏览器的 HTML 解析器对 uquoted > 没有问题

,但是不幸的是,使用正则表达式来 " 解析" JS 中的 HTML 非常常见。 (示例:Ext .util.Format.stripTags)。另外,写得不好的命令行工具、IDE 或 Java 类等可能不够复杂,无法确定开始标记的限制器。

因此,您可能会遇到这样的代码问题:(

<script data-usercontent=">malicious();//"></script>

请注意语法突出显示如何处理此代码段!)

Current browsers' HTML parsers have no problems with uquoted >s

However, unfortunately, using regular expressions to "parse" HTML in JS is pretty common. (example: Ext.util.Format.stripTags). Also poorly written command line tools, IDEs, or Java classes etc. may not be sophisticated enough to determine the limiter of an opening tag.

So, you may run into problems with code like this:

<script data-usercontent=">malicious();//"></script>

(Note how the syntax highlighter treats this snippet!)

夜雨飘雪 2025-01-05 06:24:21

始终

这是为了防止 XSS 注入(通过用户使用您的任何表单提交原始 HTML或 JavaScript)。通过转义输出,浏览器知道不解析或执行任何内容 - 只将其显示为文本。

如果您不处理基于用户输入的动态输出,这可能感觉不是什么问题,但至少理解这一点很重要,即使不是养成一个好习惯。

Always

This is to prevent XSS injections (through users using any of your forms to submit raw HTML or javascript). By escaping your output, the browser knows not to parse or execute any of it - only display it as text.

This may feel like less of an issue if you're not dealing with dynamic output based on user input, however it's important to at least understand, if not to make a good habit.

坐在坟头思考人生 2025-01-05 06:24:21

是的,因为如果未对符号进行编码,则可能会在表单、社交媒体和许多其他媒体上进行 xss,因为攻击者可以使用

Yes, because if signs were not encoded, this allows xss on forms social media and many other because a attacker can use <script> tag. If you parse the signs the browser would not execute it but instead show the sign.

久光 2025-01-05 06:24:21

对 html 字符进行编码始终是一项微妙的工作。 您应该始终对需要编码的内容进行编码并始终使用标准。使用双引号是标准的,甚至双引号内的引号也应该进行编码。始终编​​码。想象一下这样的事情

<div> this is my text an img></div>

可能是 img>将从浏览器解析为图像标签。浏览器总是尝试解析未封闭的标签或引号。正如巴塞尔所说,使用标准,否则您可能会在不了解错误来源的情况下得到意想不到的结果。

Encoding html chars is always a delicate job. You should always encode what needs to be encoded and always use standards. Using double quotes is standard, and even quotes inside double quotes should be encoded. ENCODE always. Imagine something like this

<div> this is my text an img></div>

Probably the img> will be parsed from the browser as an image tag. Browsers always try to resolve unclosed tags or quotes. As basile says use standards, otherwise you could have unexpected results without understanding the source of errors.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文