当向网页添加用户输入时,它应该(除非它的HTML当然是:)被编码以帮助防止XSS攻击等。像这样:
litForename.Text = HttpUtility.HtmlEncode(MyUser.Forename);
我正在组建一个模板来生成我的业务逻辑层,我想在数据从数据库出来之前使用它来完成所有编码,然后再进入UI代码。这将确保所有内容都应编码(我显然会排除包含Xhtml / Xml字符串的列)。数据访问方法的重载将允许在没有编码的情况下检索数据(因此可以对其进行编辑):
// Get a 'User' entity with all the string fields HTML encoded
BLL.Users.GetById(int userId)
// Get a 'User' entity with optional HTML encoding
BLL.Users.GetById(int userId, bool useHtmlEncoding)
这是其他人使用的方法,还是一个愚蠢的想法?有什么优点和缺点?
感谢。
答案 0 :(得分:3)
可能有边缘情况,这是有道理的,但总的来说,我会建议反对这一点。您的业务逻辑层应仅处理业务逻辑和业务逻辑。
同样,您的控制器(假设ASP.NET MVC)应该处理在业务域上下文中有意义的值,而不是在预期特定类型的UI时已经改变的值。
您的UI图层是唯一应该知道并关心它是什么类型的UI的图层。目前看来,您唯一的UI类型将基于HTML,但可能会发生变化。
答案 1 :(得分:1)
对保存到数据库的数据使用HtmlEncode
的问题是,您必须在数据中处理&
和"
之类的内容。例如,“Tom O'Brien”将作为“Tom O "
Brien”保存到数据库中。对此进行选择或更新将会非常棘手。
我认为只使用HtmlEncode
在UI中显示文字,你会做得更好。
答案 2 :(得分:1)
您的业务逻辑真的不应该知道您的演示文稿。无论您是在提供网络,窗口还是任何其他类型的UI,您都不应该在业务逻辑中包含这些细节。
您是否认为使用您的业务层的人可能会尝试在您的编码之上再次对数据进行编码?这可能会导致事情看起来非常混乱。
答案 3 :(得分:0)
我同意视图级数据转换属于视图生成的其他海报。您可能只从基于XML的视图开始(例如,XHTML,用于语音浏览的VoiceXML,用于Web服务的XML),但是当您决定还需要JSON视图来支持AJAX交互时会发生什么? JSON Javascript文字使用与XML不同的转义机制。
您还会遇到一种情况,其中一个逻辑层方法需要为了与视图生成无关的目的而调用另一个逻辑层方法。也许调用方法需要应用一些填充另一个数据库表的批量数据转换。在这种情况下,调用方法必须撤消XML转义。
答案 4 :(得分:0)
学习PHP的magic_quotes_gpc
功能的经验教训:这样的编码无疑只会让事情更加混乱,导致你不应该忘记,忘记在你应该的时候逃避,并且通常是一种痛苦。在将数据发送到需要的地方之前,不要对数据进行编码,无论是数据库,Web还是其他地方。