About interpreting tainting related reports

[kanaksad]

I was trying to use PTaint on esapi-java-legacy following the steps here with this command, ./doop -i toScan.jar -a 2-object-sensitive+heap --information-flow webapps.

In the output directory, I see two tainting related .csv files; adding the outputs for your reference LeakingTaintedInformation.csv LeakingTaintedInformationVars.csv

According to the rules here, in LeakingTaintedInformation.csv output, the last column is the tainted source, and the next to last column is the sink. But this does not give the trace from the source to sink. After some manual inspection, for almost all the reports here, the flow seems to be infeasible from the mentioned source to the mentioned sink. Is it the correct way to look at the reports? Or is there a way to automatically build a source-sink information flow path?

I was wondering if LeakingTaintedInformationVars.csv is useful to build any information flow path from the reports using this script? But after running the script, the commands from it don't seem to be doing that either.

Am I missing something here?

[yanniss]

I'm afraid you are not missing anything, in principle. Even if there may be a bug in current PTaint (preventing it from working optimally), what you are observing may be perfectly normal. There is no out-of-the-box support for establishing a source-sink information flow path. (You would need to create intermediate "breadcrumb" objects to do something like that yourself.) And PTaint has no more precision than what the underlying analysis gives it, so if you use 2objH, you have probably maxed out on that. (Again, modulo bugs, since this is functionality we haven't touched in years.)

I've pinged others @nevillegrech @anantoni who may have more to add.