java中包含操作系统级命令的包有哪些?

发布于 2024-09-18 06:30:50 字数 138 浏览 9 评论 0原文

我想检测给定的程序是否可以执行恶意操作,例如分叉、进程间管道、输入/输出重定向、文件处理等。 实际上我正在开发一个检查java代码的程序,并且不希望编码器以任何方式损害我的代码检查系统。
我应该在代码中查找哪些包来确保这一点?
提前致谢... !

I want to to detect whether a given program can perform malicious operations like forking , interprocess piping , input/output redirection, file handling etc.
Actually I am developing a program that checks java codes and do not want the coder to harm my code checker system in any way.
What are the packages I should look for in code to ensure this ?
Thanks in advance... !

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

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

发布评论

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

评论(4

清旖 2024-09-25 06:30:50

您的检查是在编译时还是在运行时进行?

  • 如果您在运行时检查,则可以使用具有权限的安全管理器。查看安全管理器教程。有一个广泛的权限列表。您可以禁止文件访问,甚至打开框架。

  • 对于基类,您必须小心使用java.lang.Runtimejava.lang.Systemjava.lang.ProcessBuilder< /代码>。它们创建java.lang.Process。另外,java.io.Filejava.io.FileDescriptor,甚至可能是 Sockets 和 java.nio.* 在操作系统/文件系统上运行.

  • 我也不允许反射,java.lang.reflect.*,并且java.lang.Class的一些方法也是反射的。按名称加载类可能会解决您的检查问题。 java.beans.* 中的一些类也使用反射。

  • 根据您的需求,您甚至可能希望用户代码在

  • 正如 Colin HEBERT 之前指出的那样,native 也是危险的。但其中一些是肯定需要的,例如 Object 的方法。

Would your checks be at compile time or at runtime?

  • If you check at runtime, you could use a security manager with permissions. Have a look at Security Manager Tutorial. There is a wide list of permissions. You can disallow file access, even open frames.

  • As for base classes, you would have to be careful with java.lang.Runtime and java.lang.System, java.lang.ProcessBuilder. These create java.lang.Process. Also java.io.File, java.io.FileDescriptor, maybe even Sockets and java.nio.* operate on the OS/file system.

  • I would also disallow reflection, java.lang.reflect.*, and some methods of java.lang.Class are reflective too. Loading classes by name might workaround your checks. Some classes in java.beans.* are using reflection as well.

  • Depending on your needs, you might even want the user code to run in a sandbox. But that might go too far for you. Checking for class usage (constant pool) might be an easy way.

  • As Colin HEBERT pointed out before, native is also dangerous. But some of them are definitely needed, like Object's methods.

书间行客 2024-09-25 06:30:50

您应该考虑检查所有标记为“本机”的方法。

You should think about checking also all methods marked as "native".

眼眸里的那抹悲凉 2024-09-25 06:30:50

许多操作系统交互功能是在 java.lang.Runtimejava.lang.System 中提供的。请注意,这些不需要导入,因为它们位于 java.lang 包中。

但是...如果您只是分析代码,为什么要关心它包含的调用内容呢?也许您应该查看 Java Security 而不是调用哪些类。

Much of the OS-interaction functionality is provided in java.lang.Runtime and java.lang.System. Note that these wouldn't require imports, because they're in the java.lang package.

But... if you're just analyzing the code, why would you care what calls it contains? Perhaps you should be looking at Java Security instead of which classes get called.

千秋岁 2024-09-25 06:30:50

简短的回答:java.lang。我相信这是唯一一个“开箱即用”的包,其中包含允许您访问操作系统功能的类。好吧,我在这里假设您不将 I/O 包含为“与操作系统相关”的东西。如果这样做,那么您还必须包含 java.io、javax.swing 和其他几个包。

更长的答案:程序员可以编写自己的 JNI 函数来与操作系统交互,并将它们放入他喜欢的任何包中。试图识别这一点可能非常棘手。好吧,我想你可能会说任何“本机”函数都会自动受到怀疑。

Short answer: java.lang. I believe that's the only "out of the box" package that includes classes that give you access to OS functions. Well, I'm assuming here that you don't include I/O as "OS-related" stuff. If you do, then you'd also have to include the java.io, javax.swing, and a couple of other packages.

Longer answer: A programmer could write his own JNI functions that interact with the OS and put them in any package he likes. Trying to identify this could be quite tricky. Well, I guess you could say that any "native" function is automatically suspect.

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