| I'm a legend in my own mind, or so I my wife keeps telling me ;)
My pleasure. It was a good excuse to refresh my memory on some of the details...
Best wishes,
dean
P.S. If you start doing a lot of AJ, I recommend getting copies of Ramnivas Laddad's book, "AspectJ in Action", Colyer, et al.'s "Eclipse AspectJ", and MIll's "AspectJ Cookbook". These are the most recent on AJ. I also liked "Mastering AspectJ" for its explanations of different kinds of join points. On Dec 18, 2007, at 3:21 PM, Rob Austin wrote: Dean, you are a legend. Thanks so much for such a clear and thorough explanation. You've saved me hours. Rob
On 17/12/2007, Dean Wampler <dean@xxxxxxxxxxxxxxxxxxxxx> wrote: On Dec 17, 2007, at 2:30 PM, Rob Austin wrote:
Hi Dean, I just want to clarify something here. And just to warn you I'm new to Java (disclaimer if I sound thick). From what I read it may be possible with some older JVMs for a malcious object loaded into the same JVM to grab a reference to an existing running object and call it's public methods. Were you saying that the "reflection catcher" proposed below implemented in the already running object would still catch the malicious method call? I know it's all a bit obscure. Thanks for your patience.
No problem. Let me fill in some details and others on the list can chime in with better ideas ;)
First, if the malicious object doesn't use reflection, but just calls the methods directly, you could write an aspect that looks for those calls. Say for example you want to disallow calls except from another package of yours. A common idiom is the following:
pointcut noCriticalCallForYou(): call (* com.me.mycriticalpackage..*(..)) && !within(com.me..*);
Then you can use this in advise, for runtime checking:
before(): noCriticalCallForYou() {
throw new NoCriticalCallForYouException(); // a runtime exception. you might add an error message!
}
or you can use it with a declare error (compile-time checking), as discussed before.
If the rouge object uses reflection, you'll have to use the pointcut that checks for calls to the reflection API.
For either scenario, whether compile-time or runtime checking is appropriate (or both) depends on the following. If you build all the classes that are loaded by the JVM, you could write a compile-time aspect that declares an error if any class calls either usethe reflection API or call the method(s) directly.
However, if you don't necessary build every class yourself, which sounds like it might be your situation, but you do own the process running the JVM (i.e., you launch the JVM yourself), you could write an aspect that uses "load-time weaving" (LTW) to advise any class that's loaded by the JVM. This would be the runtime checking.
This aspect would use the same pointcut(s) to look for any calls to the reflection library (in the previous message) and/or direct method calls. For runtime checking, you would raise an unchecked (runtime) exception to stop execution, like I showed above.
In either scenario, it's pretty draconian to prohibit reflection, but you can narrow the scope of the pointcut to prevent the scenario you described.
The AspectJ documentation describes how to use LTW. It's easy with Java 5, but still doable with Java 4.
HTH,
dean Rob
On 15/12/2007, Dean Wampler <dean@xxxxxxxxxxxxxxxxxxxxx > wrote: On Dec 15, 2007, at 5:54 AM, Rob Austin wrote:
Hi, I am currently looking at the extent to which AspectJ can be used to enhance object security.
A good application, but I wouldn't just rely on AJ to solve it! ;)
If I write a pointcut that allows me to trap all calls to the public methods of my objects outside of the package it resides on, I can monitor these calls and make sure they are legal, or at least acceptable,and through reflection I can tell which objects are calling these methods.
Yes
But I understand that its possible (even though I wouldn't have a clue how to do it) for one object to call a public method of another object loaded in the same JVM through introspecting the classloader. In other words there would be no matches on the pointcuts at compile time and the advices would not expect to be applied. So, what would happen at runtime if one object "illegally" called another's method? Is there any further runtime checking which would allow the advice to be matched?
It's true that using reflection would "bypass" the pointcut. This is true because the reflection calls will refer to the classes and methods by name (as a string), so the invocations will be "invisible" to AJ. However, if you want to prevent all reflection calls, you could write a pointcut that looks for anyone calling the reflection API and raise an exception. In fact, for this task and your original plan, you can write an aspect that will detect these calls at compile time!
aspect NoReflectionForYou { pointcut allReflectionCalls(): call(* java.lang.reflect..*.*(..));
declare error: allReflectionCalls(): "No reflection for you!!"; }
You can also use declare error to prevent calls to objects in package A from the within objects in package B, for example.
If you don't want to prevent all reflection calls from your code, but only those to "sensitive" areas, you could write an aspect that advices specific reflection calls, e.g., calls to the Method class, and look at the method name to pick out the ones you want to prevent.
Hope this helps.
dean
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Dean Wampler, Ph.D. dean at objectmentor.com See also:
|
