Re: [aspectj-users] Plans for dflow pointcut

[Simone Gianni <simoneg@xxxxxxxxxx>]

My two cents :
 - +1 for it, it IS really useful.
 - Perl has a similar mechanism, called taint mode, which basically
flags some variables as "tainted", makes this property transitive, and
places restrictions to their usage. If you have access to a *nix box,
type "man perlsec" to look at the manual. It sounds like something very
very similar (but seen from an implementation perspective) to what is
proposed in the paper.
 - It is possible (thought very expensive) to write aspects doing
similar (but far less sophisticated) things right now. For very
expensive I mean both for the programmer and for the runtime.

If you are really, really, really interested, have nothing better to do,
it's raining and you cannot go to the beach ... a "simple" example follows :

import java.util.WeakHashMap;

public aspect Tainting {
    // This will hold the tainted objects (only Strings and
StringBuilders right now).
    // I use a WeakHashMap so that the GC can reclaim them
    private WeakHashMap<Object, Boolean> tainteds = new
WeakHashMap<Object, Boolean>();

    // This pointcut tells which method returns insecure stuff
    pointcut taintIt() : call(String TestClass.getParameter(..));

    after() returning (String s) : taintIt() {
        tainteds.put(s, Boolean.TRUE);
    }

    // Now we have to apply transitivity. This is a PITA with strings,
cause they are immutable objects defined in the JRE so not accessible by
AspectJ.
    // Anyway we have basically three types of transitivity :
    //  ... New objects created with  tainted objects as parameters (the
case for a constructor having a tainted parameter)
    //  ... Objects modified with tainted objects (the case for a
setter, in this case the append method)
    //  ... New objects PRODUCED BY tainted objects (the case for the
toString() method of a "contaminated" StringBuilder, it's what declare
propagate does in the paper)

    // This is what a recent compiler generated when two strings are
concatenated
    pointcut stringAddition(Object isTainted, Object toTaint) : call(*
StringBuilder.append(String)) && args(isTainted) && target(toTaint);

    // more pointcuts like this could be added, there are endless
possiblities :)

    // The case for modifications (append)
    pointcut transitives(Object isTainted, Object toTaint) :
stringAddition(isTainted, toTaint);

    after(Object isTainted, Object toTaint) returning :
transitives(isTainted, toTaint) {
        if (tainteds.containsKey(isTainted))
            tainteds.put(toTaint, Boolean.TRUE);
    }
   
    // The case for new objects produced by tainted objects (the toString)
    pointcut transitiveReturns(Object isTainted) : call(String
StringBuilder.toString()) && target(isTainted);

    after(Object isTainted) returning (Object toTaint):
transitiveReturns(isTainted) {
        if (tainteds.containsKey(isTainted))
            tainteds.put(toTaint, Boolean.TRUE);
    }
   
    // The case for constructors having taninted arguments
    pointcut transitiveCreations(Object isTainted) : call(public
StringBuilder.new(String)) && args(isTainted);

    Object around(Object isTainted) : transitiveCreations(isTainted) {
        Object ret = proceed(isTainted);
        if (tainteds.containsKey(isTainted))
            tainteds.put(ret, Boolean.TRUE);       
        return ret;
    }
   
    // Here is where we check if a method is called with tainted parameters
    pointcut toProtect() : execution(* TestClass.do*(..));

    before() : toProtect() {
        Object[] params = thisJoinPoint.getArgs();
        for (Object object : params) {
            if (tainteds.containsKey(object))
                throw new RuntimeException("Using tainted stuff");
        }
    }

}

If you want to compile it, and you are lazy, this is the TestClass :

public class TestClass {

    public String getParameter(String name) {
        return "ciao";
    }
   
    public void doSecureStuff(String value) {
        System.out.println("Doing secure stuff with '" + value + "'");
    }
   
    public void tryIt() {
        String secure = "Created here";
        doSecureStuff(secure);
       
        String tainted = getParameter("a");
        try {
            doSecureStuff(tainted);
        } catch (Exception e) {
            System.out.println("Thrown exeception cause tainted");
        }
       
        String transitive = tainted + " ciao";
        try {
            doSecureStuff(transitive);
        } catch (Exception e) {
            System.out.println("Thrown exeception cause tainted");
        }
    }
   
   
    public static void main(String[] args) {
        TestClass t = new TestClass();
        t.tryIt();
       
        StringBuilder b = new StringBuilder("ciao");
        b.toString();
    }
}

Obviously this is a toy, it is implementation dependant (use another
compiler, StringBuilder not in place, nothing will work), and it's very
heavy, both on performances and on code itself (every string
concatenation is adviced, try to make a more generic aspect which
intecepts any set/get and you'll get thousands of advices), and it will
never work on primitive types since they don't have an identity.

hope you enjoied :)

Simone

Rohit Lists wrote:
> Hello, are there are any plans to implement the data flow pointcut as
> defined here www.graco.c.u-tokyo.ac.jp/~masuhara/papers/aplas2003.pdf
> in AspectJ? This would be an invaluable resource to application
> security since large classes of security problems deal with tracing
> data from source to sink (e.g. cross site scripting,
> SQL/XML/Xpath/Ldap injection, OS interaction vulnerabilities, etc.).
>
> If there are no such plans, is it because there are not enough
> resources to work on this? Has there already been a discussion on
> implementing dflow pointcut and a decision was made not to implement
> it?
>
> Thanks,
>
>   


-- 
Simone Gianni
http://www.simonegianni.it/
CEO Semeru s.r.l.
Apache Committer