在apachesling中:如果您有一个多租户设置或一个用户可以部署自己代码的环境(例如jsp或实际的java/groovy代码或诸如此类的东西):有没有一种方法可以确定从被调用的osgi服务中发送当前请求的用户的身份?它必须能安全抵御恶意代码。
背景:通常,依赖jcr权限来保护用户不应该看到的内容就足够了。但有时您希望osgi服务使用服务用户访问服务实现所需的jcr资源的内部内容,但您不希望用户能够访问这些内容。在这里,您可能有某种防篡改的方法来标识用户,以便检查其对服务的权限。
有些事情显然行不通。
您可以将users resourcesolver作为参数传递给osgi服务的调用,并检查resourcesolver.getuserid()返回的内容。通过传入一个 Package 器可以很容易地颠覆这一点,该 Package 器委托给原始的resourcesolver,但在这里为getuserid()返回一些任意的内容。
可以将users resourcesolver作为参数传递给服务,检查用户对资源树中某个路径的访问,并设置jcr权限来保护该路径。不幸的是,这并不像听起来那么容易:恶意代码可能再次通过一个 Package 器,该 Package 器返回此路径的模拟资源,模拟访问。我认为这样做唯一可行的方法是,用户必须对该路径进行写访问,服务用户用于检查是否确实修改了该路径。但由于性能和其他原因,这不是一个好方法。
你还有其他的想法吗?谢谢!
注意:我知道这里还有其他攻击需要阻止(例如使用反射入侵osgi服务,但我想至少让它变得不寻常)。
2条答案
按热度按时间cbeh67ev1#
嗯,我至少找到了一些东西:resourcesolverfactory.getthreadresourcesolver返回请求为其自身进行身份验证的最后一个resourcesolver。因此,如果将resourcesolverfactory注入到服务中,那么它返回的resourcesolver的getuserid似乎至少提供了一个用户可以模拟的用户id。
(请注意,这不一定是用户本身的原始id,因为如果代码使用resourceresolverfactory.getresourceresolver,则会更改结果。但这至少意味着用户可以模拟返回的用户id。)
另一件事是使用像composum的platformaccessfilter这样的servletfilter,它将原始slinghttprequest使用的resourcesolver保存在threadlocal中(如果恶意代码能够部署具有更高优先级的servletfilter,那么该方案就会失败,但我们必须在某个地方停止。)
不幸的是,这两种想法都不能与服务解析器一起使用,因为resourcesolverfactory.getservicesolver没有设置esourceresolverfactory.getthreadresourcesolver。
c9qzyr3d2#
它是一个多租户系统,因此每个用户都会成为某个租户。根据租户上下文,您可以使用requestcontext对象,该对象实际检查租户的用户是否具有正确的访问权限,并允许特定用户使用securitymanager。