In our app, application loads user module using custom class loader. What would be the best way to protect wild behavior of the user module? We want to prevent:
user code to modify any application code. We have some singletons, and user may access it using e.g. reflection to get some instances and change e.g. some critical configuration; or replace some guard code. Since the classloader is written by me, so I can prevent loading any class that is critical.
user code should access only some folders; if possible. So it behave like unix user :)
The first step is to set a SecurityManager. This is because the Java class library contains global state. You will also need to ensure your code does not use its privileges to expose itself through this state. In addition some global state is not security checked, for instance through "AppContext" and the current thread.
Usually the package.access security property is used to hide internal code within a parent class loader context. This isn't a bad idea if the potentially malicious code is loaded through a non-child class loader.
Note, if you pass an instance of your hidden code, malicious code can use Object.getClass, Class.getMethods, etc., to explore the public interface. Class.getClassLoader is checked, but make sure there aren't other outlets, such as through the thread context class loader (though Thread.getContextClassLoader strangely has a security check, its use is to publish the class loader).
Related
How can i prevent anonymous users to run domino servlet in a database. I have set the access for Anonymous to no access and then it works find ... but ...
We need to have the Anonymous access set to "NoAccess" and "Read public documents" in the Access Control list. I don't understand why anonymous users are allowed to run the java servlet when we have "read public document" checked.
Can I prevent this in some way? we don´t wanne allow the Anonymous to run servlets.
In our databas we have an login form thats allow public acess.
Is this possible or do we need to do this in another way?
If Anonymous is granted Read Public in the ACL, the anonymous users have to be given the ability to access design elements. That includes forms, views, and I guess servlets, too. That would explain why it behaves as you have observed.
For a workaround, you could consider putting the servlet in a separate NSF file where you can set the ACL so that Anonymous has "No Access" without the "Read public documents" flag? This might require a small amount of reprogramming if the Java code is assuming that it is accessing the current database, but the change could just be a single line of code and it should lock your servlet down.
I am a bit confused as to why someone would use #PreAuthorize("denyAll") for a method. As per the spring security documentation, it always evaluates to false.
If we are not going to allow access to a particular method, what is the point of keeping such a method. Why not comment it out? Or is it that it can still be accessed from within the same class?
I am trying to understand under what scenario such a requirement would arise.
One small clarification that I found in general for deny all was
#DenyAll annotation can be used to restrict business interface access from anyone, logged in or not. The method is still invokable from within the bean class itself.
So the jist is it can be used for a method which is public for some reason or have been exposed (perhaps it implements an interface) but should never be called directly from outside. However they can be called from inside(within the class).
here is the link
One real example that I can give you is (which is quite related with my work). We have 2 business unit with same code base. Now in one unit there is a feature where some mobile reseller can directly call a service which cancels the voucher directly to the operator end but in the other unit we needed to block this due to some business rule. Since we use the same interface in both system so in one system we blocked its usage using denyall
Hope this gives you a clear idea.
I decorate my service classes in this way which requires the individual inner service methods to override the denying class level PreAuth annotation. This ensures that each method in the class will be appropriately secured w/a fallback to denyAll.
I know this is old but I stumbled on it looking for the syntax for #PreAuthorize('denyAll') and thought I'd throw my 2cents in.
One can load a class dynamically using this method of java.lang.Class:
public static Class<?> forName(String name, boolean initialize,
ClassLoader loader)
According to the JavaDoc, the second parameter is used to control the timing of class initialization (execution of static initialization code). If true, the class is initialized after loading and during the execution of this method; if false, initialization is delayed until the first time the class is used.
Now, I understand all that, but the docs don't say how to decide which strategy to use. Is it better to always do initialization immediately? Is it better to always delay it to first use? Does it depend on the circumstances?
Yes, it depends on circumstances, but usually it is preferred to just let classes be loaded and initialized on first use.
Cases when you might want to early initialize them (e.g. by calling forName() for them):
Static initialization blocks might perform checks for external resources (e.g. files, database connection), and if those fail, you don't even want to continue the execution of your program.
Similar to the previous: loading external, native libraries. If those fail (or not suitable for the current platform), you might want to detect that early and not continue with your app.
Static initializaiton blocks might perform lengthy operations and you don't want to have delays/lags later on when they are really needed, you can initialize them early or on different, background threads.
If you have static configuration files where class names are specified as text, you might want to initialize/load them early to detect configuration errors/typos. Such examples are logger config files, web.xml, spring context etc.
Many classes in the standard Java library cache certain data like the HTTPUrlConnection caches the HTTP user agent returned by System.getProperty("http.agent"). When it is first used, its value will be cached and if you change it (with like System.setProperty()), the new value will not be used. You can force such caching if you initialize the proper classes early, protecting them to be modified by the code later on.
Cases when you should not initialize early:
Classes which might only need in rare cases, or they might not even be needed at all throughout the run of your application. For example a GUI application might only show the About dialog when the user selects the Help/About menu. Obviously no need to load the relevant classes early (e.g. AboutDialog) because this is a rare case and in most runs the user will not do this / need this.
I have a Java class which have some confidential information which I don't want to provide to any unauthorized class.
I want to access this class in some packages (classes from this packages are going to utilize confidential information), So that my secure class should be accessible in these packages.
Is there any way where I can check if caller of method is a authorized class from authorized package or not?
I know public/private/default all things (so please don't ask me to use it), but those are not useful here, because I want a class to be accessible in some packages(not one/same).
I feel that you are going in the wrong direction. It might be a design problem.
The security requirement is your business logic. You should implement your security policy somehow, not rely on the java language level visibility modifier or caller package names. since if you give your jar to someone, he can anyway get access to your "confidencial" class.
And moreover, a class is a type, something abstract. it should not contain "data". well sure sometimes conf information was written as static variable etc. However if some data is sensitive, it should not be written in class. It could be stored in database or encrypted file and so on. Once a request to the sensitive information comes, you check your implemented security policy, if it is allowed to access those data.
just my 2cents
The visibility modifiers in Java are not a security tool, but an OO design tool. Whatever you might do, if someone uses your class, it can access any private members of any class using reflection.
If your objects contain confidential information, leave these objects in your secure server.
You can create an Exception (no need for it to be thrown) and use the getStackTrace() to analize the call stack. I always found it ugly, though.
That said, anything that you put in a client machine is vulnerable to that machine; if you have something really confidential protect it in your server; make it available only as a service.
You can use the proxy pattern, implemented by the Proxy class in Java - it is designed exactly for your purpose.
Here is a how-to.
EDIT : AFAIK, you cannot use the regular Proxy mechanism for static methods, as the proxy and the proxied class must implement a common interface. However, there are more advanced tools, which may help you like javassist. Unfortunately I'm not familiar with it myself.
You might be able to leverage aspectj here. It's theoretically possible to intercept the call to a given classes' methods based on the current flow scope, and have the aspect throw an exception or something. I'm no aspectj expert though, but the "cflow" pointcut qualifier would be your most likely bet. Maybe something like this
! cflow(call(* com.mycom.AllowedClient.*))
I haven't tested this kind of pointcut, but i believe it would work.
You'd probably want compile time weaving in this case though (as opposed to load time weaving).
As a side note, i agree with some of the others that i think this is the wrong approach to take. You protect data. You protected function access based on logged in user permissions. You typically don't protect function calls from other classes.
Guideline 4-2 / EXTEND-2: Limit the accessibility of packages
Containers may hide implementation code by adding to the package.access security property. This property prevents untrusted classes from other class loaders linking and using reflection on the specified package hierarchy. Care must be taken to ensure that packages cannot be accessed by untrusted contexts before this property has been set.
This example code demonstrates how to append to the package.access security property. Note that it is not thread-safe. This code should generally only appear once in a system.
private static final String PACKAGE_ACCESS_KEY = "package.access";
static {
String packageAccess = Security.getProperty(PACKAGE_ACCESS_KEY);
Security.setProperty(PACKAGE_ACCESS_KEY,
(packageAccess == null || packageAccess.trim().isEmpty()
? "" : packageAccess + ",")
+ "xx.example.product.implementation.");
}
The question is old hat - what is a proper design to support a configuration file or system configurations across our system? I've identified the following requirements:
Should be able to reload live and have changes picked up instantly with no redeploying
For software applications that rely on the same, e.g., SQL or memcached credentials, should be possible to introduce the change in an isolated place and deploy in one swoop, even if applications are on separate machines in separate locations
Many processes/machines running the same application supported
And the parts of this design I am struggling with:
Should each major class take its own "Config" class as an input parameter to the constructor? Should there be a factory responsible for instantiating with respect to the right config? Or should each class just read from its own config and reload somewhat automatically?
If class B derives from class A, or composes around it, would it make sense for the Config file to be inherited?
Say class A is constructed by M1 and M2 (M for "main") and M1 is responsible for instantiating a resource. Say the resource relies on MySQL credentials that I expect to be common between M1 and M2, is there a way to avoid the tradeoff of break ownership and put in A's config v. duplicate the resource across M1 and M2's config?
These are the design issues I'm dealing with right now and don't really know the design patterns or frameworks that work here. I'm in Java so any libraries that solve this are very welcome.
You may want to check out Apache Commons Config, which provides a wide range of features. You can specify multiple configuration sources, and arrange these into a hierarchy. One feature of particular interest is the provision for Configuration Events, allowing your components to register their interest in configuration changes.
The goal of changing config on the fly is seductive, but requires some thought around the design. You need to manage those changes carefully (e.g. what happens if you shrink queue sizes - do you throw away existing elements on the queue ?)
Should each major class take its own "Config" class as an input parameter to the constructor?
No, that sounds like an awful design which would unnecessarily overcomplicate a lot of code. I would recommend you to implement a global Configuration class as a singleton. Singleton means that there is only one configuration object, which is a private static variable of your Configuration class and can be acquired with a public static getInstance() method whenever it is needed.
This configuration object should store all configuration parameters as key/value pairs.