使用Android共享存储时潜在的竞争状态检测方法和系统

使用android共享存储时潜在的竞争状态检测方法和系统
技术领域
1.本发明涉及共享存储安全技术领域，尤其涉及一种使用android共享存储时潜在的竞争状态检测方法和系统。


背景技术：

2.如今，为了满足不同应用程序的存储需求，智能手机的存储容量快速增长。在android中，存储在逻辑上分为两部分：内部存储和外部存储(即共享存储)。共享存储已经成为应用程序存储和共享数据的重要媒介，但是对于共享存储的保护有限，这使得共享存储面临着一系列安全问题。目前大量工作研究已经指出了存储的文件会泄漏用户的敏感信息并将受害用户暴露给攻击者，这表明共享存储的安全问题非常严重。
3.遗憾的是，与共享存储的安全问题相比，应用开发者在开发时更加关注应用的新颖功能，以吸引更多用户。因此，即使应用程序开发人员提出了一些方法来处理共享存储的安全问题，但解决方案可能没有他们预期的那么有效。由于文件操作可能没有得到精心的组织，这可能会引入一些潜在的竞争状态，导致文件内容在真正的应用程序使用它之前被恶意应用程序操纵。因此，真实应用程序会被诱导执行一些非预期行为，泄露用户隐私，造成财产损失，甚至使用户处于危险之中。


技术实现要素：

