html/XSS转义输入与输出 [英] html/XSS escape on input vs output

问题描述

从我所看到的所有内容看来，在用户输入的内容上转义html(以防止XSS的目的)的惯例似乎是在呈现内容时执行的.大多数模板语言似乎默认情况下都这样做，而且我遇到过类似

From everything I've seen, it seems like the convention for escaping html on user-entered content (for the purposes of preventing XSS) is to do it when rendering content. Most templating languages seem to do it by default, and I've come across things like this stackoverflow answer arguing that this logic is the job of the presentation layer.

所以我的问题是，为什么会这样?在我看来，逃脱输入(即表单或模型验证)看起来更干净，因此您可以基于以下原因在数据库中任何内容都可以安全显示的前提下工作:

So my question is, why is this the case? To me it seems cleaner to escape on input (i.e. form or model validation) so you can work under the assumption that anything in the database is safe to display on a page, for the following reasons:

1. 各种输出格式-对于现代Web应用程序，您可能会结合使用服务器端html渲染，使用ajax/JSON的javascript Web应用程序和接收JSON的移动应用程序(并且可能可能没有某些网络视图，可能是javascript应用程序或服务器渲染的html).因此，您必须处理到处都是html的转义.但是输入将始终在存储到db之前被实例化为模型(并经过验证)，并且您的模型都可以从同一个基类继承.

1. Variety of output formats - for a modern web app, you may be using a combination of server-side html rendering, a javascript web app using ajax/JSON, and mobile app that receives JSON (and which may or may not have some webviews, which may be javascript apps or server-rendered html). So you have to deal with html escaping all over the place. But input will always get instantiated as a model (and validated) before being saved to db, and your models can all inherit from the same base class.

您已经必须小心输入以防止代码注入攻击(当然，这通常抽象到ORM或db游标，但是仍然如此)，所以为什么不担心html在这里转义，您不必担心.不必担心与输出有关的任何安全性吗?

You already have to be careful about input to prevent code-injection attacks (granted this is usually abstracted to the ORM or db cursor, but still), so why not also worry about html escaping here so you don't have to worry about anything security-related on output?

我很想听听有关为什么首选在页面渲染上使用html转义的争论

I would love to hear the arguments as to why html escaping on page render is preferred

推荐答案

原始的误解

不要将输出的环境卫生与验证混淆.

The original misconception

Do not confuse sanitation of output with validation.

尽管<script>alert(1);</script>是一个完全有效的用户名，但在网站上显示该用户名之前，绝对必须对其进行转义.

While <script>alert(1);</script> is a perfectly valid username, it definitely must be escaped before showing on the website.

是的，存在诸如表示逻辑" 之类的东西，它与"域业务逻辑" 不相关.所说的表示逻辑是表示层所处理的.特别是View实例.在编写良好的MVC中，视图是成熟的对象(与RoR试图告诉您的内容相反)，在Web上下文中应用时，它们可以处理多个模板.

And yes, there is such a thing as "presentation logic", which is not related to "domain business logic". And said presentation logic is what presentation layer deals with. And the View instances in particular. In a well written MVC, Views are full-blown objects (contrary to what RoR would try to to tell you), which, when applied in web context, juggle multiple templates.

不同的输出格式应由不同的视图处理.控制HTML，XML，JSON和其他格式的规则和限制在每种情况下都是不同的.

Different output formats should be handled by different views. The rules and restrictions, which govern HTML, XML, JSON and other formats, are different in each case.

您始终需要存储原始输入(如果未使用准备好的语句，则应进行清理以避免输入)，因为某些时候可能需要对其进行编辑.

You always need to store the original input (sanitized to avoid injections, if you are not using prepared statements), because someone might need to edit it at some point.

存储原始和xss安全的公共"版本是浪费的.如果您想存储经过清理的输出，因为每次都需要花费太多资源来对其进行清理，那么您已经在惹恼了错误的树.在使用缓存而不是污染数据库的情况下就是这种情况.

And storing original and the xss-safe "public" version is waste. If you want to store sanitized output, because it takes too much resources to sanitize it each time, then you are already pissing at the wrong tree. This is a case, when you use cache, instead of polluting the database.

这篇关于html/XSS转义输入与输出的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！