自从去年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
之后,无奈的发现,即便是同样的Gradle
、Kotlin Plugin
、build 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
变化的时候,就出问题了。
修复方案
明了问题的所在,定解决方案自然也就方便了:
- 方案一:直接移除
resources.srcDirs = ['src']
配置。 - 方案二:为资源目录增加新的提出类型
.kt
。 - 方案三:将资源目录和代码目录区分开来,不再混杂在一起。
这些方案里,方案一有点简单粗暴。对Android
项目来说,影响倒还好,因为很多资源都是放在assets
目录里,工程内很少会放这种资源文件了。
方案二适用于那些资源文件里除了.kt
文件之外,还有别的资源文件的情况,传统java开发可能会有这种场景。
方案三是最稳妥,最合乎规范的推荐做法。将资源和代码分开,使得相关文件在物理上保持了隔离,对整个项目来说,整体结构更加清晰。
对笔者这种情况,更好的方式是做一次项目结构的改造,使之符合Gradle
的规范。
但归根结底,这个问题属于技术债务。很多时候,我们在开发的过程中,会为了贪图方便,本着尽可能的减少影响面的想法,采取了一种折中的妥协的做法,度过了一时,但往往就埋下了祸根。
短期内没时间,确实可以这么做,但从长期来看,还是要把债务还上的。只是时间的问题罢了。
最后的最后
最后的最后,建议大家自查一下,避免出现和笔者统一的情况。尤其是那些从Eclipse
时代转过来的Android项目!
感谢阅读到最后,希望本文对你有所帮助。如果觉得笔者的文章对你有所帮助,还请给个喜欢/感谢/赞。如有纰漏,也请不吝赐教。欢迎大家留言一起讨论。:-)
后记
本文发出后,有朋友留言,指本文有标题党的嫌疑。恕笔者无法苟同。诚然,如有些朋友所言,不就是自己一个配置错了,关Kotlin什么事情,Kotlin乃无辜躺枪。
但笔者认为,这固然不是编程语言的锅,但却是Kotlin工具链上的Kotlin Plugin
没兼顾到这种场景导致的安全漏洞。与之相对的Java Plugin
对这种场景就处理得周到得多。
虽然最后笔者将问题的原因归根于项目配置导致的问题,但笔者仍然认为,这种情况的发生,Kotlin Plugin
也有一定的责任。完善的工具链,能为开发和使用带来极大的便利,Kotlin Plugin
也不例外。笔者在Kotlin接入的配置教程里,看到很多人在宣扬Kotlin
的引入很方便,方便的背后,却可能会不小心带来这么大的安全隐患,笔者认为,是很有必要提醒使用了Kotlin
的各位的。
另外,安全问题的产生,往往都是小细节上的失误导致的,而失误,往往来自于人。爱因斯坦这样说道:“只有两种事物是无穷尽的——宇宙和人类的愚蠢”。
能遇上这个问题的项目,基本都是从Eclipse
时代过来的,这样的项目,其具有的价值,料想是不言而喻的。笔者看到,有的同学认为,源码泄露就泄露,爱谁看谁看。个人认为,这是对项目的一种不负责任。
以上。
再更新
之前的标题《使用Kotlin或导致源码泄漏!》,评论指出有蹭热度的嫌疑,参考了承香墨影的推送,改成《配置不当,或导致Kotlin源码泄漏!》,更直观和开门见山。:-)