7. INFERENCE RULES TO DETECT WEBVIEW BASED
VULNERABILITIES
7.1
INTRODUCTION
Web-based applications receive content from their web servers using
the standard HTTP protocol, display them and allow users to interact with
those contents. The most difficult challenge faced by Smartphone application
developers is that they are forced to compete with a wide range of
Smartphone and operating system (OS) platforms. The developers get
overwhelmed with demands to find a link between the communication and
design components that appeal to heterogeneous OS platforms.
To satisfy such vital demands and to respond to the challenges of
supporting multiple platforms, all the mainstream Smartphone operating
systems provide a web container. This web-based interface can be included
as part of the mobile application to retrieve and display web contents from
remote servers. This component is called by different names in different
platforms. They are called WebView on Android OS, Windows Browser on
Windows phone OS, UIWebView on iOS, Cascades WebView on BlackBerry
OS, Mojo WebView on Palm, WebOS and WebView on Symbian OS. In
general, the term WebView is commonly used to refer all of the above. The
term WebView APK is used to address an Android Application Package
(APK) file which contains a WebView component.
The WebView component enables the creation of hybrid web-based
applications possessing more powerful functionalities than the traditional
desktop web-browsers. However, these excess features provided by the
WebView can open up portals, for launching malicious attacks on the
Smartphone, through them.
79
The system is built to work on the Android Operating System because
as per the study on the usage share of operating systems, Mobile operating
system browsing statistics on Net Applications [113] shows that android OS
has the highest usage share among other operating systems and because of
its open-source framework nature.
WebView provides a two-way communication between the webpage
loaded by the WebView and the Web-based application installed on the
Android device. Application to Web page communication allows applications
to invoke JavaScript code within the web pages or insert their own JavaScript
code into the web pages, intercept the events occurred within the web pages
and respond to them. Webpage to application communication allows
applications to register interfaces to the WebView, such that JavaScript code
embedded within the web pages can access Java code through those
interfaces. This acts as a gateway for launching malicious attacks on the
Smartphone. Due to this, Smartphone that display web-content within their
applications using WebView can compromise the security protocols
implemented by web pages. Additionally, they themselves can become
victims through the manipulation of WebView APIs.
Android ensures security in two aspects, namely system level and
data level through the security components Dalvik Virtual machine (DVM)
and Permissions mechanism. But the rich features provided by the WebView
APIs not only guide for the creation of hybrid applications, but also provoke
the hackers to misuse the excess authorization provided by the WebView to
launch malicious attacks and collect private information about the users.
7.2
ATTACKS THROUGH WEBVIEW
Some of the WebView vulnerabilities that have been certified
potentially harmful are listed down here:
1. Excess Authorization Attack
2. Supplementary Event-Listener Injection Attack
80
3. UI Overriding Attack
4. WebView Redressing Attack
5. Transparent WebView / Invisible WebView Attack
6. Event Simulation Attack
These attacks can be detected using inference rules on Application
Program Interfaces (API). More than 600 applications containing WebView
component were downloaded. Benign applications were downloaded from
Google play store and malicious applications were downloaded from
www.conatgiodump.blogspot.com.
A detailed study on the nature of the
attack and attack causing elements was conducted. The inference rules were
framed after analyzing the WebView API’s to identify the holes that act as
doorway for each attack. These inference rules are presented as decision
tables for each attack.
The inference rules are formed based on conditions. These conditions
are addressed as series starting with ‘C’ in the inference tables. Depending
on the fulfillment of these conditions in the application, the vulnerability of the
application can be analyzed. Each rule was formed depending on the status
of each condition. For an application, a rule was considered to be followed if
the entire set of conditions exhibit the pattern specified in the table. The
decision table is to be related as follows:
Each column of the decision table corresponds to an inference rule
Each row of the table corresponds to a condition.
Each entry of the decision table corresponds to any of the three
values, namely YES (Y), NO (N) and not_signifiant (empty cells).
Upon the execution and verification of all the inference rules the
input APK is then classified into one among the following
categories:
81
1.
Harmless WebView
2.
Oblivious WebView
3.
Malicious WebView
Harmless WebView: The input APK containing a WebView
component is named as a Harmless WebView if and only if any of
the inference rules produces negative results. Moreover, this kind
of WebView does not have a vulnerability hole in its code. Also it
does not own any code segment that opens a portal for launching
malicious attacks.
Oblivious WebView: The input APK containing a WebView
component is named as an Oblivious WebView if and only if the
WebView contains code segments which can become potentially
harmful upon the manipulation of them. Though these WebViews
do not pose any threat to the users, they are on the verge of
causing troubles.
Malicious WebView: The input APK containing a WebView
component is named as a Malicious WebView if and only if any of
the inference rules produces positive results. This kind of WebView
may cause an attack on the user’s Smartphone.
Some Inference rules classify the APK under more than one action,
namely a combination of Harmless and Oblivious WebView or Oblivious and
Malicious WebView. In such cases the one with greater impact is given much
importance, namely Oblivious and Malicious of the above two cases
respectively. The following section explains each attack caused by exploiting
WebView component. For demonstrating the consequence of the attack,
exclusive applications exhibiting the nature of each attack was developed.
82
7.2.1 Excess Authorization Attack
Java
objects
can
be
bound
to
the
WebView
using
‘addJavaScriptInterface’ method as shown in Figure 7.1. This technique is
useful to access a platform feature not already available in JavaScript or a
native component written in Java.
JavaScriptInterface JSI = new JavaScriptInterface (this);
myWebView.addJavaScriptInterface (JSI, "Android");
Figure. 7.1: Bind using ‘addJavaScriptInterface’ Method
Hence, from the JavaScript context, all the public methods of the
exposed Java object can be accessed using the interface registered with the
WebView. As this mechanism provides an excess authorization to the
JavaScript, Yu and Yamauchi [100] refer to it as Excess Authorization attack.
This attack is demonstrated as follows: An HTML webpage having
three button elements is loaded into a WebView, which has registered with
interface name “Android”. Once an element is clicked, corresponding public
methods in Java are called with the help of the interface created. The
methods return sensitive data such as SIM serial id, IMEI number and
contact details which are displayed using the alert function of JavaScript to
confirm that the sensitive data have been received by the web page. This
information can now be uploaded to a remote server. The snippet of the
attack code is given in Table A2.1 of Appendix 2. Figure 7.2 shows the
screenshots of the attack. Figure 7.2.a shows the HTML page, Figure 7.2.b
shows the getContacts reponse, Figure 7.2.c shows the getSIMID Response.
83
Figure.7.2: Sample Screenshots of Excess Authorization Attack
The decision table framed for verifying the existence of Excess
Authorization attack is given as Table 7.1. The table is to be read as follows:
Rule 1: If,
a) the
APK
has
methods
‘addJavaScriptInterface’,
‘setJavaScriptEnabled’, ‘@JavaScriptInterface’, ‘loadUrl’ available
in the Java code
b) And ‘JSInterface’ method in HTML code
c) And ‘setWebViewClient’ method not included in the Java code
Then, the application causes the excess authorization attack and so
considered as malicious.
84
Table.7.1: Excess Authorization Attack Decision Table
RULES
CONDITIONS
1
9
10
C1 : Check for addJavaScriptInterface
Y Y N Y Y Y Y Y N
N
C2 : Check for setJavaScriptEnabled
Y Y N Y Y Y
Y N
Y
C3 : Check for setWebViewClient
N Y
Y
Y Y Y N
Y
C4 : Check for @JavaScriptInterface
Y Y
Y N Y
C5 : Check for loadUrl
Y Y Y Y Y Y Y Y Y
C6 : Check for JSInterface in HTML
page
Y Y
ACTIONS
1
2
2
A1 : Harmless WebView
3
4
5
6
7
N
Y
3
4
5
6
8
X X
A3 : Malicious WebView
X X
7
8
X X
X
Y
N
X
A2 : Oblivious WebView
Y
9
10
X
X
X
X
It can be inferred from Table 7.1 that if rules1, 2, 6 and 8 are satisfied,
then the WebView contains code that could lead to excess authentication
attack.
7.2.2 Supplementary Event-Listener Injection Attack
WebView’s ‘loadURL’ method is utilized for injecting the JavaScript.
This method receives the argument of type string and if the string starts with
JavaScript, then WebView treats the entire string as JavaScript and executes
it on behalf of the web page that is currently loaded in the WebView
component. The JavaScript code has the same authorization and privilege as
that of the web page scripts and therefore can manipulate information on the
webpage and steal sensitive information. This attack adds supplementary
event listeners to HTML elements through JavaScript injection technique,
85
thereby stealing sensitive data using the id of the HTML elements. This
attack is demonstrated with the Gmail login webpage. A blur event listener is
added to the input textboxes (email and password field) once the page has
completed loading. This event will be triggered when those elements lose
their focus (function of blur event). Once the event has occurred, the data
entered into the input elements are retrieved and sent to Java code using the
interface registered with WebView and then displayed using Toast message
to affirm that login details have been received at the Java side.
The code snippet is given in Table A2.2 in Appendix 2. The
screenshots are shown in the Figure 7.3. The Name (Email id) in toast
message once Email textbox loses its focus (blur event triggered) is shown in
Figure 7.3: (a). The Password appended to email in toast message once
password textbox loses its focus (blur event triggered) is shown in Figure 7.3:
(b).
Figure. 7.3: Sample Screenshots of Supplementary EventListener Injection Attack
The decision table framed for verifying the existence of Supplementary
Event-Listener Injection attack is given as Table 7.2.
86
Table 7.2: Supplementary Event-Listener Injection Attack Decision
Table
RULES
1
2
CONDITIONS
3
a
b
c
d
a
b
4
5
c
C1 : Check for
addJavaScriptInterface
Y Y Y Y Y Y Y Y N N
C2 : Check for
setJavaScriptEnabled
Y Y Y Y Y Y Y Y N Y
C3 : Check for setWebViewClient
Y Y Y Y Y Y Y Y Y Y
C4 : Check for onPageFinished
Y Y Y Y Y Y Y Y Y Y
C5 : Check for
setDomStorageEnabled
Y Y Y
C6 : Check for loadUrl
Y Y Y Y Y Y Y Y Y Y
C7 : Check for DOM element
attributes
N N N N Y Y Y
C7.1 : Value attribute accessed
Y N Y
C7.2 : Click attribute accessed
N Y Y
C8 : Check for addEventListener
Y Y Y Y N N N
C8.1 : Focus Event added
Y N N Y
C8.2 : Click Event added
N N Y Y
C8.3 : Blur Event added
N Y N N
ACTIONS
1
2
N
N
3
A1 : Harmless WebView
4
5
X X X
A2 : Oblivious WebView
X X X X
A3 : Malicious WebView
X X X X
87
X
X
Table 7.2 shows that if rules 1 and 2 are satisfied, then the APK
contains code that would act as a portal for Supplementary Event-Listener
Injection Attack.
7.2.3 Invisible Webview Attack
User Interface based WebView APIs are viable to Invisible WebView
attack. A malicious application overlay an invisible WebView on top of the
visible WebView which tricks the users to see the webpage loaded by the
visible WebView but interacts with the webpage loaded by the invisible
WebView. This type of attack is achieved by modifying the transparency
property of WebView object. By setting the opacity of the webpage
(WebView) to lower values it makes them invisible. The opacity of the
WebView is varied using the setAplha method. Though the WebView might
be invisible, it is still physically active hence it can react to user’s interaction
with the page. Since this attack is based upon user’s touch action, Luo et al.
[97] refer to it as touch-jacking attack. This attack is demonstrated by
showing a visible page with some text and then overlaying an invisible page
having a button so that when the user tries to scroll the visible page to
continue reading the text, s/he actually reacts with invisible page which
shows an alert box (event handler of the button in invisible page). The attack
code snippet is given in Figure 7.4 and screenshots are shown in Figure 7.5.
Figure 7.5.a shows the visible page, Figure 7.5.b shows the invisible page,
and Figure 7.5.c shows the attack scenario.
WebViewInvisible_WebView = new WebView (this);
Invisible_WebView.setAlpha (0);
Figure.7.4: Invisible WebView Attack Code Snippet
88
Figure.7.5: Sample Screenshots of Invisible WebView Attack
7.3.4 Webview Redressing Attack
The goal of the malicious application is to integrate two or more
WebViews into a single WebView and then display it to the user. When the
user interacts with the contents of the webpage by clicking some buttons or
typing some message, they might actually be interacting with the contents of
some other webpage loaded by another WebView. Luo et al., [97] explains
that this attack is based upon UI based APIs. Web-based Android application
can use the following APIs to position a webpage to a specific location inside
the WebView: scrollBy, scrollTo, pageDown and pageUp. The attacker can
also vary the text-size and zoom level of the webpage by using setTextSize
and setDefaultZoom APIs. This attack is demonstrated by using two
WebViews. Outer WebView is made large with some text shown on it. Inner
WebView containing a share button is redressed to merge it with the larger
WebView. When the user clicks the share button, the text from the malicious
page is shared instead of actual intended text and it is shown as an alert
message. The implementation of the attack scenario described above is
shown via screen shots in Figure 7.6. Figure 7.6.a shows the page before
redressing, Figure 7.6.b shows the page after redressing and Figure 7.6.c
shows the attack scenario.
89
Figure 7.6: Sample Screenshots of WebView Redressing Attack
The decision table framed for verifying the existence of Touchjacking
attacks (Redressing and Invisible WebView attacks) is given as Table 7.3.
Table 7.3: Touchjacking Attack Decision Table
RULES
CONDITIONS
1
2
3
4
5
6
7
8
9 10
C1 : Check for setJavaScriptEnabled N N N Y N Y Y Y N
Y
C2 : Check for loadUrl
Y Y Y Y Y Y Y Y Y
Y
C3 : Check for No of WebViews > 1
N Y N Y Y Y
N Y
Y
C4 : Check for style.display = ’none’
N
N Y Y Y N N
N
C5 : Check for setAplha (0F)
N
N N N
N Y
N
Y Y N N Y N
Y N
Y
Y
Y
8
9 10
X X
X
C6 : Check for WebViewClient
C7 : Check for onPageFinished hook Y N
ACTIONS
1
A1 : Harmless WebView
2
X
A2 : Oblivious WebView
3
4
5
6
X
X X
90
7
X
X
A3 : Malicious WebView
Y
X
From Table 7.3 it can be inferred that if rules 5, 6 and 9 are satisfied,
then touch jacking attack is possible using the APK.
7.2.5 UI-Overriding Attack
The user’s keystroke inputs are hacked in attack Keystroke hijacking
attack as illustrated by Luo et al., [97]. This attack can be extended as User
Interface (UI) overriding attack, which can be applied to all the native UI
components that can be made to appear as being displayed in the webpage.
This attack is based on the fact that HTML UI elements inside the WebView
and the Android native UI elements have the same external appearance. An
‘EditText’ element of android looks similar to HTML input text field. Hence, if
native UI object on top of the HTML UI object was overriden, the users
cannot find the difference. They seem to be interacting with the webpage but
they are interacting with the native UI components indeed.
This attack is demonstrated with the Yahoo mail login page to get user
details. Two native Edit Texts and a login button with similar outer
appearance and style are overridden with the actual page upon page loading
completion and once the user submits the form, a fake error message is
displayed; meanwhile login details are displayed in Toast message to affirm
the arrival of data to the android side. Then the overridden UI components
are removed to make the page behave normal upon next login attempt.
The Attack scenario is shown in Figure 7.7. Figure 7.7.a shows the
android native UI and Login details, Figure 7.7.b shows the yahoo login Webpage, Figure 7.7.c shows the fake message being displayed to the user after
attack.
91
Figure.7.7: Sample Screenshots of UI-Overriding Attack
The decision table framed for verifying the existence of UI overriding
attack (also known as ‘KeyStroke Hijacking attack’) is given as Table 7.4.
Table 7.4: UI Overriding Attack Decision Table
RULES
CONDITIONS
1
2
3
4
5
6
7
8
9 10
C1 : Check for setJavaScriptEnabled Y N N N Y N N N N
N
C2 : Check for setWebViewClient
Y
Y Y N Y N Y Y N N
C3 : Check for onPageFinished hook Y Y
Y
Y Y
Y
C4 : Check for loadUrl
Y Y Y Y Y Y Y Y Y
Y
C5 : Check for 0055I elements
Y N N N Y Y Y N Y
N
C6 : Check for UI elements Visibility
Y
ACTIONS
1
Y N Y
2
3
4
A1 : Harmless WebView
X X X
A2 : Oblivious WebView
X
A3 : Malicious WebView
X
5
X
X
6
7
N
8
9 10
X
X
X X X X
X
X
Table 7.4 shows that if rules 1, 5 and 7 are satisfied, the APK has a
high possibility of launching UI Overriding Attack.
92
7.2.6 Event Simulation Attack
Malicious Android applications can simulate touch events on the
contents inside the WebView using MotionEvent, KeyEvent, and DragEvent
APIs. The simulated events can also be dispatched using DispatchKeyEvent,
DispatchDragEvent, and DispatchTouchEvent APIs. Luo et al., [97] refer to
this attack as Event simulation attack. Thus, it is possible to simulate a
variety of user events and dispatch them to the web pages loaded by the
WebView. In order to simulate touch events on UI elements inside the
WebView it is essential to determine the x and y coordinate positions of those
elements before launching the attack.
This attack is demonstrated with an HTML page loaded into the
WebView, which has the facility to post comments in the text content of the
webpage. Two TouchEvents are stimulated - first TouchEvent is simulated to
attain the focus on the input textbox and then a sequence of KeyEvents are
simulated to type malicious comments; then, the second TouchEvent is
simulated to get focus on submit button (post comment). The x and y
coordinates of the elements are predetermined before simulating the events.
The code snippet is given in Table A2.3 in Appendix 2 and screenshots are
given in Figure 7.8.
Figure 7.8: (a) shows the comment “WORLD HACKED, USER_A”
being typed into the input textbox by sequence of keystroke events and it
shows POST COMMENT button getting focus for touch event simulation. Fig
7.8: (b) displays an alert message (triggered by POST COMMENT touch
event simulation) containing the comment typed by the hacker. This
comment can be then posted on the webpage.
The decision table framed for verifying the existence of Event
Simulation Attack is given as Table 7.5.
93
Figure 7.8: Sample Screenshots of Event Simulation Attack
Table 7.5: Event Simulation Attack Decision Table
RULES
CONDITIONS
1
9
10
C1 : Check for setJavaScriptEnabled
Y N N N Y Y Y Y N
N
C2 : Check for setWebViewClient
Y Y N N Y
N N
Y
C3 : Check for onPageFinished hook
Y Y
Y N N
Y
C4 : Check for loadUrl
Y Y Y Y Y Y
Y Y
Y
C5 : Check for
requestFocusFromTouch
Y Y Y N Y Y Y Y Y
N
C6 : Check for dispatchTouchEvent
Y Y N N
N N
N
C7 : Check for MotionEvent
Y Y N
Y N
N
8
9
10
X
X
ACTIONS
1
2
2
3
4
3
4
X X
A2 : Oblivious WebView
X
X X
94
6
N Y
A1 : Harmless WebView
A3 : Malicious WebView
5
5
6
7
7
8
X X X X
X
X
From Table 7.5 it can be inferred that by satisfying rules 1, 2 and 8,
the APK could open a portal to Event Simulation Attack.
7.3
SYSTEM ARCHITECTURE
The proposed system shown in Figure 7.9 performs automated static
analysis on the WebView embedded applications and generates a report in a
comprehensive format containing the results obtained from the processing of
WebView. The system takes WebView Android Application Package (APK)
as an input and reverse engineers it. It extracts all the files and analyses
them. This static analysis uses the preprocessed inference rules. These
inference rules are framed after making a detailed study of the attacks on the
WebView and the vulnerabilities found in their API’s that could cause the
attack. A detailed report on the vulnerable points and attack scenario will be
generated by the system.
Figure. 7.9: System Architecture to Detect WebView based
Vulnerabilities
95
The functioning of the system is as follows:
1. The system accepts an application’s APK file (File with an ‘.apk’
extension).
2. The file is reverse engineered to extract the code files. (Java files,
HTML files and XML files)
3. After extraction, it examines the files to check if the application is a
WebView.
4. If it is a WebView, then the files are statically analyzed using the
inference rules.
5. The results of the analysis are represented as Dominance factor,
Yield factor, and rule impact.
a) Dominance Factor:
Dominance factor is a predetermined
constant parameter, which acts as a weight for each rule of an
attack. It corresponds to the amount of dominance possessed
by each rule compared to other rules in their contribution
towards the impact.
b) Yield: Yield denotes the percentage corresponding to the output
of each rule which is calculated by considering the probability of
specified output occurring.
c) Rule Impact: Impact of each rule is given by the scalar product
of dominance and yield values of that rule.
The graphical results of static analysis are shown in the form of bar
charts and pie chart. The column charts are classified into two separate
charts. Figure 7.10 shows the values of dominance and yield corresponding
to tested application. This graph shows that the application under inspection
satisfies certain subdivisions of rule 1 pertaining to Supplementary EventInjection Attack. Rule 3 is satisfied and rules 2, 4 and 5 are not satisfied.
96
Dominance and yield for Supplementary EventListener Injection Attack
Dominance and Yield %
120
100
Dominance %
80
Yield %
60
40
20
0
Rule 1
Rule 2
Rule 3
Rule 4
Rule 5
Inference rules
Figure 7.10: Dominance and Yield Chart
Figure.7.11 shows the percentage impact of each rule for the tested
application. This graph shows that rule 1 has the highest impact. Rule 1 also
has the highest dominance factor in deciding the possibility of Supplementary
event-listener injection attack. Thus the graph in Figure 7.11 implies that the
viability of the application to cause Supplementary event-listener injection
attack is high.
Rule Impact %
Rule Impact for Supplementary Event-Listener
Injection Attack
80
70
60
50
40
30
20
10
0
Rule 1
Rule impact
Rule 2
Rule 3
Inference rules
Rule 4
Figure. 7.11: Rule Impact chart
97
Rule 5
Figure 7.12 shows the prevalence of each attack for the given input
APK in terms of percentage. For the API which is being tested, the figure
shows that the APK is highly prone to Supplementary Event-Listener
Injection Attack with a percentage of 31% when compared with the rest of the
attacks.
Figure. 7.12: Prevalence of each Attack for the given input APK
7.4
EVALUATION AND RESUTS
400 APKs were analyzed individually in the system. The benign
applications were downloaded from Google play store and the malicious
applications
were
downloaded
from
www.contagiodump.blogspot.com.
Applications from this website have been used as test bed in major standard
peer models. Among these 400 APK’s, 233 (58.25 %) APKs contained the
WebView element with them. The performance metrics used for measuring
the efficiency of the automated static analysis system are shown in Table 7.6.
98
Table 7.6: Performance Metrics Considered for Analysis
NAME OF THE METRIC
FORMULA
PRECISION
TP / ( TP + FP )
SENSITIVITY (RECALL)
TP / ( TP + FN )
ACCURACY
(TP +TN ) / (TP +FP +FN +TN )
SPECIFICITY
TN / ( TN + FN )
F- MEASURE
2 * (PRECISION * RECALL ) /(PRECISION+
RECALL)
Where,
-
True Positivity (TP) - the number of items correctly labelled as
belonging to the malicious class.
-
True Negativity (TN) - the number of items correctly labelled as
belonging to the benign class.
-
False Positivity (FP) - the number of benign apps wrongly labelled
as belonging to the malicious class.
-
False Negativity (FN) - the number of malicious apps wrongly
labelled as belonging to the benign class.
-
Precision: The ratio of number of malicious APK’s correctly
classified as malicious to the total number of malicious APK’s
classified as malicious and the benign APK’s classified as
malicious.
-
Recall: The ratio of number of malicious APK’s correctly classified
as malicious to the total number of malicious APK’s in the test
data.
-
Specificity: Measures the proportion of benign apps which are
correctly identified as such and is complementary to the Recall.
99
-
Accuracy: is the measure of the overall effectiveness of the
system.
-
F-Measure: usesprecision and sensitivity values to provide a
single measurement for the system.
The confusion matrix of the system is shown in Table 7.7. Based on these
result the above mentioned performance metrics which are calculated, is
shown in Table 7.8.
Table 7.7: Confusion Matrix for the System
Actual
Malicious
Applications
Actual Benign
Applications
Classified as
Malicious Applications
72
14
86
Classified as Benign
Applications
21
126
147
93
140
233
The system classifies malicious applications with an average of 85%
accuracy. Table 7.8 shows that the value of recall is much less than the
precision. If precision increases, recall decreases and vice versa. There is
usually a trade-off between recall and precision. If the data set is large, the
number of malicious APKs correctly classified will be high, (higher sensitivity /
recall) but the system will give more false alarms (lower precision).
Another performance metric to measure the prediction performance of
the classifier is the kappa statistic. The kappa statistic for the system is
calculated using the Equation 7.1.
100
Table 7.8: Performance Analysis
Performance metrics
Pr( ) =
(
Where,
Precision
84.04
Recall
78.04
Accuracy
85.35
Specificity
86.11
F-measure
80.79
( )
=
(
(
(
)
Pr( ) = (
( )
---- (Eq. 7.1)
( )
(
)
(
(
)
(
)
)) +
)
---- (Eq. 7.2)
---- (Eq. 7.3)
Pr is the proportion of actual (a) and expected (e) agreement between
classifiers and true values,
P (e) is the expected proportion and is given by the Equation 7.2
Pr (a) is the accuracy of the system and is given by the Equation 7.3
The kappa statistic of the system is calculated to be 0.66 which
implements that the system has a good agreement between the model’s
predictions and the true values. The proposed system was standard
benchmarked with the contributions made in this area of research and
presented in Table 7.9.
101
Table 7.9: Comparison of Smartphone Vulnerability Detection Methodologies
Veelasha [
85, 102]
Andromaly
[47, 49]
Dendroid
[66]
APK
Auditor [89]
Permissions (System
Defined)
Permissions
(Developer Defined)
Access Control
Method
Behavioral analysis
Behavioral Abstract
pattern matching
Static Code analysis
Dynamic analysis
Updated Application
scrutiny
WebView analysis
102
CRePE
[72]
Tongbo
Luo [96,
98]
Bifocals
[97]
Junho
Choi
[91]
Proposed
System
The Table 7.9 shows that the proposed system performs significantly
better in providing an overall solution for the sensitive security issues in a
Smartphone system when compared with other standard models.
WebView has become a common means of browsing web
applications using Smartphone. WebView makes browsing easier, but it also
acts as a gateway for various attacks which could cause fatal damage to the
user and his security. Six different attacks caused by WebView exploitation
have been explored and inference rules have been constructed for these
attacks. These rules identify the vulnerable points in the code that could open
a portal for these attacks. The code of the WebView has been statically
analyzed to check if these rules are satisfied. The system also provides
detailed report on the WebView that is under review and helps the developer
and the third-party vendor to check the WebView for vulnerabilities before
distributing it to the customers. The system provides 85% accuracy in finding
the malicious WebView.
103