[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Plans for dflow pointcut
|
Hi Simone, thanks for the posting. Yes this is very much based on the
idea of perl taint mode. It's funny I actually implemented something
very similar to what you've posted for the time being. My concerns are
the same as yours though.
Another interesting point is that in the paper I've linked, you simply
remove taint prior to encoding. For the case of XSS, this isn't so
easy.Take for example:
String dangerous = request.getParameter("something");
StringBuffer sb = "<b> This tag was found " + dangerous + "</b>"
In this case, you want to encode dangerous but not encode the String
literals. In my solution, I saved a copy of the StringBuffer (actually
I used CharSequences rather Strings/StringBuffers/StringBuilders since
all three classes implement the CharSequence interface in java 5+) and
encoded only the dangerous parts in the copy. When it came time to
print, I used the safe encoded copy rather than the original
CharSequence. This of course has performance penalty, but I don't see
a clear alternative to it ...
On Mon, Aug 11, 2008 at 3:08 PM, Simone Gianni <simoneg@xxxxxxxxxx> wrote:
> 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
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
--
Rohit Sethi
Security Compass
http://www.securitycompass.com
