使用“new Function(…)”的安全注意事项(在渲染期间,来自我的Javascript源的表达式)
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了使用“new Function(…)”的安全注意事项(在渲染期间,来自我的Javascript源的表达式)，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1741字，纯文字阅读大概需要3分钟。
内容图文
我想使用新的函数(…)从非常简化的代码生成函数.我想这样做
>避免自己解析表达式
>尽可能灵活.
我尽可能避免使用eval().但是我不确定它是否足够安全以使用新功能(…),这也被称为易受安全漏洞影响.
背景
我想管理菜单按钮的状态.所以,在定义按钮时,我想写一些类似的东西
{
..., // More button definition
state: "isInEditmode && (isWidgetSelected || isCursorInWidget),
...
}
在几个事件期间处理状态转换时,我将检查(汇总)当前整体状态对象的状态与状态属性中的状态.
所以我会在渲染过程中生成一个Function并将其作为DOM对象属性附加,而不是以这种方式附加DOM属性：
...
$el.stateFn = new Function("stateObj", "with (stateObj) {return " + item.state + ";}");
...
测试状态：
visible = $el.stateFn.call(currentStates, currentStates);
with语句帮助我将当前状态对象的属性作为变量提供,以便上面的表达式不需要像obj.isInEditmode那样的东西.
安全问题
在我看来,这不会引入安全漏洞,因为附加到DOM对象的函数是在渲染时生成并从源读取的.还是我错了？我应该避免这个吗？
性能提示受到赞赏(评论)(我认为只要我在渲染时评估一个新的函数,这是可以接受的).
编辑1
>我正在使用Backbone.js.使用另一个框架是不可能的.
>某些菜单项需要绑定到不同甚至多个模型.
>委托(或门面/代理？)模型是相当可观的.
解决方法:
如果允许用户输入在代码中突破,那么安全性也同样糟糕.但是,维护方面,当本地eval与您的示波器混淆并导致动态范围时,您不必担心隐藏的错误.
性能方面,新函数生成的函数与任何其他函数完全相同.生成速度较慢,但??在eval中它不会导致包含范围不可优化.
事实上,新功能可用于改善以下情况下的性能：
//Will behave like function a( obj ) { return obj.something }
function makePropReader( propName ) {
return new Function( "obj", "return obj." + propName );
}
构造函数will perform better比这里返回的函数：
function makePropReader( propName ) {
return function( obj ) {
return obj[propName];
}
}
由于必须从闭包上下文动态读取propName,并在每次调用时对对象执行动态读取.
内容总结
以上是互联网集市为您收集整理的使用“new Function(…)”的安全注意事项(在渲染期间,来自我的Javascript源的表达式)全部内容，希望文章能够帮你解决使用“new Function(…)”的安全注意事项(在渲染期间,来自我的Javascript源的表达式)所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。