在数据库中保存用户创建的javascript是否安全？
我正在开发一个代码游戏类型的应用程序，用户（web开发人员/设计师）可以输入HTML，CSS和Javascript并在iframe上查看结果。输入的代码将被保存在数据库（MySQL）中，并在show_results视图/操作中的iframe中再次呈现。在数据库中保存用户创建的javascript是否安全？
现在的问题：是否安全地直接在数据库中保存javascripts？如果不是，那么我应该如何保存它？
只要您在SQL语句中插入值时正确地转义某些字符，它就是安全的。例如，如果你的JavaScript代码：
var foo = 'hello world';
然后，你将不得不生成SQL语句时逃跑的单引号：
INSERT INTO snippets (code) VALUES ('var foo = ''hello world'';')
在上面的语句中，两个单引号（“”）是用单引号括起来的字符串中表示单引号的方式。
参见转义字符，以获得更多的信息链接： http://dev.mysql.com/doc/refman/5.0/en/string-literals.html
编辑
斯蒂芬p正确地指出，如果你使用准备好的语句在服务器端代码，然后框架下的引擎盖将替换你的那些角色。
如果您使用Prepared Statements，则您**不必**免于引号或其他任何内容。你应该这样做。总是。 – 2014-09-19 18:26:26
当然，但我只是展示了一个“原始”的例子。 – Claudix 2014-09-19 18:27:00
好的编辑@Claudix - 我指出了这一点，因为我有一个要求，我需要存储，确切地说，_anything_的用户类型英寸，因此，我逃避字符，当我从数据库中检索他们，并逃避他们取决于他们是什么用于 - HTML，JS，XML等 – 2014-09-19 18:33:57
数据库不会是你的问题在这里。使用预准备语句来允许将各种字符安全地存储在数据库中是相当简单的。使用除准备语句之外的任何内容来存储用户输入是不够的，并且基本上从未被推荐
但你说的是允许任意的javascript被执行，这总是会成为一个安全问题。正如上面的评论者所暗示的那样，您将会复制jsfiddle.net的复杂性，而没有安全体验，开发知识或明确希望修补不断出现的漏洞。
当然，你应该知道你在做什么会完全危害你设置的任何域，所以基本上这个JavaScript应该只写在你不使用的一次性域或子域上为任何其他目的。当然，在这样的环境下，这只是微不足道的，只需简单地构建帧并将观看者从托管该帧的站点拉出即可。
我敢肯定，这只是抓住了潜在滥用的表面，即任意JavaScript执行（又名有意的自我跨站点脚本）会带来它。
既然你基本上正在用这个概念重新发明一个非常危险的车轮，为什么不简单地使用一些已经存在的嵌入服务呢？例如，codepen.io允许你嵌入它的片段。
我正在构建一个应用程序，该应用程序使用“代码游乐场应用程序”背后的技术规定，用于完全不同的目的。 Codepen和CSSdeck非常棒，我同意你的观点。我愿意接受潜在的XSS攻击，并对其进行修补，并继续在我的项目中学习。如果你可以建议我写作，最佳实践和地方开始/参考？提前致谢！ – marvindanig 2014-09-19 19:15:11
那么，你在说什么（除了使用预处理语句之后不会过于复杂的保存方面），所有客户端都是这样，所以只需复制jsfiddle或codepen或cssdeck，以最接近您实际需要的为准，并从那里完善。只要确保检查它的服务器标题，并尝试复制那些看起来很有必要的东西。祝你好运。 – Kzqai 2014-09-21 14:13:42
是的，如果您在客户端执行javascript，则它作为架构决策是安全的。
在任何网站上，您都可以使用诸如chrome的“检查元素”等工具来操作客户端上的html，javascript等。您的系统不能假定客户端上的项目未被操纵。这就是为什么服务器端验证仍然如此重要。
我完全不同意kzqai。 如果是这样的话，那么小提琴手就会陷入严重的困境。
存在潜在的问题，可以更容易地暴露与你在做什么，但这些问题已经存在，只是晦涩难懂。
IFF你在服务器端执行javascript，这是一个非常复杂的决定。如果可能的话，我会亲自避免它，因为你玩的游戏是你能够抓住每一个可能的场景来解决麻烦，而一个坏人能够抓住你没有的那个。
你基本上说在服务器端执行javascript时要非常小心，因为这是一个非常复杂的决定，但后来说在客户端执行它就好，完全没有问题。唯一的区别是谁受伤。服务器端它是你的服务器，客户端是你的用户。如果您认为jsfiddle是开发人员完全可以“设置并忘记它”的事情，而不必为了客户端而不断修补新的攻击途径，那么您只是不知道持续的攻击的新客户端漏洞。 – Kzqai 2014-09-21 14:17:31
情况并非如此。 我同意客户端JavaScript可能会导致问题。但是，您永远不能相信Web环境中的任何类型的javascript都不会在客户端执行。事实上，你必须承担相反的事情。例如，可以说未来会出现新的威胁。威胁被利用与客户端下面的JavaScript代码： 功能beBad（）{ .. } 你不能说“嗯，我们是很好的，因为我们没有这样的代码”。相反，你必须说明并执行IT将被执行的事实。因此，您需要正确处理该威胁。 – vereecjw 2014-09-26 16:11:57
通过这种逻辑，允许任意的javascript被存储在数据库中并在客户端上执行本身不是安全威胁。 更具体的例子是： 假设数据可用IFF你有一个安全令牌。 每个用户都有自己的令牌。 您保存的JavaScript允许其他用户访问。 令牌允许访问的数据被认为是机密的（让我们只是说身份信息） 允许javascript访问该令牌显然是致命的，因为它们可以轻松捕获和传输令牌，从而授予访问权限。 – vereecjw 2014-09-26 16:12:33
将JS存储在任何数据库中是安全的。当您检索该JS并将其呈现为“