4.为了能够获知目前android共享存储所存在的安全问题以便开发出更加安全的应用程序，本发明提供一种使用android共享存储时潜在的竞争状态检测方法和系统。
5.一方面，本发明提供一种使用android共享存储时潜在的竞争状态检测方法，包括：
6.步骤1：利用android.os.fileobserver监控并记录android终端的共享存储上的文件操作；其中，每个文件操作的记录信息包括：目标文件路径、操作事件类型和发生时间；
7.步骤2：根据目标文件路径和发生时间对所有文件操作进行排序和聚类，得到若干种文件组织模式和若干种文件操作模式；
8.步骤3：构建竞争状态验证模型；
9.步骤4：从步骤2得到的聚类结果中，选择一种文件组织模式和一种文件操作模式，在给定文件组织模式和给定文件操作模式下，利用构建好的竞争状态验证模型验证共享存储上的文件是否存在潜在竞争状态的安全问题。
10.进一步地，步骤2具体包括：
11.步骤2.1：根据目标文件路径和发生时间对所有文件操作进行排序和聚类，得到每个文件的操作事件序列，并过滤掉只有一个操作事件的文件；
12.步骤2.2：对每个文件的操作事件序列进行预处理，以将每个文件的所述操作事件序列处理为短序列列表s＝{si|i∈{1,m}}；si表示短序列列表s中的第i个操作序列；
13.步骤2.3：针对每个文件的短序列列表s，检测所述短序列列表s中任意相邻两个操
作序列之间的时间间隔，根据时间间隔得到该文件的文件操作模式；
14.步骤2.4：针对每个文件，判断其文件名是否为随机化文件名，若为随机化文件名，则采用给定的文件命名模式对所述文件进行重命名，根据该文件的新文件名得到该文件的文件组织模式。
15.进一步地，步骤2.2具体包括：
16.步骤a1：初始化列表s
filtered
、列表s
temp
、列表s和栈stack
open
；其中，s
filtered
用于保存过滤后的文件序列，s
temp
用于保存当前文件操作序列，s用于保存短文件操作序列，stack
open
用于关联open和close事件；
17.步骤a2：循环遍历原始文件操作序列s
raw
；将所有非open、非close事件进行去重；将去重后的结果与所有open、close事件一并保存至列表s
filtered
中；
18.步骤a3：循环遍历s
filtered
，以步骤a4至步骤a7作为一次循环；
19.步骤a4：判断当前文件操作事件ej与其相邻事件e
j-1
之间的时间间隔t
j-1,j
是否大于预设时长：若t
j-1,j
不大于第一预设时长，则将ej添加到s
temp
中；否则，将s
temp
添加到s中，并重置s
temp
和stack
open
，再将ej添加到s
temp
中；
20.步骤a5：判断文件操作事件ej是否为open事件或close事件：若为open事件，则跳转到步骤a6；若为close事件，则跳转到步骤a7；
21.步骤a6：将ej入栈栈stack
open
；
22.步骤a7：判断stack
open
是否为空：若stack
open
不为空，则出栈一个元素，若出栈后stack
open
为空，则将s
temp
添加到s中并重置s
temp
；若stack
open
为空，则继续判断先前获得的序列s
last
∈s是否可以添加更多的事件：若可以，则将剩下的事件都添加到s
last
中并重置s
temp
；否则，将剩下的序列s
temp
添加到s中并重置s
temp
；
23.步骤a8：遍历完s
filtered
中的所有事件之后，得到一个包含若干短操作序列的列表s＝{si|i∈{1,m}}。
24.进一步地，步骤2.3具体包括：
25.步骤b1：初始化文件操作模式集合p和当前文件操作模式序列p
current
；
26.步骤b2：循环遍历列表s中的每个文件操作序列si，以步骤b3至步骤b6作为一次循环；
27.步骤b3：判断p是否为空：若p为空，则将si添加到p
current
中，并将p
current
添加到p中；若p不为空，则执行步骤b4；
28.步骤b4：获取p中最近一次添加的文件操作模式p
last
，判断当前的si与p
last
之间的时间间隔是否小于第二预设时长：若小于，则执行步骤b5；否则，执行步骤b6；
29.步骤b5：判断p
last
是否可以追加更多的文件操作事件：若可以，则将si追加到p
last
中；否则，将si赋值给p
current
并将p
current
添加到p中；
30.步骤b6：设置p
last
不能再添加任何文件操作事件，将si赋值给p
current
并将p
current
添加到p中；
31.步骤b7：遍历完列表s中的所有序列之后，再次遍历此时得到的p中的每种文件操作模式，对比当前文件操作模式中的open和close事件的数量是否相等，若不相等，则删除该文件操作模式；
32.步骤b8：按照步骤b8遍历完p中的所有文件操作模式之后，得到最终的文件操作模
式集合p。
33.进一步地，步骤2.4具体包括：
34.步骤c1：若文件名的长度小于给定的长度阈值或者文件名中不包含字母，则该文件的文件名为随机化文件名；否则继续执行步骤c2；
35.步骤c2：根据landmark point将文件名划分为若干个子串；其中，landmark point表示属于除字母和数字外的其他特殊字符所在的位置；
36.步骤c3：针对每个子串，统计其包含的switch point的数量count
switch
和sharp point的数量count
sharp
，若不小于第一给定阈值或者count
sharp
不小于第二给定阈值，则所述子串名为随机化子串名；其中，switch point表示当前字符从字母变为数字时所在的位置，或者当前字符从数字变为字母时所在的位置；sharp point表示当前字符属于字母而其相邻字符属于数字时所在的位置，或者当前字符属于字母而其相邻字符属于数字时所在的位置；
37.步骤c4：针对每个随机化子串名，采用给定的文件命名模式进行重命名；针对非随机化子串名，继续采用原子串名；
38.步骤c5：针对每个文件，将其所有子串的名称重新组合得到该文件的新文件名。
39.进一步地，步骤3中的所述竞争状态验证模型的验证过程具体包括：
40.步骤3.1：给定文件组织模式，在android终端的共享存储上搜索属于所述文件组织模式的文件，根据搜索到的文件生成用于发起基于竞争状态攻击的假文件；
41.步骤3.2：监控android终端的共享存储上的文件操作，根据获取的文件操作事件和选择的文件操作模式，采用假文件替换掉原始文件；
42.步骤3.3：当原始文件被替换掉之后，检测与所述原始文件相关的应用程序的功能是否正常，若选定的文件操作模式中的所有时间窗口的检测结果均正常，则认为不存在竞争状态。
43.另一方面，本发明提供一种使用android共享存储时潜在的竞争状态检测系统，包括客户端和服务器；
44.所述客户端，运行在android终端，用于利用android.os.fileobserver监控并记录所述android终端的共享存储上的文件操作并将记录信息上传至所述服务器；其中，每个文件操作的记录信息包括：目标文件路径、操作事件类型和发生时间；
45.所述服务器，接收并保存来自所有所述客户端的记录信息；根据目标文件路径和发生时间对所有文件操作进行排序和聚类，得到若干种文件组织模式和若干种文件操作模式；构建竞争状态验证模型，在给定文件组织模式和给定文件操作模式下，利用构建好的竞争状态验证模型验证共享存储上的文件是否存在潜在竞争状态的安全问题。
46.本发明的有益效果：
47.本发明提供的潜在竞争状态检测方法和系统可以有效检测出android终端共享存储上潜在的竞争状态，这就为应用程序开发人员在使用android共享存储时所应考虑的安全问题提供了参考，从而提高android终端共享存储文件的安全性。
附图说明
48.图1为本发明实施例提供的使用android共享存储时潜在的竞争状态检测方法的流程示意图；
49.图2为本发明实施例提供的共享存储上的文件操作事件和时间之间的关系示意图；
50.图3为本发明实施例提供的文件操作事件的记录日志示意图；
51.图4为本发明实施例提供的一个随机化文件名以及对其进行重新命名的示意图；
52.图5为本发明实施例提供的使用android共享存储时潜在的竞争状态检测系统的结构示意图；
53.图6为本发明实施例提供的收集数据中各种文件操作事件的占比示意图；
54.图7为本发明实施例提供的不同数量的“close_nowrite”事件的文件数量示意图；
55.图8为本发明实施例提供的前200个文件组织模式的统计图；
56.图9为本发明实施例提供的包含不同数量文件操作模式的文件占总文件百分比的示意图；
57.图10为本发明实施例提供的不同文件操作模式中时间窗口大小的统计图；
58.图11为本发明实施例提供的仅有一个线程对文件进行操作的示意图。
具体实施方式
59.为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
60.如图1所示，本发明实施例提供一种使用android共享存储时潜在的竞争状态检测方法，包括以下步骤：
61.s101：利用android.os.fileobserver监控并记录android终端的共享存储上的文件操作；其中，每个文件操作的记录信息，如表1所示，包括：目标文件路径、操作事件类型和发生时间；
62.表1收集文件操作事件的数据项
[0063][0064]
具体地，代码分析方法是了解一个应用程序的工作机制所常用的传统分析方法，但是由于某些原因该方法却不太适用于获取共享存储上文件操作的详细信息，如：1)文件处理代码可能来自外部或第三方库，无法提前获得；2)发布的apk文件中的代码可能被混淆
或脱壳，难以进行代码分析；3)目标文件路径信息可能来自互联网或经过加密，难以准确识别真实目标文件；4)代码分析方法无法提供有关文件操作的任何时间信息等。因此，本发明实施例中采用android.os.fileobserver监控并记录android终端的共享存储上的文件操作。如图4所示，android.os.fileobserver可以直接获取到文件在何处、何时以及如何操作等信息。
[0065]
s102：根据目标文件路径和发生时间对所有文件操作进行排序和聚类，得到若干种文件组织模式和若干种文件操作模式；
[0066]
具体地，本步骤具体包括以下子步骤：
[0067]
s1021：根据目标文件路径和发生时间对所有文件操作进行排序和聚类，得到每个文件的操作事件序列，并过滤掉只有一个操作事件的文件；
[0068]
具体地，单个文件操作事件e无法得到用于分析潜在竞争状态的足够信息。值得注意的是，当应用程序读取或写入文件时，它会触发一系列操作事件s
raw
＝{ei|i∈{1,n}}，如图2和表2所示。因此，一旦建立了文件操作事件序列s
raw
，就可以推断出应用程序想要如何处理该文件。如图3所示，根据发生时间和文件绝对路径对所有文件操作进行排序和聚类可以重建得到文件操作事件序列。
[0069]
表2行为和相关的文件操作事件
[0070][0071]
表2中，1这些文件操作事件来源于android 9，不同的android版本在文件操作事件上只有很小的差异；2文件操作事件attrib在某些android版本中可能不会出现；3标记'*'表示相关的事件可能出现不止一次。
[0072]
s1022：对每个文件的操作事件序列进行预处理，以将每个文件的所述操作事件序列处理为短序列列表s＝{si|i∈{1,m}}；si表示短序列列表s中的第i个操作序列；
[0073]
具体地，一个应用程序多次操作一个文件是很常见的(例如，每次应用程序被激活)，这会导致一个很长的文件操作事件序列。为了更好地理解这个文件上的每个操作，需要对获取的长文件操作事件序列s
raw
进行预处理。
[0074]
s1023：针对每个文件的短序列列表s，检测所述短序列列表s中任意相邻两个操作序列之间的时间间隔，根据时间间隔得到该文件的文件操作模式；
[0075]
具体地，结合文件操作事件的关系，步骤s1022已经将长文件操作序列s
raw
拆分为短序列s＝{si|i∈{1,m}}。然而由于很少考虑时间信息，这些短序列仍然无法支持进一步分析。如图2所示，当一个功能被激活时，相关文件会在短时间内被连续操作，这些事件之间的时间间隔不会太长。时间信息在提取文件操作模式中起着重要作用。因此，本步骤在提取文件操作模式时，充分利用了时间信息。
[0076]
s1024：针对每个文件，判断其文件名是否为随机化文件名，若为随机化文件名，则采用给定的文件命名模式对所述文件进行重命名，根据该文件的新文件名得到该文件的文件组织模式。
[0077]
s103：构建竞争状态验证模型；
[0078]
s104：从步骤s102得到的聚类结果中，选择一种文件组织模式和一种文件操作模式，在给定文件组织模式和给定文件操作模式下，利用构建好的竞争状态验证模型验证共享存储上的文件是否存在潜在竞争状态的安全问题。
[0079]
在上述实施例的基础上，本发明实施例中，作为一种可实施方式，上述实施例中的步骤s1022具体包括以下子步骤：
[0080]
步骤a1：初始化列表s
filtered
、列表s
temp
、列表s和栈stack
open
；其中，s
filtered
用于保存过滤后的文件序列，s
temp
用于保存当前文件操作序列，s用于保存短文件操作序列，stack
open
用于关联open和close事件；
[0081]
步骤a2：循环遍历原始文件操作序列s
raw
；将所有非open、非close事件进行去重；将去重后的结果与所有open、close事件一并保存至列表s
filtered
中；
[0082]
步骤a3：循环遍历s
filtered
，以步骤a4至步骤a7作为一次循环；
[0083]
步骤a4：判断当前文件操作事件ej与其相邻事件e
j-1
之间的时间间隔t
j-1,j
是否大于预设时长：若t
j-1,j
不大于第一预设时长，则将ej添加到s
temp
中；否则，将s
temp
添加到s中，并重置s
temp
和stack
open
，再将ej添加到s
temp
中；
[0084]
步骤a5：判断文件操作事件ej是否为open事件或close事件：若为open事件，则跳转到步骤a6；若为close事件，则跳转到步骤a7；
[0085]
步骤a6：将ej入栈栈stack
open
；
[0086]
步骤a7：判断stack
open
是否为空：若stack
open
不为空，则出栈一个元素，若出栈后stack
open
为空，则将s
temp
添加到s中并重置s
temp
；若stack
open
为空，则继续判断先前获得的序列s
last
∈s是否可以添加更多的事件：若可以，则将剩下的事件都添加到s
last
中并重置s
temp
；否则，将剩下的序列s
temp
添加到s中并重置s
temp
；
[0087]
步骤a8：遍历完s
filtered
中的所有事件之后，得到一个包含若干短操作序列的列表s＝{si|i∈{1,m}}。
[0088]
具体地，预处理过程主要包括两个步骤：1)合并连续重复的文件操作事件；2)拆分文件操作序列。
[0089]
1)合并连续重复的文件操作事件。在获取的文件操作事件中，可以看到，当一个应用程序读写文件时，会发生一些access或modify操作事件。虽然这些操作事件可以反映应用程序的意图，但许多不断重复的access或modify操作事件将导致不同的文件操作模式，使进一步分析变得复杂。
[0090]
值得注意的是，在大多数情况下，access或modify事件的数量是由操作系统决定
的。以modify操作事件为例，无论应用程序如何写入文件，只有在数据真正写入物理存储介质时才会发生modify事件。
[0091]
由于open、close(包括close_nowrite和close_write)事件可以提供一些关于潜在竞争状态的线索，正如步骤a2所示。除了open、close_nowrite和close_write操作事件，本步骤将连续重复的同一类型操作事件的数量减少为一个。
[0092]
2)拆分文件操作序列。拆分文件操作顺序。如图2所示，当应用程序操作文件时，open和close事件依次出现。在这一部分，充分利用了open和close事件之间的这种关系来拆分文件操作序列(如步骤a4和a5所示)。
[0093]
但是，还有一个情况需要考虑，即：客户端可能会偶尔停止工作，这会错过一些文件操作事件。当错过open和close操作事件时，很难将所有获得的open和close操作事件耦合起来，这会导致序列不完整，步骤a7处理了这个问题。
[0094]
如果先前获得的序列s
last
可以附加更多的文件操作事件，将不完整的序列附加到前一个s
last
。否则，只需将其放入s。如果客户端或文件所有者应用程序停止一段时间(例如，10分钟)，则两个操作事件e
j-1
和ej之间的时间间隔t
j-1,j
将长于10分钟。在这种情况下，e
j-1
和ej不属于同一个文件操作序列。正如步骤a4所示，提前处理了这个案例。
[0095]
在上述各实施例的基础上，本发明实施例中，作为一种可实施方式，上述步骤s1023具体包括以下子步骤：
[0096]
步骤b1：初始化文件操作模式集合p和当前文件操作模式序列p
current
；
[0097]
步骤b2：循环遍历列表s中的每个文件操作序列si，以步骤b3至步骤b6作为一次循环；
[0098]
步骤b3：判断p是否为空：若p为空，则将si添加到p
current
中，并将p
current
添加到p中；若p不为空，则执行步骤b4；
[0099]
步骤b4：获取p中最近一次添加的文件操作模式p
last
，判断当前的si与p
last
之间的时间间隔是否小于第二预设时长：若小于，则执行步骤b5；否则，执行步骤b6；
[0100]
步骤b5：判断p
last
是否可以追加更多的文件操作事件：若可以，则将si追加到p
last
中；否则，将si赋值给p
current
并将p
current
添加到p中；
[0101]
步骤b6：设置p
last
不能再添加任何文件操作事件，将si赋值给p
current
并将p
current
添加到p中；
[0102]
步骤b7：遍历完列表s中的所有序列之后，再次遍历此时得到的p中的每种文件操作模式，对比当前文件操作模式中的open和close事件的数量是否相等，若不相等，则删除该文件操作模式；
[0103]
步骤b8：按照步骤b8遍历完p中的所有文件操作模式之后，得到最终的文件操作模式集合p。
[0104]
具体地，一旦两个文件操作序列si和s
i 1
之间的时间间隔t
i,i 1
小于第二预设时长(例如，第二预设时长＝5秒)，则需要将si和s
i 1
加入到同一个文件操作模式(见步骤b5)。否则，si和s
i 1
属于不同的操作模式(见步骤b6)。另外，考虑到上面谈到的丢失文件操作事件，本实施例中过滤掉了不完整的文件操作模式(见步骤b7)。
[0105]
在上述各实施例的基础上，本发明实施例中，作为一种可实施方式，上述步骤s1024具体包括以下子步骤：
[0106]
步骤c1：若文件名的长度小于给定的长度阈值或者文件名中不包含字母，则该文件的文件名为随机化文件名；否则继续执行步骤c2；
[0107]
步骤c2：根据landmark point将文件名划分为若干个子串；其中，landmark point表示属于除字母和数字外的其他特殊字符所在的位置；landmark point这种类型的点可以指示文件名的结构，这是因为在大多数情况下它们用于链接不同的字符串。
[0108]
步骤c3：针对每个子串，统计其包含的switch point的数量count
switch
和sharp point的数量count
sharp
，若不小于第一给定阈值或者count
sharp
不小于第二给定阈值，则所述子串名为随机化子串名；其中，switch point表示当前字符从字母变为数字时所在的位置，或者当前字符从数字变为字母时所在的位置，例如“a0”、“9c”，由于字母和数字随机出现，这将会导致一系列switch point。sharp point表示当前字符属于字母而其相邻字符属于数字时所在的位置，或者当前字符属于字母而其相邻字符属于数字时所在的位置，例如“a7d”、“8c4”。
[0109]
具体地，对于一个长字符串，即使没有随机化，仍然可以有多个switch points。因此，在本步骤中，使用作为指标，而不是直接使用count switc
h。
[0110]
步骤c4：针对每个随机化子串名，采用给定的文件命名模式进行重命名；针对非随机化子串名，继续采用原子串名；
[0111]
例如，如果一个子串是随机生成的，我们就用“*[n]”标记来缩短它，其中n表示字符数。否则，我们保留原始内容。在这个过程中，landmarkpoints仍然存在。如图4所示，我们建立了一个文件命名模式。值得注意的是，文件路径包含目录名和文件名，我们可以通过为文件路径的每个部分构建命名模式来获取文件的组织模式。至此我们能够了解应用程序开发人员如何组织共享存储上的文件，并且可以进一步组织获得的数据。
[0112]
步骤c5：针对每个文件，将其所有子串的名称重新组合得到该文件的新文件名。
[0113]
具体地，文件操作事件发生在各种文件上。分析所有文件是一项繁重的工作。为了应对这一挑战，在步骤s1021中已经对这些文件进行了分类。通过分类结果发现，在一个目录中，具有相似命名模式的文件共享相似的文件进程。同时对于一些目录，应用程序会根据不同的android终端设备和不同的用户给出不同的文件名。考虑到操作事件来自不同的android终端设备，则需要了解每个文件的命名模式，以便能够在此基础上进行进一步的分类任务。
[0114]
通过对收集到的文件名的调查，发现文件名可以分为两类：(1)用有意义的词命名，如“login”、“wallet”、“purchase”等；(2)用一些算法(如md5算法)根据一些线索(如用户id或设备id)动态生成的字符串命名。分析第一种情况是相对容易的，因为该情况可以充分利用文件系统中相同字符串和相同位置的特性；但第二种情况的分析过程则存在较大难度，本步骤则主要解决了该困难。
[0115]
第二种情况的文件名由随机数字c
number
、随机字母c
letter
以及一些特殊标记c
mark
(例如“*”、“_”、
“‑”
等)组成。由于很难预测字母出现在哪里或数字出现在哪里，因此本实施例尝试使用一些统计指标来判断文件名是否是随机的。
[0116]
图4中，对switch point、sharp point和landmark point进行了示意。
[0117]
在上述各实施例的基础上，本发明实施例中，作为一种可实施方式，上述步骤s103
具体包括以下子步骤：
[0118]
s1031：给定文件组织模式，在android终端的共享存储上搜索属于所述文件组织模式的文件，根据搜索到的文件生成用于发起基于竞争状态攻击的假文件；
[0119]
s1032：监控android终端的共享存储上的文件操作，根据获取的文件操作事件和选择的文件操作模式，采用假文件替换掉原始文件；
[0120]
s1033：当原始文件被替换掉之后，检测与所述原始文件关联的应用程序的功能是否正常，若选定的文件操作模式中的所有时间窗口的检测结果均正常，则认为不存在竞争状态。
[0121]
实施例2
[0122]
对应上述的使用android共享存储时潜在的竞争状态检测方法，本发明实施例还提供一种使用android共享存储时潜在的竞争状态检测系统，如图5所示，包括：客户端和服务器；
[0123]
所述客户端，运行在android终端，用于利用android.os.fileobserver监控并记录所述android终端的共享存储上的文件操作并将记录信息上传至所述服务器；其中，每个文件操作的记录信息包括：目标文件路径、操作事件类型和发生时间；
[0124]
所述服务器，接收并保存来自所有所述客户端的记录信息；根据目标文件路径和发生时间对所有文件操作进行排序和聚类，得到若干种文件组织模式和若干种文件操作模式；构建竞争状态验证模型，在给定文件组织模式和给定文件操作模式下，利用构建好的竞争状态验证模型验证共享存储上的文件是否存在潜在竞争状态的安全问题。
[0125]
具体地，所述服务器包括数据收集模块、数据过滤模块、数据链接模块、数据排序聚类模块和数据分析模块；其中，数据收集模块接收并保存来自所有所述客户端的记录信息；数据过滤模块过滤掉记录信息中的噪声数据；数据链接模块将过滤后的操作事件根据目标文件路径链接；数据排序聚类模块根据目标文件路径和发生时间对所有文件操作进行排序和聚类；数据分析模块根据排序聚类结果进行分析得到若干种文件组织模式和若干种文件操作模式；以及构建竞争状态验证模型，在给定文件组织模式和给定文件操作模式下，利用构建好的竞争状态验证模型验证共享存储上的文件是否存在潜在竞争状态的安全问题。
[0126]
需要说明的是，本发明实施例提供的潜在竞争状态检测系统是为了实现上述方法实施例的，其功能具体可参考上述方法实施例，此处不再赘述。
[0127]
为了验证本发明方法的有效性，本发明还提供有下述实验数据。
[0128]
(1)收集数据：在10天内持续跟踪10位志愿者智能手机上的文件操作。在志愿者的智能手机上安装并激活客户端，客户端将在后台运行以监控整个android共享存储，并且不影响志愿者智能手机的正常使用。总共收集了5359339个文件操作事件，超过105963个文件。获得的数据集的详细信息如表3所示。
[0129]
表3数据集详细信息
[0130][0131]
表3中，私有目录和公共目录都在共享存储上；“open”事件表示要读取或写入文件。“close_nowrite”事件表示仅读取文件。
[0132]
需要说明的是，在实验中，不会收集任何个人身份信息(pii)，而只收集相关信息，如表1所示。使用随机id来区分设备，随机id是在客户端首次运行在志愿者的智能手机上时生成的，并且无需获取手机上的任何硬件信息。当利用文件名对相关的文件操作事件进行分类时，我们不会试图收集和使用志愿者智能手机上的任何文件内容。在本实验中，我们仅提供有关共享存储竞争状态问题的一些统计信息，而不提供有关受害应用程序和文件的任何进一步信息。当我们试图验证和利用潜在的竞争状态时，所有的实验都是在我们的测试智能手机上进行的。
[0133]
(2)文件操作事件的类型：如图6所示，当应用程序使用共享存储时，会引入各种类型的文件操作事件，采集到的数据集由各种不同类型的文件操作事件组成。通过统计，在这些文件操作事件中，前5种文件操作事件是modify(40％)、access(28％)、open(11％)、close_nowrite(10％)和close_write(7％)。这几种文件操作事件所有操作事件的97％。可以看到modify和access操作事件的数量都远高于其他事件，这是因为有限的用户空间缓存使得应用程序不断重复相同的操作(例如，修改或访问)来处理整个文件内容。同时，应用程序选择是否立即将数据写入硬盘也会影响modify事件的数量。
[0134]
此外，直观上，open事件的数量应该等于close_nowrite和close_write事件的总数。但是，通过分析收集数据发现open事件的数量远少于close_nowrite和close_write事件的总数。这是因为，当客户端在后台运行时，智能手机可能会停止它以节省能源。在这种情况下，客户端会在手动重启之前错过部分文件操作事件。
[0135]
(3)文件操作事件的发生位置：android在共享存储上引入了两种目录(即/storage/emulated/0/)：公共目录(例如/picture/)和私有目录(例如/android/data/app_package_name/)。如表3所示，有74.2％(78619)的文件访问位于私有目录中，有25.8％(27344)的文件访问位于公共目录中。
[0136]
同时，当一个文件被处理时，它会引入一些modify或access事件。为了了解文件的使用频率，我们对open事件进行了单独统计，如表3所示。此外，为了了解文件被读取的频率，我们还对close_nowrite事件进行了单独统计，根据统计结果可以得到最少的文件读取操作次数。从这两个统计数据中，我们可以看到公共目录中的文件的使用频率与私有目录中的文件一样频繁，这表明公共目录仍然是应用程序最常见的选择。需要注意的是，被授予权限的应用程序仍然可以操作共享存储上的任何文件，在以下部分中除非有详细说明，否则不明确区分公共目录和私有目录，将两者都称为“共享存储”。
[0137]
(4)目标文件路径：尽管数据集由来自不同智能手机的数据组成，但仍有一小部分文件(8411,7.94％)在不同智能手机上具有相同的路径，很大一部分文件(97552，92.06％)
则使用不同的路径，这意味着开发人员在命名和组织文件时遵循自己的标准。
[0138]
通过对不同文件的close_nowrite事件进行分析，可以知道大多数的文件内容只是未经任何修改就被访问了。如图7所示，在大量文件中对每个文件的操作次数非常有限，不利于进一步的分析，为了解决这个问题，必须充分了解我们获得的每条完整路径。
[0139]
(5)文件名的命名模式：应用程序运行的文件太多，应用程序开发人员不可能手动为每个文件命名，考虑到应用程序开发人员是按照自己的命名模式来命名文件和目录，本部分对文件名称和目录名称进行了分析。结果如表4所示。
[0140]
由表3可知，文件名称大部分(96.28％)由字母(即a-z和a-z)、数字(即0-9)以及其他特定符号组成，只有小部分名称仅由单个字符组成，例如，案例1(0.89％)、案例2(2.81％)和案例4(0.02％)。在这些案例中，根据调查，案例4中的名字实际上是由非英文字符组成的，比如中文。显然，获取每个应用程序命名模式的详细信息比较困难。
[0141]
表4文件名的不同组织方式
[0142][0143]
(6)文件组织模式：在第(5)部分中提及动态随机命名规则对理解所获得文件的关系提出了很大的挑战。因此，要了解这些文件是如何组织的，必须首先处理动态随机命名规则。考虑到文件的绝对路径包含目录名和文件名，通过为该文件路径的每个部分重新构建命名模式来构建相关的组织模式。
[0144]
一个应用程序有一个统一标准来组织不同智能手机上的文件，因此当不同的文件共享相同的组织模式时，它们主要属于一个类别。在97552个文件中，每个文件都有唯一的文件路径，我们得到10395个组织模式。从图8中可以看出，前200个组织模式中的每个组织模式至少覆盖了64个文件，前200个组织模式总共覆盖了72200个(74.01％)文件，充分说明了这些获得的组织模式的有效性。根据这些组织模式，我们对这些文件进行分类。
[0145]
但是，由于一些特殊的命名模式，仍然有7974(8.17％)个组织模式，每个模式只能覆盖一个文件。这种情况下的文件需要更多的精力来分析相关的操作。为了解决该问题，通过分离的文件操作事件，我们可以了解到一些信息。在这部分中，我们根据事件发生的时间构建文件操作序列，以进一步了解潜在的竞争状态。
[0146]
(7)文件操作模式：应用程序仅在激活特殊功能时才操作文件，并且该功能通常会定期激活。因此，我们将文件操作序列拆分为短片，以提取相关的操作模式。值得注意的是，正在运行的客户端可能会错过一些操作事件。但是考虑到open和close事件是成对出现的，操作一个文件不会花费太多时间，我们可以进一步过滤掉不完整的文件操作模式。
[0147]
从图9中可以看出，在大多数情况下，一个文件只是被一个操作模式处理过，这表明该文件只被单个函数使用。事实上，有时不同的函数(或应用程序)可能会操作同一个文件，因此也有许多文件具有多种(从2种到103种)操作模式。而且，当一个文件同时被不同的函数操作时，文件操作模式的数量会显著增加。
[0148]
在获得的文件操作模式中，如表5所示，最常见的是打开文件然后直接读取，即案例1。
[0149]
表5前30个文件操作模式
[0150]
[0151][0152]
前面提及到在提取文件操作模式时，操作事件是根据间隔时间的大小进行拆分的，因此既使对于案例1来说，竞争状态存在的可能性也很高。其他只有一个open事件的情况也是如此。如图10所示，在这些案例中我们除了单个open事件的情况外，进一步研究了其余情况下的时间窗，我们发现相当数量的时间窗足以让第三方应用程序对文件进行一些操作。21.41％的时间窗大于500ms，整个时间窗的平均值为1593ms。我们将在后续环节手工验证潜在的竞争状态。
[0153]
同时，在案例2、3、4中，可以看到一些文件在读取其内容时被读取了两次以上。在这些情况下，表5中标记的open事件之间的时间间隔也表明了潜在竞争状态的存在。
[0154]
(8)多线程的影响：大多数情况下，应用程序在操作文件时，为了保持文件内容的完整性，需要先完成当前的动作，然后才能进行后续的动作，如图11所示当只有一个线程操
作文件时的情况。但是这仍然无法避免文件内容被多个线程同时访问，如表5中的案例22,24,26,27。当多个线程同时操作一个文件时，由于缺乏同步处理，这将产生一系列的文件操作模式，而缺乏有序的、稳定的操作模式。由于难以确定每个操作事件的所有者，因此检查潜在的竞争状态非常具有挑战性。而从已得到的操作模式可以看出，时间窗口在open事件之前是很常见的。由于我们对应用程序处理文件的具体细节知之甚少，因此采用检查每个时间窗口的方式，以确定该时间窗口是否会存在潜在的竞争状态，并且以此尽量避免多线程所带来的影响。
[0155]
(9)构建竞争状态验证模型并验证，过程如下：
[0156]
准备假文件。每个函数对操作的文件都会有一些特殊的要求，我们很难提前知道具体的要求。为了解决这个问题，我们充分利用了具有相同文件组织模式的现有文件。一旦选择了一个文件组织模式，就会在整个android共享存储中搜索具有相同文件组织模式的文件，并利用这些文件生成用于发起攻击的假文件。
[0157]
替换原文件。一旦假文件准备就绪，我们就开始监控android共享存储上具有相同文件组织模式的文件。根据获取的文件操作事件和选择的文件操作模式，通过替换原始文件，自动对时间窗进行一一测试。我们采用文件操作move_to和move_from来减少替换文件的时间成本。
[0158]
检查相关应用程序随后的工作流程。当原始文件被替换时，我们检查相关应用程序是否受到篡改文件的影响。事实上，一旦相关的应用程序接受了被篡改的文件内容，其功能就会受到影响。因此，按照这个思路来判断被篡改的文件是否会影响应用程序的正常功能，从而获知是否存在竞争状态。如果此次尝试失败，我们将检查所选文件操作模式中的下一个时间窗口。当所有时间窗口的尝试都失败时，我们认为竞争状态不存在。
[0159]
(10)手工验证结果。在上述的验证模型的基础上，我们对共享存储上的文件进行了一些手工实验。我们注意到不同的文件对相关的应用程序有着不同的影响，其中一些影响是可以观察到的，而另一些则不是。由于获取应用程序处理和使用每种文件的全部细节是一项工作量庞大的工作，因此我们随机选择了33种文件，来验证潜在的竞争状态。这些文件的影响都是可观察的。根据验证结果，我们发现有31种文件(93.94％)存在竞争状态的安全问题。一个应用程序可能会多次打开一个文件，但是每次是为了不同的目的(例如，检查文件格式、文件完整性，使用文件内容)，因此这些open事件之间就潜藏着一定的竞争状态。除此之外，当文件在不同的应用程序之间进行共享时，竞争状态也非常常见。但是连续的open事件会使得时间窗口太小而无法对文件内容进行相应操作。正是这种原因导致了验证过程在剩余2种文件上的失败。
[0160]
由此可以看出，本发明提供的潜在竞争状态检测方法和系统可以检测出android终端共享存储上潜在的竞争状态，这就为应用程序开发人员在使用android共享存储时所应考虑的安全问题提供了参考，从而提高android终端共享存储文件的安全性。
[0161]
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。