What I want to do is implement some basic security by checking not only what class has called a particular method, but also, which instance of that class.
I tried
StackTraceElement[] stackTraceElements = Thread.currentThread().getStackTrace();
but that obviously only gives me the class name. The problem with allowing/requiring the callers to send self, or personal IDs is that all the callers are required to have access to the details of all the others. Can anyone help?
EDIT: More information:
So we have a server which makes connections with several agents. The agents send packets of information which include the name they CLAIM to have. There is a special agent which decides whether or not people should be able to lie about this in each particular case.
The agents make connections to instances of an Agent class on the server, but there is also a possibility that some agents will run natively. The reason I'm interested in this approach is that I will need that technique later (extract the specific instance that called a given method)
I hope this is better, and sorry for not putting enough info before :/
This whole line of attack can't possible secure anything. If users can control the code that runs, they can just run a codegen library and edit your code. If users can't control the code, then this is all unnecessary.
If you can't resist this urge, one approach is to wrap everything in Proxies that communicate the information you need.
By Proxy, I mean java.lang.reflect.Proxy. That is, wrap every one of these objects in a proxy. The proxy's job would be to store away this on a stack of your own that the callees could consult.
This is essentially AOP (aspect oriented programming) reinvented, so you might want to read about that. Look at the Spring framework.
You are not securing anything like this.
I think for such problems just check that all contributing code comes from signed jars.
Look up Capability-based security. Instead of knowing which client is doing what, you should give each client separate capability objects (essentially proxy objects with different privileges).
Related
Is there a way to configure the JVM to block instances of a class being created?
I'd like to do this to ensure no service running in the JVM is allowed to create instances of a class that has been identified as a security risk in a CVE, lets call that class BadClass.
NOTE: I'm looking for a general solution, so the following is purely additional information. I would normally address this by switching the library out, or upgrading it to a version that doesn't have the exploit, but it's part of a larger library that wont be addressing the issue for some time. So I'm not even using BadClass anywhere, but want to completely block it.
I do not know a JVM parameter, but here's some alternatives that might pout you in a position that solve your requirements:
You can write a CustomClassLoader that gives you fine control on what to do. Normal use cases would be plugin loading etc. In your case this is more security governance on devops level.
If you have a CICD pipeline with integration tests you could also start the JVM with -verbose:class parameter and see which classes are loaded when running your tests. Seem a bit hacky, but maybe suits your use case. Just throwing everything into the game, it's up to you judging about the best fit.
Depending on your build system (Maven?) you could restrict building applications just on your private cached libs. So you should have full control on it and put a library - review layer in between. This would also share responsibility between devs and the repository admins.
A distinct non-answer: Do not even try!
What if that larger library that has this dependency wants to call that method? What should happen then?
In other words, what is your blocking supposed to do?
Throw some Error instance, that leads to a teardown of the JVM?
Return null, so that (maybe much later) other code runs into a NPE?
Remember: that class doesn't exist in a void. There is other code invoking it. That code isn't prepared for you coming in, and well, doing what again?!
I think there are no good answers to these questions.
So, if you really want to "manipulate" things:
Try sneaking in a different version of that specific class into your classpath instead. Either an official one, that doesn't have the security issue, or something that complies to the required interface and that does something less harmful. Or, if you dare going down that path, do as the other answer suggests and get into "my own classloader" business.
In any case, your first objective: get clean on your requirements here. What does blocking mean?!
Have you considered using Java Agent?
It can intercept class loading in any classloader, and manipulate it's content before the class is actually loaded. Then, you may either modify the class to remove/fix it's bugs, or return dummy class that would throw error in static initializer.
I have a web service that return an xml file. Now I want to create a new web service that uses a part of information that contains the output of first web service. My question is what is better solution:
1.call first web service and use result in new web service?
recreate a part of code of first web service and create an new web service which is independent from first.
I know with first solution I can handle better the code but maybe it will be slower and use more traffic in network.
Οn the other hand,the second proposal solution don't reuse code and it will be more difficult to conserve the project. I would like an complete answer using arguments.
Thank you
Each has its own pros and cons. I'm trying to describe them below:
Using the service has the advantage of not engineering (Dev and Qa) the same functionality twice. You can call a remote service, and just use the functionality it provides. That's why services exist, isn't it? Also, when the service gets evolved, you do not have to worry about anything, like changing your local jar, etc. However, the service runs as a separate component. It thus needs to be monitored and operationally managed.
Using a jar/library in place of a service has the advantage of "locality". The code being executed within the process is much high performing. You can avoid creating a socket connection, and dealing with complexities of calling another service. However, you might have to abstract out the function as a library.
It altogether depends on "what" functionality you are looking at, how complex is it to implement, will the functionality frequently evolve, and would it be useful for other set of clients? If it's complex, evolving, and useful to a multitude of clients, the answer is "write a service".
Experts advice to avoid the 'remote' solutions for as long as possible, as they brings complexity in testing, debugging, maintaining, etc. Just imagine, how would you handle situation when the first WS is going down? How would you test all this? How would you handle situation when the first WS reponds with some invalid data? Lots of questions arises here.
It is really hard to give you the 'right' answer, because it always depends on context and your needs. Sometimes there is just no choice, but implementing the distributed solution.
For inspiration, I would strongly recommend reading the "Enterprise Architecture Patterns" book of M. Fowler.
Diplomatic Question. Its depends on organization to organization , strategy, architecture and design you have followed.
My Suggestion is :
Go with Option 1:
That is divide and rule, if it is service oriented architecture with many consumers for your service
Go with Option 2:
If you are the consumer and provider for this service.
suppose I want to allow people run simple console java programs on my server without ability to access the file system, the network or other IO except via my own highly restricted API. But, I don't want to get too deep into operating system level restrictions, so for the sake of the current discussion I want to consider code level sanitization methods.
So suppose I try to achieve this restriction as follows. I will prohibit all "import" statements except for those explicitly whitelisted (let's say "import SanitizedSystemIO." is allowed while "import java.io." is not) and I will prohibit the string "java.*" anywhere in the code. So this way the user would be able to write code referencing File class from SanitizedSystemIO, but he will not be able to reference java.io.File. This way the user is forced to use my sanitized wrapper apis, while my own framework code (which will compile and run together with user's code, such as in order to provide the IO functionality) can access all regular java apis.
Will this approach work? Or is there a way to hack it to get access to the standard java api?
ETA: ok, first of all, it should of course be java.* strings not system.*. I think in C#, basically...
Second, ok, so people say, "use security manager" or "use class loader" approaches. But what, if anything, is wrong with the code analysis approach? One benefit of it to my mind is the sheer KISS simplicity - instead of figuring out all the things to check and sanitize in SecurityManager we just allow a small whitelist of functionality and block everything else. Implementation-wise this is a trivial exercise for people with minimal knowledge of java.
And to reiterate my original question, so can this be hacked? Is there some java language construct that would allow access to the underlying api despite such code restrictions?
In your shoes I'd rather run the loaded apps inside a custom ClassLoader.
Maybe I'm mistaken, but if he wants to allow limited access to IO through his own functions, wouldn't SecurityManager prevent those as well? With a custom ClassLoader, he could provide his SanitizedSystemIO while refusing to load the things he doesn't want people to load.
However, checking for strings inside code is definitely not the way to go.
You need to check the SecurityManager. It is called by lots of JVM classes to check, before they perform their work, if they have the permission needed.
You can implement your own SecurityManager. Tutorial.
i am currently working on a java application for some network monitoring tool. In my code i am supposed to use logging a lot. Since its a network management software, the information in logs is quite useful to the user hence its compulsory to use them. But now I am bit confused with what kind of logger method i should prefer. Right now i am using Logger.lop(...//...) since with its help we are also logging the class name and method so its becoming very easy for me (developers) to debug the code and find the error. But finally I am confused should i deliver it to the end user with the same logging mechanism??? Is it any harm to let your user know what kind of class is executing currently , in which method error has occured. I have seen many times in many product in exception handling stacktrace is used so normally we get class name as well. So is there is no problem to let enduser know what your class name and method is??
Before considering the security implications of it, consider the performance. In most logging systems, getting the actual classname and method name dynamically by the logging facility requires reflection and dramatically slows down the logging - usually a synchronous operation. My guess is that in a network monitoring application, you really don't want that.
If you're hard-coding the method name into the log message (either by making it part of the message or by the category), that's a different story. As a security person, I don't consider it to be that big of a deal - if your code is in Java, it can be reversed anyhow, so your code should operate in such a way that it would be secure even if the code was given away.
All that being said, you could either use a different logging configuration for development and production, or those fine-grained messages could go in debug, trace, etc. If you're using log4j, it's generally advisable to use isDebugEnabled to wrap any logging statements which include anything dynamically-calculated as those get calculated before the logging statement determines whether it's enabled.
log4j/logback/slf4j allow you to have different formats for different appenders. For development you can enable a console appender where you include the class name in the format, while for the end-users you can omit it (for a file appender)
It's worth mentioning that such logging is performance costly in Java, contrary to C++ where it is usually implemented with preprocessor. Fortunately, with log4j/logback you can switch it on and off — follow Bozho's advice.
Is there an easy way to check whether an object is still bound to a "tnameserv" ?
After you bind an object, the "tnameserv" process might crash, be killled, ... and I want my application to verify whether an object that I bound earlier is still bound.
Assuming you're using the Oracle Java ORB, why not use the persistent name service which they provide rather than the transient tnameserv? It sounds like your application needs a persistent registration of references, so trying to get persistent-like behavior from a transient naming service will likely be a dead-end.
BTW you can use any vendor's COS Naming Service, and not just the one provided by Oracle (nor does it even have to be written in Java, either). For example, the free JacORB Name Server can run in a persistent mode, allowing the references you register to survive a restart or crash of the service.
In any case, the answer to your question depends on whether or not you're asking it from the client's or server's perspective. A server using the Naming Service shouldn't need to check that there's an existing reference of its own already registered in there - it should instead just call rebind() to update the registration. If there's nothing in there already, the reference will be added. If there's one in there, it will get overwritten with the new value.
If you're asking about this from your client's perspective, you should remember that the Naming Service is like a phone book. If the client doesn't find a registration in there that it requires, it's pretty much dead in the water unless it can find other suitable objects which could be used to provide the services you need. It's probably better to have your client fail at that point rather than try to guess at how to compensate for what is really a catastrophic scenario.