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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> >
> >
> >
> > Apologies if this question is full of hypotheticals (I know that 2 java
> > programs would normally be launched in seprate JVMs!).
> >
> > Thanks
> >
> > Rob
> >
> >
> >
> >
> > _______________________________________________
> > aspectj-users mailing list
> > [email protected]
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >
> > Dean Wampler, Ph.D.
> > dean at objectmentor.com
> > http://www.objectmentor.com
> > See also:
> > http://www.aspectprogramming.com AOP advocacy site
> > http://aquarium.rubyforge.org AOP for Ruby
> > http://www.contract4j.org Design by Contract for Java5
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > aspectj-users mailing list
> > [email protected]
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >
> _______________________________________________
> aspectj-users mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
> Dean Wampler, Ph.D.
> dean at objectmentor.com
> http://www.objectmentor.com
> See also:
> http://www.aspectprogramming.com AOP advocacy site
> http://aquarium.rubyforge.org AOP for Ruby
> http://www.contract4j.org Design by Contract for Java5
>
>
>
>
>
>
> _______________________________________________
> aspectj-users mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
