arXiv:1504.04971v2 [cs.CR] 21 Apr 2015
Impact assessment
for vulnerabilities in
open-source
software libraries
Henrik Plate, Serena Elisa Ponta, Antonino Sabetta, SAP Labs France
10 April 2015
oftware applications integrate more and
more open-source software (OSS) to
benefit from code reuse. As a drawback,
each vulnerability discovered in bundled OSS
potentially affects the application. Upon the
disclosure of every new vulnerability, the application vendor has to decide whether it is
exploitable in his particular usage context,
hence, whether users require an urgent application patch containing a non-vulnerable
version of the OSS. Current decision making
is mostly based on high-level vulnerability descriptions and expert knowledge, thus, effort
intense and error prone. This paper proposes
a pragmatic approach to facilitate the impact
assessment, describes a proof-of-concept for
Java, and examines one example vulnerability as case study. The approach is independent from specific kinds of vulnerabilities or
programming languages and can deliver immediate results.
S
1 Introduction
The adoption of open-source software (OSS) in the
software industry has continued to grow over the past
few years and many of today’s commercial products
are shipped with a number of OSS libraries. Vulnerabilities of any of these OSS libraries can have considerable consequences on the security of the commercial
product that bundles them. The relevance of this
problem has been acknowledged by OWASP which
included “A9-Using Components with Known Vulnerabilities” among the Top-10 security vulnerabilities
in 2013 [1]. The disclosure in 2014 of vulnerabilities such as Heartbleed1 and ShellShock2 contributed
even further to raise the awareness of the problem.
Despite the deceiving simplicity of the existing
solutions (the most obvious being: update to a more
recent, patched version), OSS libraries with known
vulnerabilities are found to be used for some time after a fixed version has been issued [2]. Updating to a
more recent, non-vulnerable version of a library represents a straightforward solution at development time.
However, the problem can be considerably more difficult to handle when a vulnerable OSS library is part
1
2
http://heartbleed.com/
https://shellshocker.net/
Page 1 of 11
of a system that has already been deployed and made Section 7 concludes the paper.
available to its users. In the case of large enterprise
systems that serve business-critical functions, any
change (including updates) may cause system down- 2 Approach
time and comes with the risk that new unforeseen
issues arise. For this reason, software vendors need Concept
to carefully assess whether an application requires an In order to assess whether or not a given vulnerability
urgent application patch to update an OSS library, in an OSS library is relevant for a particular applicaor whether the update can be done as part of the tion, we consider the corresponding security patch,
application’s regular release cycle.
i.e., the set of changes performed in the source code
The key question that vendors have to answer is of the library in response to the vulnerability. Our
whether or not a given vulnerability, that was found approach is than based on the following pragmatic
in an OSS library used in one of their products, is assumption:
indeed exploitable given the particular use that such
a product makes of that library [3]. If the answer (A1) Whenever an application that includes a library
(known to be vulnerable) executes a fragment of
is positive, an application patch must be produced,
the library that would be updated in a security
and its installation needs to be triggered for all existpatch, there exists a significant risk that the
ing deployments of the application. If the answer is
vulnerability can be exploited.
negative, the library update can be scheduled as part
of the regular release cycle, without causing extra
efforts related to urgent patch production by vendors The underlying idea is that if programming con3
and patch installation by users. The current practice structs that would be changed by the patch are
of assessing the potential impact of a vulnerability in used, than the application is using code involved in
OSS is time-consuming and error-prone. Vulnerabili- the vulnerable part of the library. Therefore, we
ties are typically documented with short, high-level collect execution traces of applications, and compare
textual descriptions expressed in natural language; at those with changes that would be introduced by the
the same time, the assessment demands considerable security patches of known vulnerabilities in order to
expert knowledge about the application-specific use detect whether “critical” library code is executed.
of the library in question. Consequences of wrong as- Figure 1 illustrates the approach graphically: The
sessments can be expensive: if the developer wrongly change-list Cij represents the set of all programming
assesses that a given vulnerability is not exploitable, constructs of OSS component i that were modified,
application users remain exposed to attackers. If added or deleted as part of the security patch for
she wrongly judges that it is exploitable, the effort vulnerability j. Change-lists can be computed as
of developing, testing, shipping, and deploying the soon as a security patch has been produced for a
vulnerability. Patches can be assumed available at
patch to the customers’ systems is spent in vain.
This paper presents a pragmatic approach that the time vulnerabilities become public in the case of
contributes to simplify the decision making. We do responsible disclosure. The trace-list Ta represents
so by automatically producing (whenever possible) the set of all programming constructs, either part
concrete evidences supporting the case for urgent of application a or any of its bundled libraries, that
patching. More specifically we assess whether an were executed at least once during the runtime of
application uses (portion of) a library for which a application a. The collection of traces can be done at
security fix has been issued in response to a vulner- many different times, starting from unit tests until
ability. The approach seamlessy integrates in the the application is deployed for productive use.
The intersection Cij ∩ Ta comprises all those prousual development workflow without requiring additional effort from developers and is independent of gramming constructs that are both subject to security patch j and have been executed in the context
programming languages and vulnerability types.
The paper is organized as follows. Section 2 of application a. Following assumption (A1), a nonpresents our approach and a generic architecture empty intersection Cij ∩Ta indicates that a newly disthat supports it. Section 3 describes our prototypi- closed vulnerability is highly relevant, due to the risk
cal implemention and its application to a case study. of exploitability. An empty intersection, on the other
Section 4 outlines observations regarding the inte- 3 We use the language-agnostic term “programming construct”
gration and quality of information stemming from
to refer to structural elements such as methods, construcdifferent sources. Section 5 presents related literature.
tors, functions and so on.
Page 2 of 11
hand, may result from insufficient coverage, hence, it
does not automatically render a vulnerability irrelevant. Coverage is described by the intersection of the
sets Ta ∩ Sa , where Sa is the set of all programming
constructs belonging to the application itself. The
larger the intersection, the better the coverage, and
the greater the confidence that constructs belonging
to Cij cannot be reached.
Library versions can be disregarded, provided that
the traces were collected before the release of a security patch and that all existing library versions
are affected by the vulnerability. In other cases (in
particular if traces are more recent than a patch, and
if the corresponding constructs exist in both vulnerable and patched library version) one has to identify
and compare the version of the library producing the
trace with the ones affected by the vulnerability.
Our approach is not immune to reporting falsepositives and false-negatives. False-positives occur
if a vulnerability is not exploitable despite a nonempty intersection Cij ∩ Ta , which is due to the fact
that exploitability can depend on many other conditions, e.g., the presence of sanitization techniques
in the application or specific configuration settings.
False-negatives occur if vulnerabilities are exploitable
despite an empty intersection Cij ∩ Ta , which can
result from insufficient coverage, a problem shared
with many techniques relying on dynamic execution
(as opposed to static analysis). The silver-lining is
that the approach is entirely independent of programming languages or types of vulnerabilities and
it can provide immediate results. Intuitively, we
expect that developers are convinced to update a
library when presented with a non-empty intersection Cij ∩ Ta , i.e., traces of programming constructs
that are subject to a security patch. In any case, the
information collected is valuable to simplify further
analysis, complementing the high-level vulnerability
description expressed in natural language in publicly available vulnerability databases, such as the
National Vulnerability Database.
Architecture.
Figure 2 illustrates a generic architecture that supports our approach. Components depicted in white
belong to the proposed solution and require an implementation, while components depicted in grey
represent the solution’s environment. A specific implemention for Java and related tooling is described
in Section 3.
The Assessment Engine on top is responsible for
storing and aggregating the three sets of Figure 1.
It also presents assessment results concerning the
relevance of vulnerabilities to the security expert of
the respective application.
The Patch Analyzer is triggered upon the publication of a new vulnerability for an open-source library.
It interacts with the respective Versioning Control
System (VCS), identifies all programming constructs
changed to fix the vulnerability, and uploads their
signatures to the central Assessment Engine. This
change-list is built by comparing the vulnerable and
patched revision of all relevant source code files of the
library. The corresponding commit revisions can be
obtained from the vulnerability database, searched
in the commit log, or specified manually.
The Runtime Tracer collects execution traces of
programming constructs, and uploads them to the
central engine. This is achieved by injecting instrumentation code into all programming constructs of
the application itself and all the bundled libraries.
The instrumentation can be done dynamically, during the actual runtime, or statically, prior to the
application’s deployment. The former can guarantee
the tracing of all programming constructs used at
runtime including, e.g., libraries included at runtime
and parts of the runtime environment. Its major
drawback is the impact on application startup, in
particular if many contructs need to be loaded before the applicaton becomes available to its users, as
in the case of application containers. Static instrumentation does not impact the application startup
time and can be used in cases where the runtime
environment cannot be configured for dynamic instrumentation, e.g., in PaaS environments. However,
it cannot guarantee the coverage of programming
constructs used at runtime.
The Source Code Analyzer scans the source code
of the application, identifies all its programming
constructs and uploads their signatures as well as an
application identifier to the central engine.
Note that the above-described components run at
different points in time. Source Code Analyzer and
Runtime Tracer are expected to run continuously
during different phases of the application development lifecycle and their results are kept even after
the release of the application to its customers. Once
the Patch Analyzer is triggered, typically after the
release of a patch for a vulnerable library, the assessment result is immediately available thanks to the
comparison of the newly collected change-lists with
the previously collected traces.
Page 3 of 11
Figure 1: Main concept
Figure 2: Generic Solution Architecture
3 Proof-of-concept
This section describes our current implementation
of the approach and the architecture presented in
Section 2. We illustrate its application to CVE-20140050 as case study.
Implementation
The current prototype supports the assessment of vulnerabilities of Java components and is implemented
by using technologies that can be seamlessy integrated in typical Java development and build environments based on Apache Maven.
The Assessment Engine is realized by means of a
SAP Hana database where the change-list, trace-list
and programming constructs are stored and manipulated. The results are accessible via a web frontend
(see Figure 4).
The Patch Analyzer is implemented as a Java
stand-alone application. It interacts with version
control systems (VCS) (Git and Subversion in our
current implementation) by means of the JGit4 and
SVNKit5 Java libraries. Such libraries are used to retrieve the code for the patch and vulnerable revisions
(i.e., the revision preceeding the patched one). The
4
http://eclipse.org/jgit/
5
http://svnkit.com/
ANTLR6 library is used for building the parse tree
of the Java files to be compared in order to obtain
the change-list.
The Runtime Tracer requires the injection of code
into each programming construct of the application
and its libraries. The instrumentation (both static
and dynamic) is realized using Javassist7 . Dynamic
instrumentation was found suitable for unit tests,
executed by individual developers and during continuous integration. Static instrumentation is instead
suited for integration and end-user acceptance tests
performed on dedicated systems. In particular, if the
application is deployed in application containers such
as Apache Tomcat, static instrumentations allows to
avoid the performance impact on startup time, which
is caused by the significant number of classes loaded
before the container and its application become available. Moreover, static instrumentation is also useful
in case Java Runtime Environment (JRE) options
cannot be accessed or changed to enable dynamic instrumentation, e.g., when using Platform as a Service
(PaaS) offerings. In either cases, whenever the application is executed, the instrumentation code added is
responsible for collecting and uploading traces to the
6
7
http://www.antlr.org/
http://www.csg.ci.i.u-tokyo.ac.jp/~chiba/
javassist/
Page 4 of 11
central engine. Note that the collection and upload is
only done upon the first invocation of the respective
programming construct which significantly reduces
the performance overhead. The limited impact on
application performance has as goal to enable the
trace collection during everyday testing activities.
The Source Code Analyzer is realized by means
of a Maven plugin. As for the Patch Analyzer it
uses the ANTLR library to parse the Java classes.
The result is the collection of the signature of every
programming construct belonging to the application
itself. The Maven identifier (composed of group id,
artifact id, and version) is used as identifier of the
application to set the context for the analysis, i.e.,
it represents the application a to define the sets Sa
and Ta of programming constructs and trace-list (see
Figure 1).
Case-study: CVE-2014-0050.
The National Vulnerability Database (NVD) is a
comprehensive, publicly available database for known
vulnerabilities that are disclosed in a responsible manner, i.e., for which a patch has been made available
at the time of the vulnerability publication. It also
includes the information regarding affected products.
In particular, the Common Vulnerabilities and Exposures (CVE) and Common Platform Enumeration
(CPE) standards are used to identify the vulnerability and the affected products, respectively.
CVE-2014-0050 8 describes a vulnerability in
Apache FileUpload 9 as follows: “MultipartStream.java in Apache Commons FileUpload before
1.3.1, as used in Apache Tomcat, JBoss Web, and
other products, allows remote attackers to cause a
denial of service (infinite loop and CPU consumption) via a crafted Content-Type header that bypasses
a loop’s intended exit conditions.”
Upon disclosure of the vulnerability, any developer
using Apache FileUpload needs to judge whether her
application is affected. Current practices require her
to rely on the textual description for taking a decision.
However, it is not straighforward to assess whether
the Java class MultipartStream (referenced to in the
description) is used in the scope of an application. In
fact it may be used either directly (i.e., instanciated
in the source code of the application) or indirectly
within other classes of the libraries which are directly
8
http://web.nvd.nist.gov/view/vuln/detail?vulnId=
CVE-2014-0050
9
http://commons.apache.org/proper/
commons-fileupload/
used.
The application used in our case study is a
sample Web application, com.research.vulas:vulastestapp:0.0.1-SNAPSHOT, which performs various
operations on compressed archives. Figure 3 shows
assessment results for several vulnerabilities after
the execution of both JUnit and integration tests
of the Web application as well as the computation
of change-lists. The first two vulnerabilities, including CVE-2014-0050, are marked as relevant because
constructs part of the change-list (i.e., subject to
the security patch) have been executed in its vulnerable version. CVE-2011-1498, CVE-2012-6153,
and CVE-2014-3529 are marked as irrelevant since
non-vulnerable releases of the respective libraries are
used. For CVE-2014-3577 and CVE-2014-3574 the
assessment result shows that the vulnerable release is
used but no traces for the change-list were observed.
More in detail, the table at the bottom of Figure 4 shows the change-list Cij where i is Apache
FileUpload and j the vulnerability CVE-2014-0050.
In this case, the intersection Cij ∩ Ta is not empty,
but contains the constructor of the Java class MultipartStream. The exclamation mark in the “Traced”
column highlights that its execution was observed
–at the time shown in the tooltip– during application
tests.
The Patch Analyzer computed the change-list using the URL of the VCS of Apache FileUpload and
the revision number of the patch, which is provided
by NVD in one of the references of CVE-2014-0050.
As the used programming construct in Figure 4
was modified as part of the patch (marked as MOD
in the figure), it is present both in the vulnerable
and patched version of the library. Moreover, the
experiment was done for a rather old vulnerability,
hence, the traces are more recent than the security
patch itself. As a result, it is necessary to identify
the version of the library in use, and compare it with
the ones affected by the vulnerability.
This is preferably done by means of Maven identifiers and, if this is not possible, CPEs. In particular,
we search the Maven Central repository (i.e., the
default repository for dependency management with
Maven) for the SHA-1 of the archive from which a
class was loaded at runtime and, if a match is found,
we obtain the version of the used library as well as
the information about all existing versions.
The products affected by a vulnerability are identified by interacting with the VCS of the respective
library. For that purpose, we analyze so-called tags,
which are a common means for marking all those
repository elements that constitute a given relrease
Page 5 of 11
Figure 3: Analysis overview for the sample application
–at least in case of the widely-used versioning control
systems Apache Subversion and CVS. In more detail,
we identify all tags applied prior to the security patch
in question, and parse the Maven project files that
existed at that time.
Figure 4: Analysis details for CVE-2014-0050
As the web application of our case study runs
within the Apache Tomcat application container, we
opted for the static instrumentation in order to avoid
the impact of dynamic instrumentation on the container’s initial startup time. The trace of the patched
programming construct was collected by using integration tests on the interface for uploading files of the
instrumented application. Intuitively, we perceive
that unit and integration tests are complementary
means for collecting traces. In particular, the focus
of unit tests on the business logic of fine-granular
components does not cover components involved in
Information about library releases is displayed in the application’s main I/O channels, many of which
the upper table of Figure 4. It shows that the used rely on OSS libraries, e.g., Apache FileUpload, Httplibrary, i.e., apache commons fileupload 1.2.2, is in- Client or Struts.
deed affected by the vulnerability: there existed
For CVE-2014-0050 an exploit exists as a Ruby
a corresponding tag that has been applied prior script in the Exploit-DB, i.e., an archive of exploits
to the commit of the security fix. It also shows for known vulnerabilities (http://www.exploit-db.
the latest, non-vulnerable release, i.e., apache com- com/exploits/31615/). By manually running it, we
mons fileupload 1.3.1. By updating to the latest observed that assumption (A1) of Section 2 holds in
release, the risk of being vulnerable can be addressed. our case study, i.e., the vulnerability is exploitable in
In case of VCS other than Apache Subversion and
CVS, we resort to the NVD for establishing the affected versions of a given vulnerability. The NVD
uses CPE names, mainly composed of the vendor,
product and version information, to identify all affected products. In order to establish if the used
library is affected by the CVE we check if its version is among those listed for the affected CPEs. In
general, the use of CPE names is considered as a
fallback only, since the matching of CPE vendor and
product names to Maven identifiers is ambiguous (cf.
Section 4).
Page 6 of 11
Figure 5: Information about archives declared and/or
traced
the given application context even though only one
programming construct belonging to the change-list
has been executed.
Other than assessing vulnerabilities, the prototype
offers two other views:
The first view shows all archives used by the application under analysis (cf. Figure 5), either because
they have been declared using Maven or because
they have been observed during application tests (i.e.,
classes where loaded from those archives). Archives
whose SHA-1 is not known to the Maven Central
are highlighted (commons-io-1.3.2.jar in the example), and so are archives that have not been declared
but whose execution was observed during application
tests. The former may indicate the use of a tampered
archive, the latter bad development practice.
The second view displays the function coverage of
application constructs as described in Section 2, aggregated on the level of Java packages (cf. Figure 6).
Moreover, it shows the function coverage for archives
used by the application, aggregated on archive level.
4 Data integration problems
Figure 6: Function coverage for application constructs
and archives
our experiments, we found that the integration is
hindered by several problems, each one requiring
ad-hoc, technology-specific solutions. Such problems
hamper—in general—the automation of OSS vulnerability management.
Non-uniform reporting of products affected
by a vunerability.
The NVD uses the CPE standard for enumerating
components affected by a vulnerability. In our experiments, we observed a non-uniform practice of
assigning CPEs to vulnerabilities in OSS libraries.
In some cases only the CPE of the respective library
is mentioned. As an example, the affected components for CVE-2012-209811 are versions of Apache
Commons Compress before 1.4.1.
cpe:/a:apache:commons-compress
In other cases also the CPEs of applications making
Our approach requires the integration of informa- use of the library are listed. This is the case for
tion stemming from different sources, e.g., vulnera- 11
Algorithmic complexity vulnerability in the sortbility databases, VCS for managing the code base
ing
algorithms
in
bzip2
compressing
stream
of OSS, and public OSS repositories (e.g., Maven
(BZip2CompressorOutputStream) in Apache Commons Compress before 1.4.1 allows remote attackers to
Central10 in case of our Java prototype). During
10
http://search.maven.org
cause a denial of service (CPU consumption) via a file
with many repeating inputs.
Page 7 of 11
CVE-2014-0050, whose affected components include Vulnerabilities and VCS information of the
not only Apache FileUpload,
respective security patch are not linked in
cpe:/a:apache:commons_fileupload
but also several versions of Apache Tomcat,
cpe:/a:apache:tomcat
a systematic and machine-readable
fashion.
The change-list computation requires as input the
URLs of VCS and commit numbers. The Patch
Analyzer of our prototype uses two strategies for discovering them: (i) pattern matching for identifying
VCS information in CVE references and (ii) search
for CVE identifiers in VCS commit logs. While successful in case of CVE-2014-0050 and many other
vulnerabilities, they still represent ad-hoc solutions
depending on the discipline of developers and the
quality of CVE entries. In particular, both strategies
are successfull for CVE-2014-0050: (i) the VCS
which is just one out of many applications using
this library. As mentioned in the textual description of the CVE (cf. Section 3), JBoss Web, and
other products are also affected, though, not listed
as CPEs.
The above CPEs are written in the URI binding
form. We made use of a subset of the supported fields,
i.e., type a to denote an application, vendor apache,
product commons-compress, commons_fileupload,
and tomcat. It is important to notice that CPEs do http://svn.apache.org/r1565143
not provide an immediate means to identify libraries.
is listed among the CVE references; (ii) the commit
Vulnerability and dependency management log for revision 1565143 contains the CVE identifier:
make use of different naming schemes and Fix CVE-2014-0050. Specially crafted input
nomenclatures.
can trigger a DoS if ... This prevents the
There exist many language-dependent technologies
and nomenclatures for identifying libraries and managaging dependencies at development and build time
(e.g., Maven for Java), none of which maps straightforwardly to CPE. As an example consider the
Apache HTTP Client library. Maven identifiers are
of the form
GroupId=org.apache.httpcomponents
ArtifactId=httpclient
for each release as of 4.0. CVE-2012-6153 affects
Apache Commons HttpClient before 4.2.3 and the
CPEs listed as affected products are of the form
cpe:/a:apache:commons-httpclient
While a human can easily recognize the mapping,
this is not the case for an automated solution. The
problem is made even worse by the fact that Maven
identifiers and CPEs may change for newer releases.
As a matter of fact the syntax commons-httpclient
that is used in the above CPE was also used as Maven
group and artifact id for older releases (before 4.0).
Moreover, there exists no unambigous, languageindependent way for uniquely identifying libraries
once they are bundled and installed as part of an
application. Our prototype computes the SHA-1
of Java archives and performs a lookup in Maven
central: an ad-hoc solution that fails if the bundled
library has been compiled with a different compiler
than the library available in the public repository.
DoS.
However in other cases different practices are used.
As an example CVE-2012-2098 affecting Apache
Commons Compress does not reference the VCS revision(s) fixing the vulnerability, nor the VCS commit
log systematically references the CVE. In this example the revisions fixing the vulnerability are listed
in a webpage of the Commons Compress project
dedicated to security reports 12 .
5 Related work
With the increased adoption of open-source components in commercial products, the attention to
the potential risks stemming from this practice has
increased correspondingly. More specifically, the
problem of evaluating the impact of vulnerabilities of
open-source (and more generally, of third-party) components has attracted significant attention among
researchers [4, 5] and practitioners [2, 1]. Several
approaches tackle the problem of vulnerability impact assessment by examining the system statically,
in order to determine a measure of risk, as in [6]
where the authors consider the relation between the
entry points of the subject system (the potential attack surface) and the attack target (the vulnerable
code). Younis et. al [3], elaborating on that idea,
12
http://commons.apache.org/proper/commonscompress/security.html
Page 8 of 11
proposed a similar approach that also measures the
ratio between damage potential and attack effort in
order to estimate how motivated an attacker needs
to be when targeting a particular point of the attack
surface.
Our approach is complementary to these, in that
our goal is to observe real executions of a system (as
opposed to analyzing its structure and call graph)
in order to detect whether actual executions were
observed that touched a part of the code that is
known to be vulnerable. Judging how likely is the
exploitation of vulnerabilities that were not covered
by concrete execution is not in the scope of this work
(although we do plan to include that aspect in our
future research).
Several tools have been proposed to help detect
the use of vulnerable libraries, such as the OWASP
Dependency-Check13 or the Victims Project14 . Both
support the check of whether a project depends on
libraries for which there are any known, publicly
disclosed, vulnerabilities. Similarly to ours, these
tools are realized as Maven plugins to minimize the
barrier to adoption. They differ from our approach
because their goal is to identify whether a vulnerable
library is included in a project, whereas we concentrate on detecting whether the vulnerable portion
of the library can be actually executed as part of
the container project, a question that is particularly
relevant for released applications.
6 Future directions
Up to now, we have used the current implementation
of our approach to a limited set of sample projects.
The evaluation we could make was only preliminary,
but the feedback we received from the the early
adopters of our tool (develoment units internal to
our company) indicates clearly that the problem we
are tackling is perceived as timely and extremely relevant in practice. That feedback also highlights the
importance of several outstanding problems which
demand further investigation. In this section we summarize the future directions of our research, which
will be the topic of future works.
Accuracy of the analysis
One inherent limitation of our approach, as most
existing approaches to vulnerability analysis, is that
it is neither sound nor complete. In particular, the
reliability of our assessment is heavily dependent
on the coverage achieved through executions (e.g.,
obtained by testing) of the subject system and its
libraries. This has two important consequences: one
is related to the nature of the judgments that one
can draw based on testing; the other is related to the
problems that can arise when a test suite constructed
for functional testing is used as the basis of a security
assessment.
Obviously, when execution coverage is poor, it may
happen that a vulnerability is not deemed relevant
just because no observed path reached the vulnerable
code. This says nothing about whether such path
would be feasible in practice. Furthermore, even
when relying on a well-written (functional) test suite
that achieves high-coverage, there might still be corner cases – not considered in functional tests – that
are potentially relevant from a security standpoint
and that an attacker could exploit.
The first point can be addressed by using test suites
that achieve good coverage and that therefore reduce
the chances that obvious problematic execution paths
go unnoticed.
Regarding the second point (which can also benefit
from testing if the functional test suite is augmented
with explicit tests for corner cases and negative tests),
we feel it would be tackled more effectively by combining our current test-based approach with static
analysis. By analysing the source code of the target
program and its libraries, we could determine with
some approximation (e.g., constructing the combined
call graph), whether it is at all possible to reach vulnerable code from the application code.
In certain particular cases, this method could provide very strong evidence that the vulnerable code is
unreachable, and as such it would complement nicely
our test-based method with provides very strong evidence (a proof, indeed) in the complementary case,
that is when vulnerable code is indeed reachable.
This technique would still need to cope with some
degree of approximation. A study of the interplay
of test-based analysis and static analysis will also
require to investigate which types of flow analysis
are best suited to provide a good balance between
reliability of the results and performance, especially
when taking into account the the complexity of large
real-world applications.
Scalability to large projects
13
https://www.owasp.org/index.php/OWASP_Dependency_
Check
14
https://victi.ms/, https://github.com/victims
While we do not have conclusive evidence nor quantitative figures to offer at this time, the performance
Page 9 of 11
observed in our preliminary tests is promising. We
believe that the performance penalty that our tool
imposes on the build process would acceptable in
most practical cases. As a future work, we plan to
conduct a systematic study of the performance of
our tool, by using it in large commercial applications with complex build structure and hundreds of
dependencies.
Experiments to validate the assumptions
underlying our approach
The basic assumption on which this work is based (see
Sec. 1) seems sensible based on what we observed in a
limited set of sample projects both in the open-source
and in industrial projects. However, its rigorous
validation is a prerequisite for drawing more realiable
conclusions about the quality of our approach. This
validation will require examining a larger number of
projects and compare the results of our analysis with
the actual exploitability of vulnerable libraries in the
context of those projects.
Tackling the data integration problems
Our approach heavily relies on data coming from an
heterogeneous set of sources, which include vulnerability databases (such as the NVD) and source code
repositories.
Based on our experience, we believe that, despite
the growing attention that both researchers and practitioners dedicate to the topic of automated vulnerability management, the gap to be filled in is still
quite large. A key problem that approaches like ours
have to face is how to reliably relate CVE entries
with the affected software products and the corresponding source code repository, down to the level of
accurately matching vulnerability reports with the
code changes that provide a fix for them.
This information is currently unavailable, and obtaining it proved to be extremely difficult.
We are currently adoption ad-hoc solutions to
these problems. For example, we are manually constructing a curated list of widely used open-source
projects and their respective code repositories. This
approach has the obvious drawback of requiring manual effort both to build and maintain the list; furthermore the coverage is limited to a large but nonexhaustive set of projects. Similarly, we are using
ad-hoc mechanisms to determine the correspondence
between release numbers (as mentioned in CVEs) to
commit identifiers in source code repositories.
As a future work, we will investigate ways to improve these solutions a we will study possible alternative methods.
Integrating continuous vulnerability
assessment in continuous integration
systems
Our approach, when considered as part of the overall
software development lifecycle, has a very natural
application in continuous build and integration systems. When included in such systems, our tool can
collect traces on a regular basis and therefore can offer timely notifications when one or more of the used
libraries are found to be affected by a vulnerability
report.
At the time of writing, we are initiating the work
to adapt our prototype to run as part of Jenkins
builds. As a future work, we intend to complete
this implementation and to evaluate it when used in
large development projects (e.g., with over a hundred
libraries).
7 Conclusion
This paper presented a pragmatic approach to answer one important and time-critical question: Does
a vulnerability in bundled OSS libraries affect an
application? Our approach helps to assess whether
urgent patching is needed in response to a vulnerability. It is generic with regard to programming
languages and types of vulnerabilities, and can be
seamlessly integrated into industry-scale build and
integration systems.
This paper presented both the conceptual approach and a concrete implementation as a tool,
whose functionality was demonstrated using an illustrative example.
Contact
information. The
authors
can
be contacted via e-mail at their addresses:
firstname.lastname AT sap.com. Comments and
feedback on this paper are very appreciated.
References
[1] OWASP Foundation, “OWASP top 10 - 2013,”
Tech. Rep., 2013. [Online]. Available: https://
www.owasp.org/index.php/Top 10 2013-Top 10
[2] Contrast
Security,
“The
unfortunate
reality
of
insecure
libraries-reloaded,”
Page 10 of 11
Tech.
Rep.,
2014.
[Online].
Available:
http://www1.contrastsecurity.com/
the-unfortunate-reality-of-insecure-libraries
[3] A. A. Younis, Y. K. Malaiya, and I. Ray, “Using
attack surface entry points and reachability analysis to assess the risk of software vulnerability
exploitability,” ser. HASE ’14. IEEE Computer
Society, 2014, pp. 1–8.
[4] G. Schryen, “Is open source security a myth?”
Communications of the ACM, vol. 54, no. 5, pp.
130–140, 2011.
[5] A. Arora, R. Krishnan, R. Telang, and Y. Yang,
“An empirical analysis of software vendors patching behavior: Impact of vulnerability disclosure,”
2006.
[6] D. Brenneman, “Improving software security by
identifying and securing paths linking attack surfaces to attack targets,” McCabe Software, Tech.
Rep., 2012.
Page 11 of 11
Module 11: Windows Application Software for Security Vulnerabilities
Critical Thinking: Software Security
Assignment Details:
In an essay, review the following statements based on the readings from this week’s module:
•
•
Once your operating system is secure, you can focus on securing the software that runs in the operating
system.
Evaluate some of the most popular Microsoft applications and analyze how to make an application more
secure to protect your organization’s data. Describe at least three (3) techniques used to secure an
application.
Provide information from your readings to support your statements.
Requirements:
-
4-5 pages
3 references in addition to the case study
APA format
APA citation
- the essay must include introduction – body – conclusion – references
Required Reading the below materials:
https://doaj.org/article/a7ae190a2c3d49c2a824f9b788814966
And the two attached PDF files their names are tv_22_2015_2_279_287 and 1504.04971 and the
ppt file its name is SEU_CS566_winsec_ppt15_l12
Recommended
Security Strategies in Windows
Platforms and Applications
Lesson 12
Microsoft Application Security
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Learning Objective and Key
Concepts
Learning Objective
▪ Design techniques to protect given Windows
application software from security vulnerabilities.
Key Concepts
▪ Vulnerabilities to Microsoft server and client
applications
▪ Strategies for securing Microsoft server and client
applications
▪ Procedures for securing Microsoft applications
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 2
Client Application Vulnerabilities
Malformed input
• Inputs that applications doesn’t expect
• Inputs that can cause unexpected results
Privilege escalation
• Using loopholes to pursue administrator
privilege
Identity spoofing
Denial of Service (DoS)
• Assuming another user’s identity
• Slows application
• Crashes applications
Direct file or resource
access
• Exploits holes in access controls .
Extra-application data
access
• Accesses application’s data outside the
application
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 3
Application Hardening Process
Minimal
Install
Assess
Security
Monitor
Performance
Security Strategies in Windows Platforms and Applications
Latest
Patches
Least
Privilege
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 4
Common Client Applications
Web
browser
E-mail
client
Productivity
software
File
Transfer
Software
AppLocker
• Internet Explorer
• Outlook
• Microsoft Office
• File Transfer Protocol/Internet
Protocol (TCP/IP)
• Software Restriction Policies (SRP)
• Group Policy
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 5
Internet Options Dialog Box in
Internet Explorer 8
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 6
Securing Client Applications
Update software to the latest
patch
Remove or disable unneeded
features
Use principle of least privilege
Use encrypted communication
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 7
Common Server Applications
Web server
• Internet
Information
Services
(IIS)
Security Strategies in Windows Platforms and Applications
E-mail
server
• Exchange
Database
server
• Structured
Query
Language
(SQL)
Server
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 8
Common Server Applications
(Cont.)
Enterprise
Resource
Planning
(ERP)
Software
Unique user accounts
Line of
Business
(LoB)
Software
Enterprise project management
Strong authentication
Restricted access
Encrypted connections
Workflow control
Service technician tracking and scheduling
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 9
Add Roles Wizard, Windows
Server 2008 R2
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 10
Select Role Services, Windows
Server 2008 R2
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 11
Securing Server Applications
Use server roles in Windows
Server
Update software to the latest
patch
Remove or disable unneeded
services
Filter network traffic
Encrypt communication
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 12
Case Studies
Sporton
International
Monroe College
Dow Corning
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 13
Best Practices
▪ Harden the operating system.
▪ Install only the services necessary.
▪ Use server roles when possible.
▪ Use SCW to apply least privilege principle to
applications.
▪ Remove or disable unneeded services.
▪ Remove or disable unused user accounts.
▪ Remove extra application components.
▪ Open only the minimum required ports at the
firewall.
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 14
Best Practices (Cont.)
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
Define unique user accounts.
Use strong authentication.
Use encrypted connections for all communication.
Encrypt files, folders, or volumes that contain private data.
Develop and maintain a BCP and DRP.
Disable any unneeded server features.
Ensure every computer has up-to-date anti-malware
software and data.
Never open any content or files from untrusted sources.
Validate all input received at the server.
Audit failed logon and access attempts.
Conduct penetration tests to discover vulnerabilities.
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 15
Summary
▪ Client and server applications, vulnerabilities,
and security method
▪ Process to harden client and server
applications
▪ Key roles involved in application security
▪ Environments exposed to higher risk
▪ Importance of application security
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 16
Virtual Lab
▪ Securing Internet Client and Server
Applications on Windows Systems
Security Strategies in Windows Platforms and Applications
© 2015 Jones and Bartlett Learning, LLC, an Ascend Learning Company
www.jblearning.com
All rights reserved.
Page 17
Y. C. Cho
Uvođenje i analiza sustava za probijanje sigurnosti web mjesta s primjenom na sveučilišne akademske mreže
ISSN 1330-3651 (Print), ISSN 1848-6339 (Online)
DOI: 10.17559/TV-20150310110158
IMPLEMENTATION AND ANALYSIS OF WEBSITE SECURITY MINING SYSTEM, APPLIED
TO UNIVERSITIES' ACADEMIC NETWORKS
Ying-Chiang Cho
Original scientific paper
It is becoming increasingly common for web application and data storage services to be handled by cloud computing; therefore, more and more people are
putting their private information on the internet, motivating research into cloud computing, database security and authority encryption. In the Open Web
Application Security Project (OWASP) assessment, SQL injection is one of the most dangerous attack vectors in internet security. With this in mind, we
have implemented a system named the website security mining system, which leverages a web crawling algorithm to analyze web URL and e-mail address
leaks through black-box testing of 20 well-known universities’ websites. Based on our data, academic website maintainers can be clearly informed about
what kind of danger they are exposed to, which URLs are highly in danger, and the need to patch the website to protect against vulnerabilities and prevent
academic resources from attacks. We hope that in the future, academic networks will gain more attention in the information security community, just like
commercial and government networks today.
Keywords: academic networks; black-box testing; database security; search engine; SQL injection
Uvođenje i analiza sustava za probijanje sigurnosti web mjesta s primjenom na sveučilišne akademske mreže
Izvorni znanstveni članak
Sve je uobičajenije za web aplikacije i poslužitelje za pohranu podataka rukovanje putem programskog rješenja u oblaku; stoga je sve veći broj ljudi koji
svoje privatne podatke stavljaju na internet, motivirajući istraživanje mogućnosti programskog rješenja u oblaku, sigurnosti baza podataka i kodiranih
nadležnosti. U procjeni Open Web Application Security Project (OWASP)-a, ubacivanje SQL-a jedan je od najopasnijih napadnih vektora na sigurnost
interneta. Imajući to u vidu, uveli smo sustav nazvan sustav za probijanje sigurnosti web mjesta, koji pokreće algoritam za pretraživanje weba kako bi
analizirao propuste na zaštiti URL-a i adresa e-pošte ispitivanjem crnih kutija web mjesta 20 poznatih sveučilišta. Na temelju naših podataka, održavatelji
akademskih web mjesta mogu saznati kakvoj su opasnosti izloženi, kojim URL-ovima prijeti veća opasnost i što učiniti kako bi uredili web stranicu za
zaštitu od ranjivosti i sprijećili napade na akademske resurse. Nadamo se da će se u budućnosti veća pažnja posvetiti sigurnosti informacija na
akademskim mrežama, kako se to danas čini s komercijalnim i vladinim mrežama.
Ključne riječi: akademske mreže; sigurnost baza podataka; stroj za pretraživanje; testiranje crne kutije; ubacivanje SQL
1
Research motivation
Due to the broad availability of web applications,
securing a web application (particularly one backed by a
database) is much more challenging than securing a
traditional application [1]. Some security researchers have
attempted to convey the concepts of information security
to web application programmers [2]. However, these
concepts are often not successfully applied. After all,
human thoughts are much more uncontrollable [3, 4] than
computer software; therefore, humans still need to use
external programs to help analyze security issues in
source code, web application services, and even the entire
operating environment. For example, some researchers
have used bounded model checking to analyze web
application security [5] but this approach still fails to
account fully for the dynamic environment that real web
applications must deal with. SQL injection attacks have
been known for decades, but due to improper handling of
user input, these attack modalities are still leveraged
towards nefarious purposes such as executing arbitrary
database queries to, for example, delete data or steal user
account information [6].
Academic networks are typically smaller and simpler
than commercial and government networks, where the
issue of information security is given more attention.
However, academic networks still face serious risks.
Commercial networks contain much private data and
government networks contain government documents,
which motivates strong security measures as compared to
academic networks where malware attacks are more
Tehnički vjesnik 22, 2(2015), 279-287
common [7, 8]. However, academic networks do contain
valuable information, such as proprietary academic
material and private personal data.
This research applies web crawling and keyword
searching, the core elements of a search engine, with
automated vulnerability detection to implement the
Website Security Mining System (WSMS), which we
applied to websites of the top 20 universities (ranked by
Quacquarelli Symonds) [9]. Comparing the difference
among these well-known universities’ security protection
schemes reveals some interesting phenomena which
deserve more attention in the web security community.
2
Introduction of the core system and techniques
The WSMS is designed to combine search engine
technology with vulnerability testing to automatically
spider and assess the security of a target website. Below,
the key technologies involved are discussed: search
engines, web vulnerability mining, and SQL injection
attacks.
2.1 Search engines
Although there are differences in the designs of every
search engine, the key components can be broken into
four categories: Web Crawler, Indexer, Searcher and User
Interface. The detailed functions are as follows:
• Web Crawler: A web crawler moves throughout the
internet, collecting web pages and metadata for use in
building the other components of a search engine
279
Implementation and analysis of website security mining system, applied to universities' academic networks
•
•
•
listed below. A web crawler typically starts at one
URL and then follows links on that web site to find
other URLs. Because content can rapidly change, a
web crawler needs to repeatedly revisit sites that it
has already visited previously.
Indexer: An indexer analyzes web pages that have
been downloaded by the web crawler, then sifts out
useless information and keeps useful information to
make a query index, which allows for fast information retrieval.
Searcher: A searcher uses the query index database
created by the indexer to determine which results to
display to the user. Searchers can be based on a variety of metrics such as quality, relevance, and popularity.
User Interface: A search engine is of little use if users
cannot access it. Therefore, a user interface is necessary to allow the user to query the search engine and
to display results in a human-friendly manner. A
search engine’s basic framework is depicted as Fig. 1.
Y. C. Cho
Figure 1 Framework for a search engine
Figure 2 Top ten web application threats
2.2 Web vulnerability mining
According to OWASP’s [53, 54] statistics in 2010,
SQL injection attacks are one of the most dangerous
attack vectors among web applications’ top ten security
threats, accounting for 18 % of all attacks. These statistics
are shown in Fig. 2 [53].
A weakness in a system’s security is also called a
vulnerability, which has been defined in RFC2828 [16] as
following: "A flaw or weakness in a system’s design
implementation or operation and management that could
be exploited to violate the system’s security policy".
There are two ways to analyze vulnerabilities:
• Static Analysis: Analyzes a web page’s source code
to attempt to find vulnerabilities. If one can control
all of a program’s behaviors, then one can find all the
possible interactions between user input and internal
program logic, which can reveal functional
parameters that may have problematic security
properties. By comparing known classes of
vulnerabilities against source code, static analysis can
identify potential flaws for developers to repair [17].
• Dynamic Analysis: Identifies security problems by
directly interacting with a functioning web site. In
other words, dynamic analysis relies on simulating
280
user interactions with web pages, including
interactions designed with potentially malicious
intent. Because dynamic analysis uses a real website
to find vulnerabilities in real time, found
vulnerabilities are much more likely to be real than
with static analysis, which has problems with
detecting false positives [18, 19].
Based on the above two general analysis technique
categories, many more specific analysis methods have
been created, some of which even combine static and
dynamic analysis [20]. For instance, black box testing,
fuzz testing and penetration testing are all growing
increasingly common.
Black box testing determines whether a web
application has vulnerability by inputting testing data to
the application and analyzing its response [21], as
opposed to white box testing which focuses on source
code parsing and analysis. White box testing tends to have
lower efficiency because it does not factor in the dynamic
interplay between the web server, application server, and
database server [22]. Therefore, it is more common to use
black box testing to more holistically analyze web
application’s vulnerability [23]. Fuzzing [24] is automatic
software testing technique that is based on vulnerability
Technical Gazette 22, 2(2015), 279-287
Y. C. Cho
Uvođenje i analiza sustava za probijanje sigurnosti web mjesta s primjenom na sveučilišne akademske mreže
injection which uses lots of invalid or even random data
as input to analyze whether vulnerabilities can be detected
in these abnormal scenarios. Fuzzing does not have the
False Positive problem caused by the static analysis, and
it also does not need lots of people to do the reverse
engineering because it can be highly automated.
Therefore, fuzzing is a technique that has high efficiency
and low cost [14, 15]. Fuzzing is widely used. Many
companies and organizations use it to improve the quality
of software; vulnerability analyzers use it to discover and
report vulnerabilities; and hackers use it to discover and
exploit vulnerabilities. Penetration testing is a method to
estimate the security of computer system or internet
security by actively simulating attacks [24, 25]. This
method analyzes all possible injection weaknesses in the
system, so the testing result is very valuable and
convincing. The end product is not simply potential
vulnerabilities, but verified vulnerabilities and exploits.
Honest testing result can form a bridge between developer
and information security communities [26, 27]. The
WSMS was created by combining several of these
concepts discussed above.
Fig. 3 is the format of an XML file. The bug file
parameter is a base64 hash and other parameters are
converted from the open source website vulnerabilities
database. Our system updates its vulnerability database by
adopting new vulnerabilities that have been announced on
the Exploit Database regularly [34]. By updating the
vulnerability database, we can ensure that the
vulnerability samples are always updated, similar to how
antivirus software regularly updates its virus database.
2.3 SQL injection attacks
SQL injection attacks [28] take advantage of the
process of web applications accessing databases with
queries based on improperly-validated user input. The
WSMS finds SQL injection attacks which can bypass
firewall and identity authorization to control the database
[29]. SQL injection can penetrate any type of database
that relies on SQL, regardless of whether the underlying
web application is written in ASP, PHP or JSP as long as
the program has a severe yet common logic error.
Although there are well-known techniques to combat
SQL injection attacks [30, 31], they are still quite
common and therefore there has been much interest in
developing methods to inspect web applications and
detect these vulnerabilities [29, 32, 33].
3
System implementation
In order to inspect whether information stored on the
web presents a security risk, this research combines a web
crawler, like those used in search engines, with the
concept of application vulnerability inspection,
specifically black box and penetration testing. The end
product is the WSMS, a tool to evaluate a website’s
security [36, 37]. This system can be separated into two
main modules which are the Static Mining Module and
the Dynamic Scanning Module. The Static Mining
Module inspects a specific website’s robots.txt, e-mails,
potential SQL injection URLs, files, and broken links.
The Dynamic Scanning Module uses the system’s
vulnerability-inspecting function by typing keywords into
a search engine’s query box to inspect many websites.
Both of the Static Mining and Dynamic Scanning
modules can lever the system’s vulnerability inspecting
function, which has two parts: known website
vulnerability inspection and SQL injection inspection.
The former compiles a database of open source website
vulnerabilities into an XML file which is used to inspect
the website to see whether it has the same vulnerability.
Tehnički vjesnik 22, 2(2015), 279-287
Figure 3 XML Format
The WSMS can find vulnerabilities in a variety of
database engines, specifically MS-SQL, MySQL, Access,
Oracle, Postgresql, and Sqlite. The steps to identify SQL
injection vulnerabilities are as follows. First, an injectable
point must be identified by inspecting the website for
places where user input may be used in SQL queries. If
such an injectable point is found, then further tests are
conducted to identify the specific type of database engine.
To do this, we take advantage of how different databases
use different function names for certain tasks. For
example, MS-SQL and MySQL use len( ) to calculate
length, while Oracle uses length() to do this. In other
words, when you use len(‘s’)=1 to test and receive a
normal response, the target website uses MS-SQL or
MySQL. On the other hand, if this does not work, then the
database might be Oracle or other database type. There
are several other functions that can help us determine
what the database is. After getting the database’s type, we
can obtain table and column names and finally get the
database’s data.
The WSMS can run on any operating systems which
are supported by Java. We describe the two basic modules
in more detail below.
3.1 Static mining module
The Static Mining Module runs depth mining on a
specific website. There is an option to determine whether
you want to follow the website’s robot.txt rules. Robot.txt
[35] is an ASCII-encoded file stored in the website’s root
directory that lists files that can and cannot be accessed by
search engine crawlers. There is no official standards
body or RFC for the robots.txt format. It was created by
consensus and ultimately serves only as a
281
Implementation and analysis of website security mining system, applied to universities' academic networks
recommendation for crawlers, so it cannot protect the
website’s private data completely. Other functions of the
Static Mining module are identifying e-mail information,
potentially injectable URLs, downloadable files, and
broken links, which may contain private information.
Y. C. Cho
through all of those URLs to fetch all links within them.
This type of method can be easily parallelized to improve
fetching speed. After files are downloaded by the web
crawler, an HTML parser process extracts pages’ URLs
and then adds it into the URL queue. Also, the system
will call vulnerability inspecting process to inspect URLs,
checking whether it has potential vulnerabilities or not.
Fig. 4 shows the process of mining a college’s
website [40] by our system. Several injectable URLs were
found and by exploiting these vulnerabilities we were able
to retrieve the database information shown in Fig. 5.
Additionally, we determined that the operating
system (OS) of the host was "Microsoft Windows XP
Professional", as shown in Fig. 6, which could open up
the possibility for further OS-based exploits.
3.2 Dynamic scanning module
Figure 4 Static mining module
The most popular search engines today are Google,
Yahoo, Baidu, Microsoft Bing, NHN, eBay, Ask.com,
Yandex and Alibaba. With the help of search engines, we
can find billions of web pages and their URLs. Our
system inspects these websites to determine whether they
have vulnerabilities by analyzing the results retrieved
from search engines. Our system supports the kinds of
query syntaxes used in modern search engines. After you
input the keywords, the system can find all related web
pages and inspect whether they are at risk for
vulnerabilities or not.
Figure 5 Database content found by injectable URLs
Figure 7 Working on different search engines
Figure 6 Operating system of the host
The Static Mining Module starts with a specific web
site and then collects all the related pages from it using a
breath-first search algorithm. The system assumes that
web pages have close relations to the original web page if
the link distance is within a certain range [38, 39], so it
will fetch all links inside the original page then iterate
282
Figure 8 Results of dynamic scanning
Technical Gazette 22, 2(2015), 279-287
Y. C. Cho
Uvođenje i analiza sustava za probijanje sigurnosti web mjesta s primjenom na sveučilišne akademske mreže
Fig. 7 shows the different query syntaxes used in
different search engines. For Google, it is "inurl:.asp?
site:edu nobel prize"; Yahoo is "inurl:.php? site:edu
education"; Baidu is "inurl:.jsp? site:edu research"; Bing
is "inurl:.aspx? site:edu academic".
This research used the same command, inurl:.asp?
|.jsp?|. php?|.aspx?site:com new, to search the ten most
popular search engines. 800 web pages were retrieved
from each search engine. We found 550 SQL injectable
URLs and 21 known website vulnerabilities out of this
total of 8000 web pages, which are shown in Fig. 8 below.
This highlights the fact that SQL injection problems are
still very severe on the internet.
4
Real experimental analysis
This research tested websites of the top 20
universities based on the Quacquarelli Symonds 2012
ranking by applying the Static Mining Module to gather
e-mail addresses and find injectable URLs. This analysis
was done on a single computer running Windows XP on
an Intel Core I3-540 processor and 1 GB of RAM. Each
university’s website was allotted a maximum of 72 hours
for analysis, although some analyses terminated before
the time limit.
Tab. 1 shows the number of e-mail addresses and
injectable URLs found after 72 hours’ mining the
websites of 20 universities. Six universities exposed over
ten thousands e-mail addresses and nine universities had
URLs that could be injected. In total, there were 152523
e-mail addresses and 34 injectable URLs detected in this
experiment. Fig. 9 below shows an example of the direct
output of the system in terms of e-mail addresses,
injectable URLs, and broken links.
Website
Massachusetts Institute of
web.mit.edu
Technology (MIT)
University of Cambridge
www.cam.ac.uk
Harvard University
www.harvard.edu
University College Lonwww.ucl.ac.uk
don (UCL)
University of Oxford
www.ox.ac.uk
Imperial College London www3.imperial.ac.uk
Yale University
www.yale.edu
University of Chicago
www.uchicago.edu
Princeton University
www.princeton.edu
California Institute of
www.caltech.edu
Technology (Caltech)
Columbia University
www.columbia.edu
University of Pennsylvawww.upenn.edu
nia
ETH Zurich (Swiss Federal Institute of Technolwww.ethz.ch
ogy)
Cornell University
www.cornell.edu
Stanford University
www.stanford.edu
Johns Hopkins University
www.jhu.edu
University of Michigan
www.umich.edu
McGill University
www.mcgill.ca
University of Toronto
www.utoronto.ca
Duke University
www.duke.edu
Tehnički vjesnik 22, 2(2015), 279-287
Number of
Injectable
URL
School
Number of
Mail
Table 1 Statistics of mail numbers and Injectable URLs in every university
12122
0
6075
8081
1
0
4589
4
15324
978
9056
2888
7434
2
0
7
0
1
6822
2
16732
4
7967
1
778
2
545
8733
10067
310
5056
11746
17427
5
9
4
1
10
14
6
Figure 9 Program output, showing-mail address, injectable URLs, and
broken links
The data from Tab. 1 is further summarized in Fig. 10
and 11 below, showing the distributions of e-mail and
injectable URL counts by university. From these two
figures, we observe that the universities which have over
a thousand leaked e-mail addresses account for 80 % of
the total in the experimental samples. This experiment
shows most universities do not take any extra steps to
process the "@" symbol, such as changing @ to "at" or
replacing it with a @ picture. As for the injectable URL’s
inspection, we found that nine universities have howintion
vulnerabilities which might let hackers gain access to
underlying databases for a variety of malicious purposes.
Figure 10 Bar chart of the amount of e-mail addresses found
for each university
Figure 11 Line chart of the number of injectable URLs found
for each university
Figure 12 Detailed analysis of injected URLs
283
Implementation and analysis of website security mining system, applied to universities' academic networks
Fig. 12 below shows details of the 20 universities’
websites, including database type, database name, and the
specific formats used for injection attacks. For further
research to explore the databases, we were able to identify
the content of databases, for instance as is shown in Fig.
13. Additionally, we found some databases that stored
user account passwords in clear text rather than hashing
them, shown in Fig. 14.
Y. C. Cho
characters to protect against such as "space",
"parentheses", "SELECT" or "INSERT" to expand the
scope of prevention, it is not sufficiently effective, but a
temporary solution. For instance, consider the following
queries:
SELECT/**/passwd/**/from/**/user
SELECT(passwd)from(user)
SELECT passwd from users where user=0x61646D696E
/* Hexadecimal encoding 0x61646D696E =admin*/
Despite the number of vulnerabilities we found, the
majority of websites were secure to our attempts thanks to
sound security practices. Practical approaches towards
protecting against SQL injection attacks are summarized
as follows:
Figure 13 Content in a database revealed by an injection attack
Figure 14 Accounts and passwords stored in the database
5
Response strategies
SQL injection has been a dangerous yet common
attack vector for many years. However, during our
penetration testing, we identified many cases of privacy
leakage, most commonly through the exploitation of SQL
injection vulnerabilities that should be fixed. Consider
this example in PHP:
$sql=“SELECT id,name,mail,cv,blog,twitter FROM
register WHERE id=
“.mysql_real_escape_string($_GET[‘id’]);
When an attacker uses a URL such as:
http://vuln.example.com/user.php?id=12,AND,1=0,u
nion,select,1,concat(user,0x3a,password),3,4,5,6,fro
m,mysql.user,where,user=substring_index(current_us
er(),char(64),1)
This attack may bypass the intended protection from
"mysql_real_escape_string" and instead allow for injected
code, since "mysql_real_escape_string" only creates
characters overflow of ", \r, \n, NULL, and Control-Z. In
the URL above, these characters are totally avoided in the
payload. Though the programmer may add in more
284
A. Pre-prepared Statements
Replacing the parameters in SQL statements with
prepared statements. Consider this prepared statement
written in Java:
String Stuname = request.getParameter(“studentName”);
//This should REALLY be validated too
//perform input validation to detect attacks
String query = “SELECT student_score FROM user_data WHERE user_name = ? ”;
PreparedSttatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, stuname );
ResultSet results = pstmt.executeQuery( );
From the programmer’s perspective, the semantics of
the SQL query remain the same using prepared
statements. However, attackers will fail to change the
structure of SQL when we use "?" as the parameter in
SQL statement. As is shown below in PHP, even if
attackers input string like tom’ or ‘1’ = ’1, database will
take it as username to query.
$query = “INSERT INTO myData (Name, Height,
Weight) VALUES (?,?,?)”;
$stmt = $mysqli->prepare($query);
$stmt = $bind_param(“sdd”, $val1, $val2, $val3);
$val1 = ‘Fred’;
$val2 = ‘177.7’;
$val3 = ’77.7’;
/* Execute the statement */
$stmt->execute();
Different methods are adopted for prepared statements
in each language:
• Java EE – use PreparedStatement() with bind variables
• NET – use parameterized queries like SqlCommand()
or OleDbCommand() with bind variables
• PHP – use PDO with strongly typed parameterized
queries (using bindParam())
• Hibernate – use createQuery() with bind variables
(called named parameters in Hibernate)
• SQLite – use sqlite3_prepare() to create a statement
object
Technical Gazette 22, 2(2015), 279-287
Y. C. Cho
Uvođenje i analiza sustava za probijanje sigurnosti web mjesta s primjenom na sveučilišne akademske mreže
B. Using Stored Procedures
The difference between stored procedure and prepared
statement is that stored procedure is defined and stored at
the database level, rather than the application level. Also,
a stored procedure itself might have an injection problem
if it is built from user input as a dynamic SQL query. In
that case, one should first apply strict input filtering to
deal with input data from users. In the code below,
sp_getStudentScore is a stored procedure:
String stuname =
request.getParameter(“studentName”);
//This should REALLY be validated too
try {
CallableStatement cs =
connection.prepareCall(“{call
sp_getStudentScore(?)}”);
Cs.setString(1, stuname);
ResultSet results = cs.executeQuery();
//… result set handling
} catch (SQLException se) {
//… logging and error handling}
Sometimes it is impractical to use prepared statements
or stored procedures, for instance due to working with
legacy code. In those scenarios, a strong focus must be
placed on filtering input data.
C. Data Type Inspection
Checking the data type of input data can prevent SQL
injection efficiently. The following PHP code restricts the
input data type to be an integer, which makes it uninjectable:
settype($offset, ‘integer’);
$query = sprint(“SELECT id, name FROM products
ORDER BY name LIMIT 20 OFFSET %d ;”,$offset);
Checking the data format and data type is very
beneficial. For example, when users input e-mail
addresses, time, and date, these formats can all be
checked to ensure that they are strictly adhered to. But
checking data type is not invulnerable, as if the request
needs the user to send arbitrary strings, for example, one
must take care to appropriately handle these strings.
D. Using Safety Functions
Nearly every web programming language has built in
functions to properly escape variables for use in SQL queries. When that is not available, each database vendor has
its own strategy to deal with it. Taking MySQL for example, it can use the following rules to encode characters:
NUL (0x00) \0
BS (0x08) \b
TAB (0x09) \t
LF (0x0a) \n
CR (0x0d) \r
SUB (0x1a) \z
“ (0x22) \”
% (0x25) \%
‘ (0x27) \’
\ (0x5c) \\
_ (0x5f) \_
All other non-alphanumeric characters with ASCII
values less than
Tehnički vjesnik 22, 2(2015), 279-287
256--> \c
where ‘c’ is the original non-alphanumeric character.
Also, we can use the functions of OWASP ESAPI which
are written by security experts, for instance:
ESAPI.encoder().encodeForSQL( new OracleCodec(),
queryparam);
Codec ORACLE_CODEC = new OracleCodec();
String query = “SELECT user_id FROM user_data WHERE
user_name = ‘ ” + ESAPI.encoder().encodeForSQL(
ORACLE_CODEC, req.getParameter(“userID”))
+ “ ‘ and user_password = ‘ “
+ ESAPI.encoder().encodeForSQL( ORACLE_CODEC,
req.getParameter(“pwd”) )
+ “ ‘ “;
Another fundamental principle of security is that the
web application should have the minimal amount of
power it needs to accomplish its task, and no more; this is
known as the principle of least privilege. If there are
different applications using the same database, then each
application should use a separate account that cannot
access the data from other applications. The database
account used by web application should not have the
authority to create functions or operate on files. If the
principles discussed above are followed, then SQL
injection attacks will become increasingly rare.
6 Conclusions and future work
Static and dynamic analysis cannot produce a full
picture of web site security; therefore, we can use code
review to make up for the deficiencies of static analysis
and penetration testing to make up for the deficiencies of
dynamic analysis. Penetration testing is invaluable in
improving the security of us applications. Deep
penetration testing, which executes human-like actions,
can make up the deficiencies of dynamic analysis. Similar
to how code review needs some specialized software to
do code inspection, penetration testing also requires some
domain-specific tools which can vastly improve
efficiency. Even though automated analysis tools are
growing more and more sophisticated, the human element
inherent in code review and penetration testing is still of
critical importance.
These days, there are many automated programs to
aim at data collection from the internet [55]. If harvested
e-mail addresses are sent malware, it could lead to many
security problems [41 ÷ 43]. From the inspection we ran
on university web sites, we found lots of academic
websites do not cover the characteristic of "@" to mask
email addresses and they also do not optimize robot.txt
settings [35, 44, 45], which let us easily find thousands of
mail addresses. However, there are also many academic
websites with more strict security procedures that do not
expose e-mail addresses and do not have injection
vulnerabilities [46, 47]. Furthermore, our research showed
that many databases on academic servers contained
valuable data (including passwords) in plaintext, which
could obviously be of great value to malicious hackers
who could exploit similar vulnerabilities to access
database content. This research reminds us that web
security is an important consideration in many phases of
web development, including database design and
285
Implementation and analysis of website security mining system, applied to universities' academic networks
application development. Software written with the best
of intentions may be vulnerable to creative attacks made
by humans with very different thought processes than the
software creators [48, 49]. The future of this research will
emphasize the comparative efficiency of vulnerability
detection [21, 50, 51, 52], keep expanding the
functionality of the WSMS, and work with the Exploit
Database [34] to use knowledge gained from our research
to improve vulnerability detection performed on other
websites. Then, as other researchers improve the state of
knowledge about vulnerabilities and thus improve our
work, a positive feedback loop will lead to enhanced
vulnerability analysis that can be used for any website.
7
References
[16] Shirey, R. Internet security glossary. // IETF The Internet
[17]
[18]
[19]
[20]
[21]
[1] Scott, D.; Sharp, R. Abstracting application-level web
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
286
security. // Proceedings of the 11th International Conference
on World Wide Web, ACM. (2002), pp. 396-407.
Curphey, M.; Endler, D.; Hau, W.; Taylor, S.; Smith, T.;
Russel, A. et al. A guide to building secure web
applications: The open web application security project,
OWASP. 2002.
Laribee, L.; Barnes, D. S.; Rowe, N. C.; Martell, C. H.
Analysis and defensive tools for social-engineering attacks
on computer systems. // Information assurance workshop.
IEEE. (2006), pp. 388-389.
Kotenko, I.; Stepashkin, M.; Doynikova, E. Security
analysis of information systems taking into account social
engineering attacks. // PDP, Euromicro international
conference, IEEE. (2011), pp. 611-618.
Huang, Y. W.; Yu, F.; Hang, C.; Tsai, C. H.; Lee, D. T.;
Kuo, S. Y. Securing web application code by static analysis
and runtime protection. // Proceedings of the 13th
International Conference on World Wide Web, ACM.
(2004), pp. 40-52.
Lin, J. C.; Chen, J. M.; Liu, C. H. An automatic mechanism
for sanitizing malicious injection. // ICYCS, The 9th
International Conference, IEEE. (2008), pp. 1470-1475.
Pan, C. C.; Yang, K. H.; Lee, T. L. Secure online
examination architecture based on distributed firewall. //
IEEE. (2004), pp. 533-536.
Riden, J. Responding to security incidents on a large
academic network-a case study. // IEEE, 2006.
Priyadarshini, R.; Aishwarya, S.; Ahmed, A. A. Search
engine vulnerabilities and threats-a survey and proposed
solution for a secured censored search platform. //
INCOCCI, IEEE. (2010), pp. 535-539.
Kleinberg, J. The CLEVER project, IBM.
http://www.almaden.ibm.com/projects/clever.shtml, 2010.
Accessed: August 15, 2013.
Wikimedia Foundation. Direct hit technologies. Wikipedia
Foundation.
http://en.wikipedia.org/wiki/Direct_Hit_Technologies,
2011. (15.08.2013).
N. L. Northern Light Search, NLG, LLC.
http://www.nlsearch.com/home.php, 2012. (23.08.2013).
Phillips, F. Scirus topic pages: New publication possibilities
for Moti researchers. // Management of Engineering and
Technology. (2009), pp. 2184-2189.
Chakrabarti, S.; Van den Berg, M.; Dom, B. Focused
crawling: A new approach to topic-specific web resource
discovery. // Computer Networks. 11, 31(1999), pp. 16231640. DOI: 10.1016/S1389-1286(99)00052-3
Lawrence, S.; Giles, C. L.; Bollacker, K. Digital libraries
and autonomous citation indexing. // Computer. 6,
32(1999), pp. 67-71. DOI: 10.1109/2.769447
Y. C. Cho
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
Society.
http://www.ietf.org/rfc/rfc2828.txt, 2002. (15.08.2013).
Xu, P.; Liu, W. A research of on-line static security
analysis based on WEB services. // APPEEC, IEEE. (2011),
pp. 1-4.
Weiser, M. Program slicing, IEEE transactions on software
engineering. // SE10. 4, (1984), pp. 352-357. DOI:
10.1109/TSE.1984.5010248
Phalgune, A. Testing and debugging web applications: An
end-user perspective. // VLHCC, IEEE Symposium, 2004.
Antunes, N.; Vieira, M. Comparing the effectiveness of
penetration testing and static code analysis on the detection
of SQL injection vulnerabilities in web services. //
Dependable Computing. PRDC, IEEE Symposium. (2009),
pp. 301-306.
Bau, J.; Bursztein, E.; Gupta, D.; Mitchell, J. State of the
art: Automated black-box web application vulnerability
testing. // SP, IEEE Symposium. (2010), pp. 332-345.
El Ioni, N.; Sillitti, A. Open web services testing. //
SERVICES, IEEE World Congress. (2011), pp. 130-136.
Khoury, N.; Zavarsky, P.; Lindskog, D.; Ruhl, R. An
analysis of black-box web application security scanners
against stored SQL injection. // PASSAT, IEEE Third
International Conference on Social Computing. (2011), pp.
1095-1101.
Bishop, M. About penetration testing. // Security &
Privacy, IEEE. 6, 5 (2007), pp. 84-87. DOI:
10.1109/MSP.2007.159
Antunes, N.; Vieira, M. Enhancing penetration testing with
attack signatures and interface monitoring for the detection
of injection vulnerabilities in web services. // SCC, IEEE,
International Conference. (2011), pp. 104-111.
Hwee-Joo, K.; Pauli, J. J. Web penetration testing:
Effectiveness of student learning in web application
security. // FIE. 2011.
Mainka, C.; Somorovsky, J.; Schwenk, J. Penetration
testing tool for web services security. // SERVICES, IEEE
Eighth World Congress. (2012), pp. 163-170.
Junjin, M. An approach for SQL injection vulnerability
detection. // ITNG, IEEE. (2009), pp. 1411-1414.
Chapela, V. Advanced SQL injection, OWASP Foundation.
2005.
Overstreet, R. Protecting yourself from SQL injection
attacks,
QuinStreet.
http://www.4guysfromrolla.com/
ASPScripts/PrintPage.asp?REF=%2Fwebtech%2F0619021.shtml, 2006. (01.09.2013).
Boyd, S. W.; Keromytis, A. D. SQLrand: Preventing SQL
injection attacks. // Applied Cryptography and Network
Security. (2004), pp. 292-302.
Anley, C. More advanced SQL injection. // NGSSoftware
Insight Security Research. 2002.
Anley, C. Advanced SQL injection in SQL server
applications. // NGSSoftware Insight Security Research.
2002.
The
Exploit
Database,
Offensive
Security,
http://www.exploit-db.com, 2012. (10.08.2013).
Sun, Y.; Councill, I. G.; Giles, C. L. Botseer: An automated
information system for analyzing web robots. // Web
Engineering, ICWE Eighth International Conference, IEEE.
(2008), pp. 108-114.
Cho, Y. C.; Pan, J. Y. Multiple-Feature Extracting Modules
Based Leak Mining System Design. // The Scientific World
Journal. Article ID 704865, Vol. 2013.
Cho, Y. C.; Pan, J. Y. Vulnerability Assessment of IPv6
Websites to SQL Injection and Other Application Level
Attacks. // The Scientific World Journal, Article ID 946768,
Vol. 2013.
Technical Gazette 22, 2(2015), 279-287
Y. C. Cho
Uvođenje i analiza sustava za probijanje sigurnosti web mjesta s primjenom na sveučilišne akademske mreže
[38] Shkapenyuk, V.; Suel, T. Design and implementation of a
[39]
[40]
[41]
[42]
[43]
[44]
[45]
[46]
[47]
[48]
[49]
[50]
[51]
[52]
[53]
[54]
[55]
high-performance distributed web crawler. // Data
Engineering, IEEE. (2002), pp. 357-368.
Najork, M.; Wiener, J. L. Breadth-first crawling yields
high-quality pages. // Proceedings of the 10th International
Conference on World Wide Web, ACM. (2001), pp.114118.
National Taiwan University. http://www.ntu.edu.tw/
english/, 2012. (20.08.2013).
Hoanca, B. How good are our weapons in the spam wars? //
Technology and Society Magazine, IEEE. 1, 25(2006), pp.
22-30. DOI: 10.1109/MTAS.2006.1607720
Geer, D. Malicious bots threaten network security. //
Computer. 1, 38(2005), pp. 18-20. DOI: 10.1109/MC.2005.26
Heymann, P.; Koutrika, G.; Garcia-Molina, H. Fighting
spam on social web sites: a survey of approaches and future
challenges. // Internet Computing, IEEE. 6, 11(2007), pp.
36-45. DOI: 10.1109/MIC.2007.125
Stassopoulou, A.; Dikaiakos, M. D. Crawler detection: a
Bayesian approach. // Internet Surveillance and Protection
ICISP, IEEE. (2006), pp. 16-17.
Tong, W.; Xie, X. A research on a defending policy against
the webcrawler’s attack. // ASID, IEEE. (2009), pp. 363366.
Central Police University. http://www.cpu.edu.tw, 2012.
(01.09.2013).
National Defense University. http://www.ndu.edu.tw, 2012.
(01.09.2013).
Arnold, A. D.; Hyla, B. M.; Rowe, N. C. Automatically
building an information-security vulnerability database. //
Information Assurance Workshop, IEEE. (2006), pp. 376377.
Avancini, A.; Ceccato, M. Security testing of web
applications: A search-based approach for cross-site
scripting vulnerabilities. // Source Code Analysis and
Manipulation (SCAM). IEEE International Working
Conference. (2011), pp. 85-94.
Fonseca, J.; Vieira, M.; Madeira, H. Testing and comparing
web vulnerability scanning tools for SQL injection and
XSS attacks. // PRDC, IEEE. (2007), pp. 365-372.
Fong, E.; Gaucher, R.; Okun, V.; Black, P. E. Building a
test suite for web application scanners. // Hawaii
International Conference on Syst. Sciences. IEEE. pp. 478478, 2008.
Chao, D.; Danfeng, Y.; Yun, Y. Fangchun, Y. A domainoriented distributed vulnerability scanning mechanism. //
Broadband Network and Multimedia Technology, ICBNMT, IEEE International Conference. (2009), pp. 832836.
OWASP Foundation. The ten most critical web application
security vulnerabilities. // OWASPF.
http://www.owasp.org/images/e/e8/OWASP_Top_10_2007
.pdf, 2007. (27.08.2013).
Williams, J. The ten most critical web application security
vulnerabilities. // OWASP Foundation, 2010.
Cho, Y. C.; Pan, J. Y. Design and Implementation of
Website Information Disclosure Assessment System. //
PLoS ONE, (2015). DOI: 10.1371/journal.pone.0117180
Author’s address
Ying-Chiang Cho
Department of Electrical Engineering,
National Chung Cheng University,
Chia-Yi 62102, Taiwan
E-mail: silvergun@mail2000.com.tw
Tehnički vjesnik 22, 2(2015), 279-287
287
Module 11: Windows Application Software for Security Vulnerabilities
Critical Thinking: Software Security
Assignment Details:
In an essay, review the following statements based on the readings from this week’s module:
•
•
Once your operating system is secure, you can focus on securing the software that runs in the operating
system.
Evaluate some of the most popular Microsoft applications and analyze how to make an application more
secure to protect your organization’s data. Describe at least three (3) techniques used to secure an
application.
Provide information from your readings to support your statements.
Requirements:
-
5-6 pages
3 references in addition to the case study
APA format
APA citation
- the essay must include introduction – body – conclusion – references
Required Reading the below materials:
https://doaj.org/article/a7ae190a2c3d49c2a824f9b788814966
And the two attached PDF files their names are tv_22_2015_2_279_287 and 1504.04971 and the
ppt file its name is SEU_CS566_winsec_ppt15_l12
Purchase answer to see full
attachment