按以下方式使用 eval() 有哪些风险或责任

发布于 2024-09-26 21:15:27 字数 479 浏览 5 评论 0原文

我正在制作一款机器人游戏。用户创建一个机器人,然后将其与其他机器人一起放入战场。

我想让用户使用 JavaScript 来编写他们的机器人。我将提供许多函数供他们调用,但他们也可以构建自己的函数。 (有点)

迄今为止,我提出的唯一解决方案是使用 javascript eval() 函数来执行用户编写的代码。

我想知道两件事:

  1. 有人有任何仍然允许用户用 javascript 编写的替代建议实现吗?

  2. 用户可以利用这个缺陷做一些他们使用 Firefox javascript 调试工具做不到的事情吗? (即:在我不使用 eval() 函数的情况下自行完成)

注意:javascript 代码存储在 mySQL 中。 ajax用于拉出jscript并显示给用户。 ajax 用于将 javascript 更新发送回 SQL。用户提交的并将插入数据库的所有代码都通过“clean()”函数运行。

I'm working on creating one of those robot games. The user creates a robot and then puts it in a battlefield with other robots.

I'd like to let the users use javascript to program their bots. I'll provide a number of functions for them to call, but they also can build thier own. (sorta)

To date, the only solution I have come up with is to use the javascript eval() function to execute the code the users have written.

I want to know two things:

  1. Anyone have any alternative suggested implementations that still allow the users to write in javascript?

  2. Can the users do anything with this flaw that they could not do using the firefox javascript debugging tools? (ie: on their own without my use of the eval() function)

Note: The javascript code is stored within mySQL. ajax is used to pull the jscript out and display to users. ajax is used to send javascript updates back into SQL. All code submitted by users and about to be inserted in the database is run through a "clean()" function.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

故人爱我别走 2024-10-03 21:15:27

所以基本上你会允许用户A编写将在用户B的浏览器中进行评估的javascript?

如果是这样,那么这听起来是一个相当糟糕的主意;)

您可以使用中间层,例如 http://code.google.com/p/google-caja/wiki/CajaCajole 以使其更安全。

他们可以做的一个例子是:编写 javascript,它将显示类似于您的登录页面的内容,然后将用户名和密码发送到另一台服务器。

另一个例子是注入一个脚本标签,然后获取“完整”有效负载,这可能会造成各种恶作剧,例如 fx 显示一个友好的弹出窗口,其中包含新的独家可下载 Portal 游戏,您与 Steam 达成了特殊协议可用等等。只需下载并运行!然后它会为某些木马 cdn 创建一个隐藏的 iframe。 :)

So basically you will allow UserA to write javascript which will be evalled in UserB's browser?

If so, then that sounds like a fairly bad idea ;)

You could use a middle layer such as http://code.google.com/p/google-caja/wiki/CajaCajole to make it a bit safer.

An example of what they could do is: write javascript which will present what looks like your login page, then send the username and password to another server.

Another example would be to inject a script tag which then gets the 'full' payload which could get up to all kinds of mischief, like fx showing a friendly popup with the new exclusive downloadable Portal game that you got a special deal with Steam to make available etc etc. Just download and Run! Then it creates a hidden iframe to some trojan cdn. :)

差↓一点笑了 2024-10-03 21:15:27

我从没想过我会这么说,但是水仙项目可能对你有用。它是一个用 JavaScript 编写的 JavaScript 引擎。

I never thought I'll say this, but Project Narcissus might be of use to you. It's a JavaScript engine written in JavaScript.

空心↖ 2024-10-03 21:15:27

很酷的主意。

与其他脚本注入方法相比,eval 确实有一点缺点。

您可以使用 Function 动态创建函数。试试这个:

var command = "alert(123)";
var doStuff = new Function(command);
doStuff();

eval 在私有作用域中运行,Function 在全局作用域中运行。这意味着,如果您有一个机器人不应该能够修改的内部值,那么如果您通过 eval 运行它们的逻辑,它们可能可以访问它,但如果您使用 <代码>函数。更多信息请参见:

将字符串更改为函数javascript(不是评估)

Cool idea.

eval does have a slight disadvantage against other methods of script injection.

You can create a function on the fly with Function. Try this:

var command = "alert(123)";
var doStuff = new Function(command);
doStuff();

eval runs in the private scope, Function runs in the global scope. That means if you have an internal value that bots aren't supposed to be able to modify, they might have access to it if you run their logic through eval, but they shouldn't if you use Function. More info here:

changing string to a function in javascript (not eval)

压抑⊿情绪 2024-10-03 21:15:27

许多AJAX库可以设置为自动执行返回的JS。不需要 eval()。

Many AJAX libraries can be set to execute the returned JS automatically. No need for eval().

儭儭莪哋寶赑 2024-10-03 21:15:27

最重要的是让包含用户脚本的页面在单独的“沙盒”域上运行,该域没有来自主站点的可以连接到用户帐户等的会话 cookie。

再加上对提交的一些手动监控,已经消除了很多脚本注入风险。

当允许用户使用 Javascript 时,总会存在恶意代码在用户浏览器上运行的风险,但理所当然的是,获取恶意 JavaScript 是 Internet 上的普遍风险,因此客户端需要采取防范措施。

我不会做的是在项目的主域中使用 eval() 用户输入的 JavaScript。这带来了太多真正的攻击危险。

The most important thing is to let pages containing user scripts run on a separate, "sandboxed" domain that has no session cookies from the main site that could be connected to user accounts and such.

That, together with some manual monitoring of the submissions, will already take away a lot of the script injection risks.

There will always be some risk of malicious code being run on the user's browser when allowing Javascript from your users, but it stands to reason that getting malicious JavaScript is a general risk on the Internet, and it's up to the client to protect against it.

What I wouldn't do is eval() user-entered JavaScript inside the main domain of the project. That opens too many real dangers of attack.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文