本地化消息中可能存在的安全风险
如果 Web 应用程序允许用户贡献翻译消息，以便将应用程序本地化为给定语言或区域设置，那么其中涉及的潜在安全风险是什么。 [除了明显的社会工程之外]
这些翻译消息通常是某种格式的键值对的集合，具体取决于语言/库等。例如，许多 OSS PHP 应用程序中的 PHP 数组文件、getetxt使用 gettext 的应用程序的 .po 文件、Rails 中的 Yaml 文件等。
然后，此类翻译数据用于在站点可用的区域设置列表中提供新的区域设置。
If a web application allows users to contribute translation messages in order to localize the application to a given language or locale, then what are the potential security risks involved in this. [Apart from social engineering which is an obvious one]
These translation messages are usually a collection of key-value pairs in some kind of format depending on the language/library etc. For example, PHP array files as in many OSS PHP applications, getetxt .po files for apps using gettext, Yaml files in Rails, and many others.
Such translation data is then used to provide a new locale in the list of locales available for a site.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一旦您放弃了对内容的控制，您实际上就允许任何“授权”内容提供商将他们想要的任何内容添加到您的 UI 中。即使您阻止执行内容中包含的潜在代码，也无法阻止向用户显示不适当的文本（或图像），除非您在系统的入口点屏蔽该文本。
解决这个问题的一种方法是通过与内容提供商签订服务合同，规定他们的内容验证义务。根据提供者是谁，这可能足以让您放心放弃控制权。否则，几乎没有什么可以替代人类，应用程序的所有者组织会在批准发布之前批准所有提交的内容。
As soon as you relinquish control of the content, you are effectively allowing any "authorized" content provider to add whatever they want to your UI. Even if you prevent execution of potential code included in the content, you cannot prevent display of inappropriate text (or images) to users unless you screen that text at its entry point into your system.
One way to address this is via service contracts with the content providers that specify their obligations for content verification. Depending on who the providers are, this may be enough to make you confortable with relinquishing control. Otherwise, there's pretty much no substitute for a human with the application's owner organization approving all submitted content before it is approved for publication.
老实说，这是一个奇怪的问题。我假设您已阅读并理解 OWASP Top 10。我假设您知道如何保护自己的服务器免受攻击。
话虽这么说，在我看来，针对此翻译系统的最明显的攻击是持久性 XSS，它允许攻击者使用此数据集来破坏每个网站。仅仅说“哦，我们对值进行 html 编码”是不够的。如果您将这些数据集提供给第三方，您不能指望他们都能正确清理数据。更糟糕的是，XSS 是输出问题，你不能HTML 编码整个数据集并期望它 100% 安全，因为你不知道数据是如何的将在 HTML 文档中使用。问题是数据可能最终出现在脚本标记或事件中，然后 html 编码的保护可能会完全失效。当我看到有人使用 strip_tags() 试图阻止时，我总是会笑xss，这是错误的做法。
总而言之，确实没有 100% 解决该问题的方法，但这可以防止大多数 xss：
显然，
rtrim()用于帮助防止脚本标记内的 xss。如果字符串以反斜杠结尾，您可以打破带引号的字符串，反斜杠与引号同样危险。To be honest this is kind of a strange question. I will assume that you have read and understand the OWASP top 10. I assume you know how to protect your own server from attack.
That being said in my mind the most obvious attack against this translation system is persistent XSS which would allow an attacker to deface every website using this dataset. Just saying "oah we htmlencode the values" isn't enough. If you are supplying these data sets to a 3rd party you can't expect all of them to sanitize the data properly. To make matters worse, XSS is an output problem, you can't HTML encode the entire data set and expect it to be 100% safe because you have no idea how the data is going to be used within the HTML document. The problem is the data may end up within a script tag or event, and then the protection from html-encoding could be nullified entirely. I always chuckle when I see someone using strip_tags() to try and stop xss, this is just the wrong approach.
In summation there really isn't a 100% solution to the problem, but this will prevent most xss:
Obviously the
rtrim()is used to help prevent xss within a script tag. If the string ends with a backslash you can break out of a quoted string, backslashes are equally as dangerous as quote marks.我认为可以肯定地说，“新”字符串中的 HTML 元素只能是旧字符串中的元素，减去一些特定属性，例如
title和alt。示例：
悬停此消息Hang hier met de muis boven- 将被标记为安全Hang hier met de muis boven将会被过滤器失效，但是您必须编写一个相当强大的过滤器，并且始终验证没有添加、删除任何属性，也没有添加或删除 HTML 元素。另外，请务必小心
"和'。I think it's safe to say that HTML elements in the "new" string can only be those that were in the old string, minus a few specific attributes such as
titleandalt.Example:
<strong title="Just a test">Hover this message</strong><strong title="Gewoon een test">Hang hier met de muis boven</strong>- will be marked as safe<strong onmouseover="window.location='something';">Hang hier met de muis boven</strong>will be invalidated by the filterYou would have to write a rather strong filter though, and always verify that no attributes were added, removed, and no HTML elements were added or removed. Also, always be careful with
"and'.