阅读 4852

WARNING! 配置不当,或导致Kotlin源码泄漏!

自从去年Google扶正了Kotlin,使之成为了Android官方的推荐开发语言,Kotlin便迎来了春天。很多团队/产品也纷纷加入了Kotlin的支持,大厂的应用也很多,社区对Kotlin也是赞不绝口。正在看此文的同学,也相信要么用上Kotlin,要么准备使用Kotlin。

这里,笔者要给大家提个醒:旧项目引入Kotlin,如配置不当,会导致源码泄露!。这意味着我们所做的混淆、加固之类的防护操作都白费了!这可是相当严重的安全问题!

如图。这是笔者在网上闲逛的时候,偶然发现的某应用包内竟然包含了Kotlin的源文件!

妥妥的如假包换的源文件,代码、注释都是全套的。

原因分析

当笔者发现这个情况的时候,内心暗喜:难道笔者不小心挖到了一个Kotlin的大新闻,只要使用了Kotlin,就会被开源?

笔者尝试在本地复现这个场景,但遗憾的是,不管是新版本的Kotlin Plugin还是旧版本的Kotlin Plugin,打出来的包都不包含.kt文件。随后笔者又尝试去应用宝抓取Top50的应用,发现使用了Kotlin的应用虽然多,但也没出现图上的应用一般的代码泄露情况。无法复现,还怎么定位问题的原因?此时陷入了僵局。

后来,笔者查看自家的应用时,发现自家应用引入了Kotlin后,也出现了这样的问题。那这就不是小事了。

排查和定位过程按下不表,直观的结果就是,打出来的APK包里,混入了源代码目录下的.kt源文件。

我们知道,打包过程中,有一个步骤叫做Jar包资源合并,这个步骤会把Jar包内资源合并到一起,打包到apk中。既然APK里包含的.kt文件,那极有可能是合并资源的任务出了问题。

可惜,比对了有问题的项目和正常的项目的build.gradle之后,无奈的发现,即便是同样的GradleKotlin Pluginbuild tools版本,同样的配置,依然无法在正常的项目下复现这个问题。

也就说,gradle的Jar包资源合并任务并不是导致问题的元凶。也是,Gradle如果有问题,社区也早就发现了。

但问题还是得解决,既然是资源被合并打包了,那就找方法做指定资源的排除呗。

这部分的工作是由java plugin干的,那就到文档: The Java Plugin里找答案。

首先看到这个任务:

从描述可知,这个任务就是我们要找的,拷贝资源到jar包的资源目录。

再往下看,项目的默认目录结构:

资源目录是放置在src/main/resources,或对应的src/<代码集>/resources目录内。

如果要自定义资源目录的配置,看这个:

也就是说,这个配置指定了代码集的资源目录的位置。它会排除掉目录内的.java文件,其他的插件,也可能从这里移除掉额外的文件类型。

看到这里,大家也差不多明白了吧?

讲道理,默认生成的项目的目录结构中,资源目录和代码目录是区分开的。既然APK里包含了.kt源代码,那必然是资源目录和代码目录是同一个的情况。

由于java plugin默认会移除资源目录内的.java文件,因此,在以往的打包中,源代码能够被安全的移除掉,不至于导致泄露。

而现在,我们引入Kotlin的时候,会依旧保持原有的代码目录结构,此时代码目录中就混入的.kt文件,由于不属于资源剔除的范围,自然就被当做资源文件打包进APK里了。

在出现了源码泄露的应用里,我还发现了.aidl文件,也就是IPC通讯时定义的接口文件。这类文件的泄露也是同样的原因造成的。

至此,这个源码泄露案,也就告破了。

当然,说告破还有点早,毕竟上面给出的是推测,就算是真理,也是需要检验的。

回到自家工程的build.gradle里一查:

android {
    sourceSets {
        main {
            manifest.srcFile 'AndroidManifest.xml'
            java.srcDirs = ['src']
            resources.srcDirs = ['src']
        }
    }
}
复制代码

果不其然,资源文件所在的目录和源码所在的目录配置成了同一个。

至于出现这个问题原因,笔者反思了一下。这个项目属于比较早期的项目,代码目录结构遵循的是Eclipse时代的规范,后面拥抱变化转Android Studio时,Gradle默认的那套项目布局规范和Eclipse相差较大,为了避免对项目造成大的改动,所以采取了自定义目录配置的做法,用较小的代价,完成了迁移。时过境迁,到了拥抱Kotlin变化的时候,就出问题了。

修复方案

明了问题的所在,定解决方案自然也就方便了:

  1. 方案一:直接移除resources.srcDirs = ['src']配置。
  2. 方案二:为资源目录增加新的提出类型.kt
  3. 方案三:将资源目录和代码目录区分开来,不再混杂在一起。

这些方案里,方案一有点简单粗暴。对Android项目来说,影响倒还好,因为很多资源都是放在assets目录里,工程内很少会放这种资源文件了。

方案二适用于那些资源文件里除了.kt文件之外,还有别的资源文件的情况,传统java开发可能会有这种场景。

方案三是最稳妥,最合乎规范的推荐做法。将资源和代码分开,使得相关文件在物理上保持了隔离,对整个项目来说,整体结构更加清晰。

对笔者这种情况,更好的方式是做一次项目结构的改造,使之符合Gradle的规范。

但归根结底,这个问题属于技术债务。很多时候,我们在开发的过程中,会为了贪图方便,本着尽可能的减少影响面的想法,采取了一种折中的妥协的做法,度过了一时,但往往就埋下了祸根。

短期内没时间,确实可以这么做,但从长期来看,还是要把债务还上的。只是时间的问题罢了。

最后的最后

最后的最后,建议大家自查一下,避免出现和笔者统一的情况。尤其是那些从Eclipse时代转过来的Android项目!

感谢阅读到最后,希望本文对你有所帮助。如果觉得笔者的文章对你有所帮助,还请给个喜欢/感谢/赞。如有纰漏,也请不吝赐教。欢迎大家留言一起讨论。:-)

后记

本文发出后,有朋友留言,指本文有标题党的嫌疑。恕笔者无法苟同。诚然,如有些朋友所言,不就是自己一个配置错了,关Kotlin什么事情,Kotlin乃无辜躺枪。

但笔者认为,这固然不是编程语言的锅,但却是Kotlin工具链上的Kotlin Plugin没兼顾到这种场景导致的安全漏洞。与之相对的Java Plugin对这种场景就处理得周到得多。

虽然最后笔者将问题的原因归根于项目配置导致的问题,但笔者仍然认为,这种情况的发生,Kotlin Plugin也有一定的责任。完善的工具链,能为开发和使用带来极大的便利,Kotlin Plugin也不例外。笔者在Kotlin接入的配置教程里,看到很多人在宣扬Kotlin的引入很方便,方便的背后,却可能会不小心带来这么大的安全隐患,笔者认为,是很有必要提醒使用了Kotlin的各位的。

另外,安全问题的产生,往往都是小细节上的失误导致的,而失误,往往来自于人。爱因斯坦这样说道:“只有两种事物是无穷尽的——宇宙和人类的愚蠢”。

能遇上这个问题的项目,基本都是从Eclipse时代过来的,这样的项目,其具有的价值,料想是不言而喻的。笔者看到,有的同学认为,源码泄露就泄露,爱谁看谁看。个人认为,这是对项目的一种不负责任。

以上。

再更新

之前的标题《使用Kotlin或导致源码泄漏!》,评论指出有蹭热度的嫌疑,参考了承香墨影的推送,改成《配置不当,或导致Kotlin源码泄漏!》,更直观和开门见山。:-)