安全性:限制第三方软件的内部访问 [英] Security: Restrict internal access by third-party software

查看:29
本文介绍了安全性:限制第三方软件的内部访问的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个 Java 应用程序,用户可以在其中加载第三方插件"以增强用户体验.存在供这些插件使用的 API,但出于安全目的,应限制第三方软件访问内部应用程序类.插件的受限包是com.example",允许的是com.example.api".API 类确实会调用内部的混淆类.

I have a Java application in which third-party "plugins" can be loaded by users to enhance the user experience. An API exists for use by these plugins, but the third-party software should be restricted from access to internal application classes for purpose of security. The restricted package to plugins would be "com.example" and the allowed would be "com.example.api". The API classes do make calls to the internal, obfuscated classes.

在研究这个之后,我遇到了几个SecurityManager的方法:checkMemberAccess(Class, int)checkPackageAccess(String),这两者似乎都是实现我的目标的可行途径.但是,经过一些测试和进一步研究,我发现 checkMemberAccess 仅适用于反射调用,而 checkPackageAccess 仅在类加载器调用 loadClass 时调用.

After researching this, I came across a couple methods of SecurityManager: checkMemberAccess(Class, int) and checkPackageAccess(String), which both seemed to be viable paths to my goal. However, after doing some tests and further research, I have found that checkMemberAccess only applies to reflection calls, and checkPackageAccess is only called when a class loader invokes loadClass.

限制对包的访问的合理方法是什么(com.example,但不是 com.example.api)?

What is a reasonable way to restrict access to a package (com.example, but not com.example.api)?

推荐答案

我建议为插件编写一个自定义类加载器,它隐藏了com.example 从使用该类加载器加载的类中打包.通常类加载器委托给它们的父级,但在野外有几个实现只能部分或根本不这样做.我相信例如蚂蚁使用这种技术.当使用这样的类加载器加载时,任何违反禁止功能的链接类都将无法加载.或者,如果实现使用了延迟链接,并且它确实加载成功,则在执行禁止代码期间它仍然会失败.

I suggest writing a custom class loader for the plugins, which hides the existence of the com.example package from classes loaded using that classloader. Usually class loaders delegate to their parent, but there are several implementations out in the wild which will do so only in part or not at all. I believe e.g. ant uses this technique. When loaded with such a class loader, any class linked against forbidden functinality would fail to load. Or if the implementation used lazy linking, and it did load successfully, it would still fail during execution of the forbidden code.

拒绝您的插件链接时访问被禁止的包后,您可以使用 SecurityManager 通过反射拒绝运行时访问,并拒绝创建可能用于绕过您的新类加载器.

Having denied your plugins link-time access to the forbidden package, you can then use a SecurityManager to deny runtime access via reflection, and also to deny creation of a new class loader which might be used to circumvent yours.

class RestrictingClassLoader extends URLClassLoader {
  @Override
  public Class<?> loadClass(String name) throws ClassNotFoundException {
    if (!name.startsWith("com.example.") || name.startsWith("com.example.api."))
      return super.loadClass(name);
    return findClass(name);
  }
}

class RestrictingSecurityManager extends SecurityManager {
  private boolean isRestricted() {
    for (Class<?> cls: getClassContext())
      if (cls.getClassLoader() instanceof RestrictingClassLoader)
        return true;
    return false;
  }
  // Implement other checks based on isRestricted().
}

这篇关于安全性:限制第三方软件的内部访问的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