-
Notifications
You must be signed in to change notification settings - Fork 2k
Expand file tree
/
Copy pathFragmentInjection.inc.qhelp
More file actions
60 lines (54 loc) · 2.49 KB
/
FragmentInjection.inc.qhelp
File metadata and controls
60 lines (54 loc) · 2.49 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
<!DOCTYPE qhelp PUBLIC "-//Semmle//qhelp//EN" "qhelp.dtd">
<qhelp>
<overview>
<p>
When fragments are instantiated with externally provided names, this exposes any exported activity that dynamically
creates and hosts the fragment to fragment injection. A malicious application could provide the
name of an arbitrary fragment, even one not designed to be externally accessible, and inject it into the activity.
This can bypass access controls and expose the application to unintended effects.
</p>
<p>
Fragments are reusable parts of an Android application's user interface.
Even though a fragment controls its own lifecycle and layout, and handles its input events,
it cannot exist on its own: it must be hosted either by an activity or another fragment.
This means that, normally, a fragment will be accessible by third-party applications (that is, exported)
only if its hosting activity is itself exported.
</p>
</overview>
<recommendation>
<p>
In general, do not instantiate classes (including fragments) with user-provided names
unless the name has been properly validated.
Also, if an exported activity is extending the <code>PreferenceActivity</code> class, make sure that
the <code>isValidFragment</code> method is overriden and only returns <code>true</code> when the provided
<code>fragmentName</code> points to an intended fragment.
</p>
</recommendation>
<example>
<p>
The following example shows two cases: in the first one, untrusted data is used to instantiate and
add a fragment to an activity, while in the second one, a fragment is safely added with a static name.
</p>
<sample src="FragmentInjection.java" />
<p>
The next example shows two activities that extend <code>PreferenceActivity</code>. The first activity overrides
<code>isValidFragment</code>, but it wrongly returns <code>true</code> unconditionally. The second activity
correctly overrides <code>isValidFragment</code> so that it only returns <code>true</code> when <code>fragmentName</code>
is a trusted fragment name.
</p>
<sample src="FragmentInjectionInPreferenceActivity.java" />
</example>
<references>
<li> Google Help:
<a href="https://support.google.com/faqs/answer/7188427?hl=en">How to fix Fragment Injection vulnerability</a>.
</li>
<li>
IBM Security Systems:
<a href="https://securityintelligence.com/wp-content/uploads/2013/12/android-collapses-into-fragments.pdf">Android collapses into Fragments</a>.
</li>
<li>
Android Developers:
<a href="https://developer.android.com/guide/fragments">Fragments</a>
</li>
</references>
</qhelp>