Embed Size (px)
Citation preview
A Software Security Assessment
using OWASP’s Application
Security Verification Standard
Results and Experiences from
Assessing the DHIS2 Open-Source
Platform
Andrei Eismont
Thesis submitted for the degree of
Master in Informatics: Programming and Networks
60 credits
Department of Informatics
Faculty of mathematics and natural sciences
UNIVERSITY OF OSLO
Spring 2020
2
A Software Security Assessment
using OWASP’s Application
Security Verification Standard
Results and Experiences from Assessing
the DHIS2 Open-Source Platform
Andrei Eismont
© 2020 Andrei Eismont
A Software Security Assessment using OWASP’s Application Security
Verification Standard
http://www.duo.uio.no/
Printed: Reprosentralen, University of Oslo
Abstract
Security in a software product is a property organizations can not overlook
in this day and age, due to the sensitive and personal information they
need to protect. To ensure that software is secure and that "due care" has
been exercised, a standard can be utilized to measure one’s security posture
against industry best practices. This study aims to examine the application
of the Application Security Verification Standard (ASVS) on the District
Health Information System 2 (DHIS2) platform. By conducting an audit of
DHIS2, the thesis explores how DHIS2 compares against ASVS and what
the benefits and challenges of assessing DHIS2 using this standard are.
Interviews were conducted with members of the DHIS2 team, wherein
the participants would select applicable ASVS controls to DHIS2 and
then score them. The auditing results showed that DHIS2 failed to
achieve complete coverage of ASVS. In analyzing the results for themes
and patterns and drawing from personal experiences from conducting
the assessment, several benefits and challenges were discovered. First,
the data showed that ASVS’s selection of control was relevant to DHIS2.
Second, the ASVS results can be leveraged to address the shortcomings of
DHIS2, to find vulnerabilities, and to fix them through a secure Software
Development Life Cycle and other methods. The value of ASVS, however,
is dependent on the organization’s maturity and willingness to embrace
and invest in this process.
i
ii
Acknowledgements
First of, I would like to give a big thanks to my supervisors Johan Ivar
Sæbø and Nils Gruschka for their guidance and inspiration throughout
the project. Moreover I would like to thank the HISP team for their
involvement in this project. Thanks to Bob Joliffe for providing invaluable
input on my research.
And finally, a special thanks to my family for their continuous support and
encouragement.
iii
iv
Contents
List of Figures ix
List of Tables xi
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Research question . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Research context 7
2.1 Health Management Information Systems and HISP . . . . . 7
2.2 Distributed Health Information System . . . . . . . . . . . . 8
2.2.1 DHIS2 as a platform . . . . . . . . . . . . . . . . . . . 9
2.2.2 Configuring the platform and cloud hosting . . . . . 10
2.2.3 Collected data and metadata . . . . . . . . . . . . . . 11
2.2.4 Aggregate and patient data . . . . . . . . . . . . . . . 11
2.2.5 DHIS2 development . . . . . . . . . . . . . . . . . . . 12
2.2.6 DHIS2 security landscape . . . . . . . . . . . . . . . . 12
3 Relevant literature 15
3.1 Software development . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Secure Software Development Life Cycle . . . . . . . 16
3.1.2 Secure by Default . . . . . . . . . . . . . . . . . . . . . 17
v
3.2 Security Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 Security services . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Security controls . . . . . . . . . . . . . . . . . . . . . 19
3.3 Security standards . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.1 Cyber security standards . . . . . . . . . . . . . . . . 21
3.3.2 Information Security Management Systems . . . . . . 21
3.3.3 Application security . . . . . . . . . . . . . . . . . . . 22
3.4 Overview of selected security standards . . . . . . . . . . . . 22
3.4.1 Possible standard candidates . . . . . . . . . . . . . . 23
3.4.2 Application Verification Security Standard . . . . . . 24
3.5 Security and privacy regulations . . . . . . . . . . . . . . . . 28
3.5.1 Security regulations . . . . . . . . . . . . . . . . . . . 28
3.5.2 General Data Protection Regulation (GDPR) . . . . . 28
3.6 Security requirements and threats to an HMIS . . . . . . . . 29
3.6.1 Security in an HMIS . . . . . . . . . . . . . . . . . . . 29
3.6.2 Regulatory considerations when selecting a standard 30
3.7 Summary of Literature . . . . . . . . . . . . . . . . . . . . . . 31
4 Research approach 33
4.1 Project summary . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Qualitative and quantitative . . . . . . . . . . . . . . 35
4.2.2 Why ASVS? . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 General methods for data collection . . . . . . . . . . . . . . 37
4.3.1 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.2 Auditing methods . . . . . . . . . . . . . . . . . . . . 39
4.3.3 Tools used for data collection . . . . . . . . . . . . . . 39
4.3.4 Participant selection . . . . . . . . . . . . . . . . . . . 40
4.3.5 Approach to interviews . . . . . . . . . . . . . . . . . 42
4.4 Approach to the Applicability Phase . . . . . . . . . . . . . . 43
4.4.1 The checklist . . . . . . . . . . . . . . . . . . . . . . . 43
4.4.2 The procedure . . . . . . . . . . . . . . . . . . . . . . . 44
vi
4.4.3 Combining the data . . . . . . . . . . . . . . . . . . . 44
4.5 Approach to the Scoring Phase . . . . . . . . . . . . . . . . . 46
4.5.1 The checklist . . . . . . . . . . . . . . . . . . . . . . . 46
4.5.2 The procedure . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.3 Combining the data . . . . . . . . . . . . . . . . . . . 47
4.6 Approach to the Ranking Phase . . . . . . . . . . . . . . . . . 48
4.6.1 The checklist . . . . . . . . . . . . . . . . . . . . . . . 48
4.6.2 The procedure . . . . . . . . . . . . . . . . . . . . . . . 49
4.7 Data analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.8 Reflections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.8.1 Discussion between participants . . . . . . . . . . . . 50
4.8.2 Ethical considerations . . . . . . . . . . . . . . . . . . 51
5 Results 53
5.1 Part 1: Security audit results . . . . . . . . . . . . . . . . . . . 54
5.1.1 Applicability . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.2 Scoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.3 ASVS V1: Architecture, Design and Threat Modeling 56
5.1.4 ASVS V2: Authentication . . . . . . . . . . . . . . . . 57
5.1.5 ASVS V3: Session Management . . . . . . . . . . . . . 59
5.1.6 ASVS V4: Access Control . . . . . . . . . . . . . . . . 60
5.1.7 ASVS V8: Data Protection . . . . . . . . . . . . . . . . 61
5.1.8 ASVS V10: Malicious Code . . . . . . . . . . . . . . . 62
5.1.9 ASVS V12: File and Resources . . . . . . . . . . . . . 63
5.1.10 ASVS V14: Configuration . . . . . . . . . . . . . . . . 64
5.1.11 Updated scoring . . . . . . . . . . . . . . . . . . . . . 65
5.2 Part 2: Ranking results . . . . . . . . . . . . . . . . . . . . . . 66
5.2.1 Statistical results . . . . . . . . . . . . . . . . . . . . . 66
5.2.2 Critical and non-critical controls . . . . . . . . . . . . 67
6 Discussion and analysis 71
6.1 Summary of the results . . . . . . . . . . . . . . . . . . . . . . 71
6.1.1 Factors in applicability . . . . . . . . . . . . . . . . . . 72
vii
6.2 DHIS2 and the expectations of security in an HMIS . . . . . 73
6.2.1 Auditing results compared to ASVS levels . . . . . . 73
6.2.2 GDPR as a reference point for DHIS2 . . . . . . . . . 74
6.3 Possible solutions to software and implementation . . . . . . 75
6.3.1 Solving software related controls . . . . . . . . . . . . 75
6.3.2 Solving implementation related controls . . . . . . . 77
6.4 Relevance of an ASVS assessment . . . . . . . . . . . . . . . . 81
6.4.1 OWASP’s Top 10 as security standard . . . . . . . . . 81
6.4.2 Relevance of ASVS in a mature organization . . . . . 82
6.4.3 Time estimates for the audit . . . . . . . . . . . . . . . 84
6.5 Challenges and limitations to the audit . . . . . . . . . . . . . 85
6.5.1 Developer participation and consulting with mul-
tiple people . . . . . . . . . . . . . . . . . . . . . . . . 85
6.5.2 Outdated data . . . . . . . . . . . . . . . . . . . . . . . 86
6.6 Reflections upon the research conducted . . . . . . . . . . . . 86
6.6.1 Errors in the applicability spreadsheets . . . . . . . . 86
6.6.2 The author’s involvement in selecting applicability . 87
7 Conclusion 89
7.1 Research summary . . . . . . . . . . . . . . . . . . . . . . . . 89
Bibliography 93
Appendices 101
A Phase 1: Applicability spreadsheet 103
B Phase 2: Scoring spreadsheet 119
B.1 Updated scoring . . . . . . . . . . . . . . . . . . . . . . . . . . 131
C Phase 3: Ranking spreadsheet 135
viii
List of Figures
2.1 DHIS2 platform components (source: [39]) . . . . . . . . . . 10
3.1 Example of ASVS Authentication controls . . . . . . . . . . . 26
4.1 Original ASVS spreadsheet by OWASP . . . . . . . . . . . . 40
4.2 ASVS applicability spreadsheet . . . . . . . . . . . . . . . . . 44
4.3 ASVS applicably spreadsheets combined . . . . . . . . . . . 45
4.4 ASVS scoring spreadsheet . . . . . . . . . . . . . . . . . . . . 46
4.5 ASVS scoring spreadsheets combined . . . . . . . . . . . . . 47
4.6 ASVS ranking spreadsheet . . . . . . . . . . . . . . . . . . . . 49
ix
x
List of Tables
5.1 Results from the applicability phase . . . . . . . . . . . . . . 54
5.2 Results from the scoring phase . . . . . . . . . . . . . . . . . 55
5.3 Results from the scoring phase by level . . . . . . . . . . . . 55
5.4 Results from ASVS section V1 . . . . . . . . . . . . . . . . . . 56
5.5 Results from ASVS section V2 . . . . . . . . . . . . . . . . . . 58
5.6 Results from ASVS section V3 . . . . . . . . . . . . . . . . . . 59
5.7 Results from ASVS section V4 . . . . . . . . . . . . . . . . . . 60
5.8 Results from ASVS section V8 . . . . . . . . . . . . . . . . . . 62
5.9 Results from ASVS section V10 . . . . . . . . . . . . . . . . . 63
5.10 Results from ASVS section V12 . . . . . . . . . . . . . . . . . 63
5.11 Results from ASVS section V14 . . . . . . . . . . . . . . . . . 64
5.12 Updated results from the scoring phase . . . . . . . . . . . . 66
5.13 Phase 3 results from the security engineer . . . . . . . . . . . 67
5.14 Phase 3 results from the frontend developer . . . . . . . . . . 67
6.1 Failed ASVS controls . . . . . . . . . . . . . . . . . . . . . . . 72
xi
xii
Chapter 1
Introduction
The necessity of handling system security and information security in
particular is obvious when you look at the security breaches that have
occurred in the last decade alone. The web service provider Yahoo, for
instance, suffered an attack in 2013-14 in which the names, email addresses,
and dates of birthdays of approximately 3 billion users was compromised
[25]. The danger to the health industry is even greater, where a disruption
can lead to the endangerment of patient lives. In late 2019, a small town in
the Czech Republic suffered a cyberattack in which the staff was unable to
use x-rays, ultrasound or laboratory instruments, forcing operations to be
postponed or relocated to nearby hospitals [71].
Individual steps can be taken to prevent a breach but, identifying critical
measures without a comprehensive guidance document can be challen-
ging. To get an overview of one’s security posture and identify critical
weaknesses, a security assessment is required. A security assessment is
a measurement of the security apparatus (people, process, technology) of a
system, facility or organization [3]. In other words, the assessment looks at
the way security is designed and implemented and identifies weaknesses
and vulnerabilities in the implemented security controls. There are many
approaches to security assessments, like penetration testing, risk assess-
ment, threat modeling and vulnerability assessment. The method used
1
here is an internal audit of a health information system, using the Applic-
ation Security Verification Standard (ASVS) [47] standard of security- tech-
niques, and best practices to evaluate the company’s defenses and security
architecture. In other words, this means going through the requirements
found in ASVS, and deciding if they are applicable and if the proposed
solutions are in place. By comparing one’s personal security system with a
given frame of reference, an organization can discover critical weaknesses
and raise awareness [24].
This thesis looks at the application of ASVS on the District Health
Information System 2 (DHIS2) software, a health management platform
that stores information of 67 low and middle-income countries in which it is
used today [4]. Here the focus is on data security, centered around the CIA
principles: confidentiality, integrity and availability, all an integral part of
maintaining a healthy and secure information system. By using a standard
to assess DHIS2’s security, we also examine the process, the benefits and
the challenges of this process.
1.1 Background
This thesis project was among several initiated by the HISP group at
the University of Oslo (UiO), as part of a larger effort to evaluate and
strengthen the security of the DHIS2 platform. Penetration tests by external
organizations using DHIS2 had been done before, and for the findings to be
fixed requested, but no systematic security audit had been done previously.
This research involved collaboration with DHIS2 developers and other
members of the HISP group, who provided their knowledge and expertise
in things related to DHIS2.
2
1.2 Motivation
Security breaches can and will happen, from large corporations such as
Yahoo to smaller hospitals and medical service providers. At the time of
writing, the Coronavirus (COVID-19) has become a global pandemic [16],
and the health-care sector is more important now than ever. Still, hacker
groups are targeting hospital and medical services, with two recently
reported cases: an attack at the Champaign Urbana Public Health District
in Illinois, USA, taken offline on March 10. 2020 by ransomware attack1;
and again in the Czech Republic, an attack at the biggest hospital in the
country that shut down all computers and delayed coronavirus test results
[52]. These recent events underscore the importance of a capable security
infrastructure. DHIS2’s reach is enormous, and it is operated in countries
with poor resources and poor health systems [12]. Its databases contain
both aggregated and patient data. Therefore, protecting the privacy,
integrity, and availability of that data from external threats is critical,
especially today in the wake of COVID-19.
Scarfone, Benigni, and Grance from the National Institute of Standards
and Technology (NIST) state that, “while it is impossible to eliminate all
threats, improvements in cybersecurity can help manage security risks
by making it harder for attackers to succeed and by reducing the effect
of attacks that do occur” [54, Chapter 1]. No such systematic audit has
been done before for DHIS2. A security audit is, therefore, important to
assess the organization’s security posture against industry best practice, to
identify vulnerabilities and measure the effectiveness of the organization’s
controls. The motivation for doing this research is to explore this process
and the applicability of an ASVS-type standard on DHIS2. It is the wish of
the author that the research can also be relevant for similar organizations
and software. The audit results will give the reader insight into DHIS2’s
1Ransomware is a type of malware attack that blocks access to the victim’s system or
files until a ransom is paid
3
security posture, and the following discussion will explore the benefits and
challenges of the ASVS auditing process.
1.3 Scope
This thesis looks at the auditing process from selecting the security controls
found in ASVS, to scoring them as either pass or fail. Though instigated by
the author, the selection and scoring is done by the various HISP employees
at UiO who contributed to this research.
1.4 Research question
The purpose of this thesis is to do a security audit and then explore the
benefits and challenges in assessing the security of a software product
using a standard. First, benefits includes taking a broad perspective on the
value of a standard, as well as exploring what the audit results revealed
about DHIS2 and how this knowledge can be utilized. Second, challenges
involves reflecting on the limitations and issues discovered during the
auditing process. More specifically, the purpose of the thesis is reflected
in the following research questions:
How does DHIS2’s security compare against ASVS?
What are the benefits and challenges of using ASVS to assess DHIS2’s
security?
The first research question will be answered by first doing the audit and
giving an overview of the results, and the second will be answered through
an analysis of both the results and drawing from personal experiences from
doing the audit.
4
1.5 Chapter Overview
This thesis is organized into 7 chapters as follows:
Chapter 1: Introduction: presents the background of this thesis, motiva-
tion and proposes the research question.
Chapter 2: Research context: provides information on HISP and the DHIS2
platform.
Chapter 3: Relevant Literature: presents the relevant literature, including
an overview of software development, technical concepts, security stand-
ards, and finally a look at security regulations and threats to DHIS2.
Chapter 4: Research Approach: presents the research approach and how
the application of ASVS to DHIS2 was conducted.
Chapter 5: Results: presents the results from the ASVS auditing process.
Chapter 6: Discussion and Analysis: evaluates the results from the case
and present the learning outcome from the ASVS exercise.
Chapter 7: Conclusion: summarizes the discussion and concludes the
thesis.
5
6
Chapter 2
Research context
To follow the case study, the contextual background of this thesis is
required. First will be given a brief introduction to health information
systems and the Health Management Information System Project (HISP).
Next, an overview of the District Health Information System 2 (DHIS2),
with a particular focus on its architectural composition.
2.1 Health Management Information Systems and
HISP
An information system (IS) is defined as “formal, sociotechnical, organiz-
ational systems designed to collect, process, store, and distribute inform-
ation” [27, p. 28]. A health information system (HIS) is an informa-
tion system specific to the health sector, “designed to manage different
kinds of healthcare-related data and is one of the foundational blocks of
every health system” [6, p. 73]. Over the last couple of decades, there
has been an increased global effort to accommodate the inadequate health
status in developing countries, as existing HIS’s were either not well-
functioning or non-existing [6]. To tackle the many health-related chal-
lenges developing countries faced, a comprehensive health management
system (HMIS) needed to be implemented, such that the governments or
7
Non-Governmental Organizations (NGOs) would be able to “monitor, de-
tect and respond appropriately to public health emergencies” [6, p. 73].
The Health Management Information System Project (HISP) is one of those
efforts.
Originated in South Africa after the fall of apartheid in 1994, the project
was backed and developed in collaboration with local health activists,
university students, and information system developers [6]. Coordinated
from the University of Oslo (UiO) in Norway, HISP today is a global
network comprising of several independent HISP groups, all of who help
design, implement and sustain health information systems in over 100
developing countries around the world, including Indian states and the
majority of Africa. The HMIS at the core of this effort is the Distributed
Health Information System (DHIS).
2.2 Distributed Health Information System
Braa and Sahay define the DHIS software as a “free and open-source
software platform for the collection, management, analysis, and use of
health data” [13, p. 1]. Following its inception in 1994, DHIS has gone
through several iterations. The latest generation, DHIS2, was launched in
2005 and is currently on its 33rd release. Decades later, today the software
is relied upon by Ministries of Health and NGO’s all across the globe,
covering an estimated 2.28 billion people [6]. While the software core is
developed by a team at UiO, it is part of a larger HISP ecosystem, local
groups who “support the implementation of DHIS2 in their countries and
regions based on their domain knowledge, technical and implementation
expertise and experience” [6, p. 75]. These on-site observations from local
HISP groups and other action-based research projects ensure that DHIS2
evolves to meet the many use cases and challenges that people need to
solve.
8
2.2.1 DHIS2 as a platform
A platform can be defined as a group of technologies - at the center of
which is a core used as a foundation on which outside parties can build
products or services [64]. The platform provides a set of core functionality
and an interface through which applications can interoperate. DHIS2 can
be perceived as a platform based on these criteria. The following is an
explanation of DHIS2’s three main components and their boundaries, as
illustrated in figure 2.1, as well as the interface that links them all.
Generic core. The main component of the DHIS2 platform is the core, a
web-based solution that can run on most browsers and phones. The core
consists of two parts: an SQL database and the Java-written codebase. This
is the building block on which other applications can build upon.
Bundled apps. The second component is the bundled apps that come with
the core package, developed by the same core DHIS2 team at UiO.
Custom apps. The third component is the custom apps. The platform’s
modular architecture allows it to be extended not only by apps but add-
ons, plugins et cetera. This allows local developers to create applications
specific to their use cases.
The Web API. The API supplies the interface between the user and
the application. An external or internal application fetches data from
the database in the form of a resource, in order words, anything the
client might want to interact with. This resource could be patient data,
configuration information et cetera. The web API allows the implementors
to create custom apps that communicate with the core and the underlying
database. Although each core given to the local implementors is the
same, custom apps can alter the design of an individual DHSI2 instance
significantly.
9
Figure 2.1: DHIS2 platform components (source: [39])
2.2.2 Configuring the platform and cloud hosting
When downloading DHIS2, it is empty of any content. The platform
instance needs to be configured to a specific context and filled with data.
The basic idea of DHIS2 is to provide a basic set of functionality to all
countries and health facilities that implement it. By providing a flexible
data structure, implementors can adapt the software to suit their specific
problem or the laws or regulations that exist on the handling of private
data in their country or region.
An implementors responsibility for deploying a reliable and secure DHIS2
instance includes the following (selected) actions [22]:
• Human resources with skills in relevant technologies such as web
servers and database systems.
• Reliable backup of your system including safe storage at a remote
server.
• Use of SSL (HTTPS/encryption) to keep private information like
passwords secure.
• Monitoring of server resources and application performance.
• Secure server environment to avoid unauthorized access, theft and
10
fire.
When the DHIS2 project was created, it was important from the start that
“the project invested significant resources in building expertise in HIS in
the countries where HIS was implemented” [6, p. 74]. Today, this effort
includes training in system implementation, maintenance, integration with
other systems and software development of external apps. The implication
of having a highly configurable, open-source platform is that aspects of
DHIS2 can only be secured by the UiO development team, while other
aspects of security need to be addressed at the implementation level.
2.2.3 Collected data and metadata
DHIS2 data can be described in two terms: collected data and metadata.
Collected data is the data gathered from patients and districts, like data
entered by a desk clerk or a doctor. There are three dimensions to this
data: the what, where and when. What refers to the value measured by the
indicator, e.g. the number of new measles outbreaks, pregnancies. Where
records where a data value was collected or where a health event took
place. When gives a period or a timestamp for when the data was collected.
Metadata refers to the data “describing your data” [1]. For instance, say
you are tracking the mortality rate among infants aged less than five years
old. This data would be collected in what DHIS2 calls a dataset. This
dataset is configured by the implementors, who specify how often the data
is to be collected, what indicators are to be used, which health facilities it
applies to et cetera.
2.2.4 Aggregate and patient data
DHIS2 stores three types of data: user data, patient data, and aggregated
data. Patient data, recorded by a health worker during a patient’s visit,
pertains to information about a single individual, such as their name, age,
medical history and diagnosis. There are two functionalities (apps) for
11
registering individual entities: the Tracker and Event Capture modules. In
the case of pregnancy, the Tracker app can be used to log when the baby is
due, when the next scheduled checkup is set, et cetera. The Event Capture
app is used to capture singular events. An event is not necessarily tied to a
specific individual by a name or id, but information such as height, gender
and the nature of the event are registered, as are any comments written by
the health worker.
Aggregate is a collection of data, such as the number of pregnancies within
a region or the cases of ebola outbreaks. This data is used as a statistic to
generate reports to help health facilities and governments to track events
and allocate their resources accordingly.
2.2.5 DHIS2 development
DHIS2 is developed in (agile) teams (more on the definition of Agile
development in the next chapter). Four main teams work on different parts
of the platform: Apps, Android, the Tracker module, and Analytics. Each
team consists of a frontend and backend, both of which have team leads.
Also, there are supporting services: UX and Quality Assurance.
The DHIS2 team keeps track of two separate Jira boards. A Jira board is
used to report issues, follow requirements, progress, and roadmap for the
DHIS2 software [23]. One is public, and the other is private to the core
team.
2.2.6 DHIS2 security landscape
DHIS2 has experienced security breaches before. Machines have been
taken over and data has been exposed (through an open database
configuration). There are known architectural defects, the results from
penetration tests, reports from the field et cetera. These can be addressed
by the software team. However, the main challenge in regards to security
is with implementation.
12
The implementors are not security experts. The different countries in which
DHIS2 is implemented also frequently do not have a strong regulatory
environment or institutions to promote good security practices. The
consequence of this are many badly configured systems, with poor (or no)
TLS configuration, naive (or no) proxy setup, no firewalls, no monitoring,
inadequate physical environments, and poor management of users and
roles. There are remedies to these problems, such as better guidance, better
training materials, and better tools. And there has been significant progress
in these areas, particularly in regards to training for server administrators.
For the development team, the software release process has improved
greatly also.
13
14
Chapter 3
Relevant literature
This chapter will present relevant literature that is deemed appropriate
for the topics concerned in this thesis. First is an introduction to
software development models followed by an overview of relevant security
concepts. Second, the concept of a standard will be presented as well
as relevant standards for the assessment of DHIS2. And finally, a brief
explanation of security laws and regulations within the health sector and
data protection in general, followed by an overview of the threat-landscape
for an HMIS.
3.1 Software development
A development model describes the software development lifecycle of a
development process [60]. It helps provide a common understanding of
the software building process, such that developers can easier define what
work has to be accomplished during each phase. One of the oldest of
the development models is the Waterfall model [8]. Here, a development
process consists of five phases: requirements, design, coding, testing, and
maintenance. Each phase needs to be fully completed before continuing
to the next, and this process lasts throughout the entire project. At the
opposite end of that spectrum is the Agile model, currently used by the
15
DHIS2 development team. Here, the software is developed in iterations
lasting between 2 and 3 weeks, called a sprint, during which each phase
of the software development lifecycle (SDLC) is repeated for that sprint.
Before each sprint begins, tasks are selected from a backlog to be developed
during that iteration. In stark contrast to the Waterfall method, the agile
method places a large emphasis on quick delivery and allows for a clearer
set of priorities for developers to work on.
3.1.1 Secure Software Development Life Cycle
An SDLC defines the process used by organizations to build an application
or a feature from start to finish [55]. Regardless of the development model,
the prime reason for using an SDLC is that it provides a framework for
a standard set of activities, such as planning, building and maintanence,
and ensures that the project is planned, tracked and controlled throughout
its life cycle [66]. In the past, it was common practice to perform
security related-activities only as part of testing. However, this resulted in
security-related bugs being discovered too late. To address this issue, the
secure software development life cycle was invented, meant to integrate
security-related activities in every step of the development process [41].
This ensures that activities such as penetration testing, code review, and
architecture analysis are an integral part of the development effort [57].
Alternatively, these principles can be referred to as Security by Design
and Secure by Design, two terms often used interchangeably, meaning that
software has been designed from the foundation to be secure.
The integration of an security into your SDLC has many benefits, some of
which are [43]:
• Making security a continuous concern.
• Raise awareness of security issues.
• Early detection of flaws in the system.
16
An example of an SSDLC is the Microsoft Security Development Lifecycle,
launched in 2004 as a response to the growing PC market and equally
growing threat landscape [5]. The SDLC was developed such that it would
help integrate security-related practices found in the SDLC into the agile
development environment, including training in secure coding techniques,
secure code review and threat modeling.
3.1.2 Secure by Default
The United Kingdom’s National Cyber Security Centre (NCSC) writes that
“technology which is Secure by Default has the best security it can without
you even knowing it’s there, or having to turn it on” [56]. Though closely
related to Security by Design, the by Default philosophy revolves around
building software that is configured by default to be as secure as possible.
This is beneficial not only to system administrators but, as Gorski and
Iacano explain, also to non-security workers, who “benefit from safeguards
being in place by default as this avoids vulnerabilities resulting from a lack
of knowledge, comprehension or attention” [31, p. 1]. A selected few of
Secure by Default principles as listed by the NCSC are [56]:
• security should never compromise usability – products need to be
secure enough, then maximize usability
• security is never a goal in and of itself, it is a process – and it must
continue throughout the lifetime of the product
• security should not require extensive configuration to work, and
should just work reliably where implemented
• security should not require specific technical understanding or non-
obvious behavior from the user.
Poor set-up or configuration of technology increases the risk of system
vulnerabilities being exploited, either unintentionally by its users or
purposefully by hackers.
17
3.2 Security Concepts
Security is a wide field of study with many concepts, principles, and
services. This section will give a brief overview of a few concepts relevant
to the discussion on security and standards.
3.2.1 Security services
How secure a system is strongly depends on the security requirements
and the security measures that are in place. With respect to information
systems and system security in general, the CIA (Confidentiality - Integrity
- Availability) principles are important [53]. The security spectrum
also includes accountability, authentication, non-repudiation, and other
concepts. For this thesis, the CIA principles should provide the reader with
adequate background on information system security.
Integrity
Integrity is to protect assets from unauthorized modifications or destruc-
tion. Integrity encompasses both data integrity (all digital information)
and system integrity (state of the system ) [30, p. 34-37]. In the context
of DHIS2, tampering with health data is a breach of integrity.
Confidentiality
Confidentiality is to protect assets from being disclosed to unauthorized
individuals [30]. A breach of confidentiality can both be accidental and
intentional and can come from a bug or poor configuration that leads to
disclosure of information.
18
Availability
Availability ensures the availability of data and resources to authorized
individuals. It is crucial to all systems, in particular cloud services and
information systems. An attack on availability is best illustrated by the
DoS (Denial of Service) attack, which overloads a server’s resources, thus
hindering legitimate users from accessing their data.
3.2.2 Security controls
IT security is about protecting assets that are of value to the organization.
This includes people, property and information. A standard will often
include a series of controls for the purpose of reducing or mitigating the
risk to those assets. Security controls are divided into these three categories
[51, p. 12-13]:
• Physical
• Technical
• Administrative
The control category is selected based on the organization’s objective.
The aforementioned three categories are by type, but controls can also be
categorized by function: preventive, detective, and corrective. For this
thesis, only the former is required to understand ASVS. Note that in this
thesis, the words controls and requirements are often used interchangeably.
A security requirement can be defined as a “security feature required by
system users or a quality the system must possess to increase the users
trust in the system they use” [69]. The ASVS standard, for instance, names
each category and subcategory as requirements. The items themselves, are
typically referred to as controls.
The following is an overview of the three control types [51, p. 12-13].
19
Physical controls
Physical controls deal with the tangible, as in preventing or detecting
unauthorized access to information through the use of locks, security
guards, alarms, motions sensors, and similar measures.
Technical controls
Technical controls are security measures that use technology as a basis for
authorizing access to sensitive data and protecting assets. This includes
authentication solutions, firewalls, antivirus software, cryptography, intru-
sion detections, forensics, and other measures.
Administrative controls
Administrative controls (also called procedural in literature) are security
measures that take into account the human factor. It refers to the policies,
procedures, or guidance that define work-place practices when handling
sensitive information, be it at rest or in use.
3.3 Security standards
A definition of a standard as defined by Webster is that it is “something
set up and established by authority as a rule for the measure of quantity,
weight, extent, value, or quality” [20]. Standards are applied everywhere:
it is the celsius scale, date format and the rules by which the web
communicates. In the context of health information, a standard is a
common set of guidelines for the “the collection, reporting and use of
health information by all developing countries and global agencies” [26].
In the case of application security, a standard provides a set of best-practice
security techniques or requirements that, if followed, gives confidence
that the application is secure. Further, the standard allows developers to
20
compare “their personal security system with a given frame of reference
adopted at an international level” [65, p. 128]. In this chapter, the words
standard and framework are sometimes used interchangeably.
This section will give an overview of a few standards relevant to DHIS2.
In the security field, standards are typically categorized based on the
objective. The following sections give info on three such categories:
cyber-security standards; information security standards; and application
security. Note that a standard can belong to multiple categories.
3.3.1 Cyber security standards
“Cyber Security, a subset of information security, is the practice of
protecting systems, networks, and programs from digital attacks” [68].
Cyberattacks caused by cyber threats seek to access, change and destroy
sensitive information. Part of the cybersecurity process is knowing what
the critical data is, where it is stored, and what technology needs to be
implemented to protect it. An example of a cybersecurity standard are
the CIS controls, though all standards in this chapter contain cybersecurity
safeguards.
3.3.2 Information Security Management Systems
An ISMS is a “systematic approach to managing sensitive company
information so that it remains secure” [34], which includes people,
processes, and IT systems. Like cybersecurity standards, an ISMS seeks
to minimize risk and reduce the impact of a security breach. However, an
ISMS focuses more on the management side of the company, meaning it
recognizes that security breaches can occur both due to human errors and
errors in the company’s structure. For example, an employee can cause a
security breach by accident, with no malicious intent, or purposely, in both
cases causing significant damage. Examples of an ISMS is the ISO/IEC
27000-series and NIST’s SP 800-53.
21
3.3.3 Application security
Application security is the measures taken to improve the security of an
application during the application’s lifecycle. This involves finding, fixing
and preventing security vulnerabilities, through a wide range of techniques
such as code review, white-box security review and black-box security
audit. Whereas cybersecurity is directly aimed at defending against
cyberattacks, application security involves the entire SDLC process. The
Application Security Verification Standard is an example of an application
security standard.
3.4 Overview of selected security standards
The project was presented with ASVS in mind. Chapter 5 will present
an argument why it was the correct choice. But to understand ASVS’s
place within the standard landscape and present a valid argument for
ASVS’s selection, giving background on and comparing ASVS to other
standards was important. Not all software products are alike, nor are
all organizations and their security goals. Available manpower, cost, and
regulatory compliance are all driving factors behind selecting a standard.
These standards presented here as candidates for DHIS2 were selected
based on three criteria. First, the standard had to be general-purpose
or health-specific. Unfortunately, standards tailored to the health-sector
are few, and those that are relevant, such as HIPAA (Health Assurance
Portability and Accountability Act) [62] - often referred to as a standard,
are more concerned about information from a management point of view,
rather than a technical one. The second criteria is that the standard had to
be internationally-recognized and accepted by the professional community.
And third, the standard had to be relatively modern.
Section 3.4.1 presents a few possible standards that could have been used
to audit DHIS2. Section 3.4.2 then gives an in-depth description of ASVS,
22
written in more detail compared to the other standards as it was chosen for
the task of auditing DHIS2.
3.4.1 Possible standard candidates
ISO/IEC 27000-series
The International Organization of Standardization (ISO) develops and
publishes standards, one of which is the ISO/IEC 27000-family [34]. The
pillar of the series is the ISO/IEC 27001 standard. An example of an
ISMS, the standard provides guidelines on how to establish, implement,
operate, monitor and maintain an information system. Moreover, the
Annex A section of the publication contains over a hundred security
controls, covering both the physical, the administrative, and the technical
side of security. However, ISO/IEC 27001 only establishes what to do,
but not how to do it. A sibling standard, the ISO/IEC 27002, provides
concrete implementation guidelines on how to achieve a requirement from
the Annex. While 27001 does not mandate a specific action, 27002 includes
plenty of suggestions for corrective and preventive actions.
The Norwegian National Security Authority (NSM) advises corporations
to follow a standard like the ISO/IEC 27001 as their security framework
[45]. A bank, for instance, with several offices and possibly hundreds of
employees handling high-value transactions, will require a management
policy, internal organization structure, incident management rules and so
on, such as provided by ISO/IEC 27001 – in addition to the technical and
physical controls.
NIST SP 800-53
NIST SP 800-53, shorthand for National Institute of Standards and
Technology Special Publication 800-53, also an ISMS, provides a catalog
of technical, operational and administrative security controls [44]. For each
23
of its 1000+ security controls, SP 800-53 outlines what to examine, whom to
interview, and what to test. The publication is relatively large, due to the
fact that it was designed for governmental applications and information
systems – in particular, to facilitate compliance with federal legislations
and directives. A smaller, international software company may find the
size of its content daunting, and its vast amount of controls irrelevant.
Center for Internet Security
An example of a Cybersecurity standard, the CIS controls (Center for
Internet Security) consist of 20 actionable control categories, spread across
3 sections: basic (the essentials for cybersecurity defense), fundamental
(technical best practice), and organizational (aimed at the people involved
in maintaining a cybersecurity defense) [63]. At a glance, the framework
lacks the depth and specialization that other standards such as ASVS offer.
And that is by design. As the document states: “this is not a one-size-fits-all
solution, in either content or priority” [14, p. 3]. The CIS controls provide
a baseline for a strong security foundation that applies to all industries,
from healthcare to retail, and seek to secure various asset types, such as the
application, network, data, users and devices.
3.4.2 Application Verification Security Standard
The following section is an in-depth description of the Application Security
Verification Standard. ASVS was developed by the Open Web Application
Security Project (OWASP), a non-profit, community-driven organization
dedicated to web application security [70]. In order words, ASVS was
created by developers for developers. The latest version, 4.0.1, was released
in March of 2019. The objective of the standard is to “normalize the range
in the coverage and level of rigor available in the market when it comes
to performing Web application security verification using a commercially-
workable open standard” [47]. What this means in practice is that the
24
standard provides measures that can be adapted to any project of any size.
The applications of ASVS are many. One listed by OWASP is to use
ASVS as a “blueprint to create a Secure Coding Checklist specific to your
application, platform or organization” [9, p. 10]. Another, as a security
architecture guidance, or for secure development training. For this project,
the security audit route was taken.
Verification levels
ASVS operates with three ranges of levels to help developers classify
or describe the size of their project. Each tier offers additional security
requirements targeted at more security-critical projects (see figure 3.1). The
levels are:
• Level 1. According to the document, level 1 is the “bare minimum
that all applications should strive for” [9, p.10]. It is also the only
level that can be checked either by using automatic tools or manually,
without access to the source code.
• Level 2. This is for most applications. Projects that should strive for
this level of verification are applications that process transaction data,
store personal information about individuals or process health care
information.
• Level 3. This is the highest verification that can be achieved. Projects
that should strive for this level of verification are applications that
require a significant level of security. This can include health and
safety, military or day-to-day governance in critical infrastructure.
Security requirement sections
As of the 2019 revision, there are 14 security requirement sections. Each
section has controls typically grouped into subsections that are of similar
functionality. The session management category, for example, consists
25
Figure 3.1: Example of ASVS Authentication controls
of 7 subcategories, such as cookie-based requirements and token-based
requirements. This split helps the user in tailoring the standard to
their project, by selecting sections and subsections that apply to their
application. For each category and sub-category of requirements, there is a
description, along with external references for further reading.
Below is a short description of three of those sections.
V2. Authentication
Authentication is concerned with the authentication between the user and
the service. This concerns, for example, how passwords are generated,
which cryptographic algorithms are used, and how those passwords are
stored and encrypted. An example control is to verify that passwords are
at least 12 characters in length.
V5. Validation, Sanitization and Encoding
The most common web application weaknesses are those concerning a
lack of input validation from the client, which leads to several well-
known vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection.
An example control in this section is to verify that unstructured data is
sanitized, i.e. the input is checked against allowed characters and length.
26
V13. API and Web Service
These are measures to ensure that applications that use API’s are properly
secured. This requires proper authentication, session management, and
authorization. A possible situation that could occur is a user sending
malicious data as part of the POST payload. To combat this, input
validation of all parameters is required.
The remaining security requirement sections are
• V1. Architecture, Design and Threat Modeling
• V3. Session Management
• V4. Access Control
• V6. Stored Cryptography
• V7. Error Handling and Logging
• V8. Data Protection
• V9. Communications
• V10. Malicious Code
• V11. Business Logic
• V12. File and Resources
• V14. Configuration
Note that the 3.0 version of the ASVS standard contained a mobile section,
which in the 4.0 release has been retired in favor of a separate checklist
dedicated entirely to mobile security. The document also contains an
Internet of Things (IoT) appendix, which is part of a separate OWASP IoT
project. However, it is not considered part of the main branch, and due to
its irrelevance to the DHIS2 project, it was not included in the audit.
27
3.5 Security and privacy regulations
3.5.1 Security regulations
Security regulations are directives on how information technology and
computer systems should be protected [19]. There are industry-specific
regulations, such as the Payment Card Industry Data Security Standard
(PCI-DSS) [50] for the banking industry or the HIPAA for the U.S. health
sector [62], and then there are general data protection laws. In Norway,
the EU’s GDPR (General Data Protection Regulation) applies [29]. Many
African countries have taken inspiration from GDPR and implemented
regulations with a similar set of laws [36]. Therefore, the GDPR is worth
exploring with respect what it says on information security.
3.5.2 General Data Protection Regulation (GDPR)
The GDRP is a privacy and security law that came into force on May
25, 2008, with the mission to “modernize laws that protect the personal
information of individuals” [28]. Though formed by the European Union
(EU), its laws apply to all who target and collect data on EU’s citizens
[15]. The stated goal of the legislation is to harmonize data privacy laws
across Europe, in addition to giving greater data protection and rights to
individuals [29].
GDPR covers personal and sensitive personal data. Personal data in this
context means a piece of information that can be used to identify a person,
such as a name, address et cetera, whereas sensitive data encompasses
genetic data, religion, sexual orientation. Of particular interest to this
thesis is Article 25, which communicates requirements for data protection
(privacy) by design and by default when handling sensitive data [10]. Both
concepts share similarities, but take different approaches to data protection.
Closely related to Security by Design as defined in section 3.1.1, Data
Protection by Design is centered on data protection rather than software
28
development in general [61], encouraging organizations to “implement
technical and organizational measures, at the earliest stages of the design
of the processing operations, in such a way that safeguards privacy and
data protection principles right from the start” [67]. Data Protection by
Default is concerned with ensuring that personal data has the highest
privacy protection, e.g. short storage period, limited accessibility, and more
information is not disclosed than necessary.
3.6 Security requirements and threats to an HMIS
The digital revolution has brought many benefits to the health sector,
including the ability to track and mitigate disease outbreaks at a speed
hitherto impossible, but it has also created a new threat landscape [12]. This
section examines the security threats to DHIS2 and the health industry in
general.
3.6.1 Security in an HMIS
With the digitization of health information, this has created new tempting
targets for hostile actors, seeking to exploit vulnerabilities in today’s digital
systems [12]. Health data stored in electronic form is today at its greatest
risk, particularly in third-world countries who may lack the infrastructure
to respond or recuperate from an attack. The type of actors and their
motivation, for example, could be “states wishing to exaggerate or cover up
an outbreak by hacking these systems or falsifying data within them; mask
an ongoing biochemical or bioweapons attacks; or prosecute a politically
motivated attack on an individual or group through the corruption of
health data” [12, p. 1].
Breach of integrity and availability are the greatest threats to digital
systems [12]. For example, changing a persons’ blood type in the HMIS
database could have severe consequences for a patient’s health, whereas
29
the availability of DHIS2 could impact the health worker’s ability to record
the correct data (though DHIS2 supports offline mode). This would affect
the government’s or health worker’s ability to monitor the health status of
its citizens, and hinder their ability to track and monitor a pandemic.
A health system, like any other software, can be compromised through a
variety of attacks, such as phishing, malware, ransomware, SQL injection,
Cross-Site Request Forgery, Denial of Service (DoS), et cetera. Concerning
DHIS2, the authors of Weaponizing Digital Health Intelligence list insufficient
encryption and software errors as the biggest challenges to DHIS2’s
security [12]. The encryption concern deals with the implementors’
reliance on cloud services such as Amazon and their unfamiliarity with the
vulnerabilities found in those services. The second issue: software errors,
stresses the importance of a secure software product. An error, a bug, could
give absolute control to the attacker, and thus access to the entire database.
3.6.2 Regulatory considerations when selecting a standard
Depending on the country or political union in which software is operated,
it may be subject to local regulations and laws. These compliance
frameworks would set the conditions and guidelines for how organizations
should store, transmit and process personal information. In Europe, there
is the GDPR, which covers all personal information. In the United States,
there is HIPAA for the health sector. The story is entirely different in third-
world countries. For many of the countries that use DHIS2 as their main
HMIS, regulations are either non-existing or in their infancy. Still, data
protection laws in Africa have seen an increased push in the last 20 years,
particularly in the last decade [37]. As of this writing, 25 out of 54 African
countries have passed some form of data protection laws, such as Uganda,
Nigeria, and Egypt [40]. India, too, has seen an increased push to regulate
citizen data, with a new, GDPR-inspired data protection bill proposed at
the end of 2019 [35].
30
3.7 Summary of Literature
Security is important in the development process and of the finished
product. To achieve confidence that your application is secure and
followed methods endorsed by the international security community, a
standard can be followed, of which there are many. One is ASVS, which
will be used in this thesis to assess DHIS2’s security. ASVS was designed
for the web, providing a large selection of controls for web applications and
web services of all types. The leveled structure of this standard allows for
both larger and smaller projects to scale and achieve verification.
31
32
Chapter 4
Research approach
The following chapter will introduce the research approach and the
methodologies used in this thesis. It will begin with a quick recap of
the project, followed by a methodology section describing the research
strategy. Next, an overview of the general methods applied to all phases of
the data gathering process will be given, followed by a closer look at each
phase in detail. Next will be a brief overview of how the data is analyzed
and how it will be used to answer the research question. Finally, the chapter
will conclude with a few reflections on the research approach.
In this thesis, the words "assessment" and "audit" are often used inter-
changeably, although each word has a slightly different meaning. Accord-
ing to Abdel-Aziz, “auditing is measuring something against a standard,
while assessing is determining how good or bad something is, but not
necessarily measuring it against a specific standard”, and that while “the
main focus of an audit is to check for compliance, the main focus of an as-
sessment is to help the organization improve its security posture” [3, p. 4].
An audit is a type of security assessment. The main task of this thesis is an
audit of DHIS2 using ASVS. But in doing the audit, we also seek to give
the results some context, and determine if they are "good or bad", and to
provide guidance on how to use that information to improve DHIS2’s "se-
curity posture". In other words, the thesis is an assessment of DHIS2 using
33
an auditing approach.
4.1 Project summary
The original idea of this project centered on continuous security testing,
using ASVS as a secure coding checklist during the development process.
Throughout the research process and discussion held with my supervisors,
the research aims were redefined to what it is now: an audit of DHIS2’s
security controls and a look at the benefits and challenges to assessing
DHIS2 using ASVS. The research approach was also highly influenced by
the availability and willingness of HISP to contribute to this project. The
plan was for the audit to be completed before or during the summer of
2019, by the participants in their own time, without my intervention. Then,
group interviews were considered but were unrealized due to scheduling
conflicts.
The main source of data for this project came from the ASVS audit, the
nature of the study being of a qualitative nature, but with quantitative
results. What this means is that while the results contain a measure of
statistical data in the form of failed and passed controls, the majority of
the data comes from the one-to-one interviews held with DHIS2 team. The
quantitative results are used to answer the first objective of this thesis: how
does DHIS2’s security compare against ASVS? This is used in conjunction with
the qualitative approach to give context to the results, highlighting patterns
and themes. The data from the interviews would tell a story, one of people
with different positions at HISP, with a different approach and possibly
contradictory opinions. The same data, together with personal experiences
of conducting the audit, is then used to answer the second objective of this
thesis.
34
4.2 Methodology
The methodological approach of this project is the ASVS audit. This process
will utilize two modes of data collection: qualitative and quantitative. Both
of these approaches are described below. Also, the choice to go with ASVS
is argued for.
4.2.1 Qualitative and quantitative
Research methods are generally classified in two ways: a qualitative and
a quantitative approach. There are several ways to distinguish between
them. One such distinction, made by Shields and Twycross, defines
qualitative as a “method used when something needs to be measured,
while qualitative methods are used when a question needs to be described
and investigated in depth” [59, p. 24]. While a measure of quantitative
data is part of this thesis, and answers the first objective, the research of
this project falls under the qualitative canopy, as the main source of data
originates from the one-to-one interviews conducted with the HISP team.
The research is driven by the need to examine how various people at the
HISP team evaluate the applicability or scoring of security requirements,
based on unique and possibly conflicting points of view. The qualitative
approach allows us to capture this form of data, as it is best suited for
the “collection, organization, and interpretation of textual material derived
from talk or conversation” [32, p.109].
The qualitative approach best suited to record this form of data is the
interview, considered to be the most commonly used qualitative data
collection tool [17][7]. Using an excel spreadsheet of ASVS controls, this
project will utilize the qualitative approach to interview people who work
at HISP. By inquiring how developers, security engineers et cetera evaluate
security aspects of their system, we form stories, stories that help paint a
detailed picture of DHIS2 and the process of conducting a security audit.
By examining the quantitative results and the qualitative data gathered
35
through the interviews, this thesis can address the second objective and
discuss the strengths and weaknesses of using ASVS to assess DHIS2.
4.2.2 Why ASVS?
Though the project was presented with ASVS in mind, it was important to
consider other options and give a broader look at the standards landscape.
In the end, the selection of ASVS came down to one deciding factor: the
standard’s relevance and applicability to the development of the DHIS2
core and apps. The main, deciding factor is OWASP’s focus on web
security, but other factors played a role as well.
First, the focus on the development of DHIS2 meant that only technical
controls were directly applicable to DHIS2. Although HISP assists in
setting up local instances of DHIS2, they cannot provide nor enforce
physical and administrative guidelines on the implementors. An ISMS,
in general, would a perfect fit for DHIS2, with its focus on information
security and day-to-day security policies and procedures in the handling
of that information. In theory, any governmental or health group is free
to implement a standard such as ISO 27001 to guide their administrative
policy. However, that is beyond the reach of the development team, and
outside the scope of this thesis.
Second, all the standards presented in section 3.4 have different aims. The
goal of the CIS controls, for instance, is to protect against cyberattacks.
That is an essential part of every standard listed in this thesis, but it does
not address information security directly, nor the root cause of security
vulnerabilities: a secure software development life cycle. Both the ISO/IEC
27000-series and NIST’s SP 800-53 address all three security controls types:
technical, administrative, and physical, only one of which is relevant to
DHIS2. The relative simplicity of ASVS is important too. The sheer size
of standards like the ISO 27001 and 27002 make it too complicated for
a thesis of this size, as translating its numerous controls into checkable
36
requirements would be a massive task in on itself.
4.3 General methods for data collection
This section outlines the general data collection methods used for this
project. This will include an overview of the interview method, auditing
methods, tools used to collection the data, participant selection, and the
general approach to the interviews.
Note that since the last round of interviews in early December, several
requirements have since been fixed. To avoid having to continuously
update the results and the text on which it is based, a line must be drawn.
The ASVS results presented in this thesis will, therefore, be based on the
December 2019 ASVS findings, as will the discussion that follows. A short
summary of the updated scoring is presented in section 5.1.11.
4.3.1 Interviews
The interview method comes with a set of preconceptions. Coughlan
defines the one-to-one interview as offering “the researcher the opportunity
to interpret non-verbal cues through observation of body language, facial
expression, and eye contact” [17, p. 310]. The aim of this study is only
to capture the spoken or written word about technical matters, and is
not a study of the participants themselves. The interview method was
chosen because it is particularly useful for getting the story behind a
participant’s choice or experience [46]. As Grossoehme notes, interviews
“explore experiences of individuals, and through a series of questions and
answers, the meaning individuals give to their experiences” [32, p. 110].
The interview approach taken for this thesis is elaborated below.
37
Semi-structured interview format
There are three interview types to consider: structured, semi-structured
and unstructured. The interview type that you choose depends on the
“research question and the information needed to provide holistic answers
to these questions” [7, p. 150]. The type chosen for this thesis is a semi-
structured interview approach, a hybrid of structured and unstructured.
Less rigid than structured, and more focused than unstructured, this type
of interview is where “questions are pre-planned prior to the interview but
the interviewer gives the interviewee the chance to elaborate and explain
particular issues through the use of open-ended questions” [7, p. 151]. This
form of an interview follows an interview schedule with predetermined
topics and questions. However, as Coughlan explains, “the flexibility of
the semi-standardized interview allows the interviewer to pursue a series
of less questioning and also permits the exploration of spontaneous issues
raised by the interviewee to be explored.” [17, p. 310].
The reasoning for selecting the semi-structured approach is two-fold.
First, structured interviews are considered too strict, which removes the
“flexibility of the interviewer in terms of being able to interrupt, and the
interviewee to elaborate, is restricted” [7, p. 151]. They are akin to a
questionnaires survey, whereby there are no deviations from the sequence
of questions. While the interview is structured in the sense that there
are a set of predefined questions, and the interviewee is asked to discuss
each of the security requirements in sequence, the questions themselves
are broad, and the participant is allowed to take the discussion to hitherto
unthought-of places. The depth of the responses is highly dependent on
the participant’s familiarity with the topic. Due to this fact, it is not a
requirement that all questions about a particular control are answered.
38
4.3.2 Auditing methods
This section outlines the methods used during the auditing process. Data
collection in this thesis comes in three phases. The ability to be able to
proceed to the next phase was dependent on the completion of the previous
phase. The three phases of data collection can be described as follows:
1. Applicability. In the first phase, security controls applicable to the
DHIS2 platform from ASVS are identified and checked as either
applicable or non-applicable.
2. Scoring. The second phase consists of scoring the applicable security
controls as either pass or fail.
3. Ranking. The final phase is to rank and discuss the importance of
each failed control.
The first two phases are part of the ASVS auditing process. The third phase
was added to better address the second objective of this thesis. By having
the participants rank the importance of the failed controls, this thesis is able
to reflect on the relevance of ASVS controls and ASVS in general.
All phases share similarities in how the participants were chosen and
how the interviews were conducted. The following sections describe the
similarities, including a brief overview of the participants, tools used for
data gathering, and the procedure.
4.3.3 Tools used for data collection
ASVS contains 286 security controls spread across 14 chapters. To present
the list in an easily readable and available manner, an excel spreadsheet
was utilized, downloaded directly from OWASP’s official ASVS website.
This spreadsheet had each control categorized into one of the 14 sections,
and gives three columns for each level, with a x indicated whether given
control is applicable to level 1, level 2 or level 3. For each phase, this
spreadsheet was forked and modified with new columns to gather new
39
data, and each modification was in turn duplicated for every participant.
Each of these files was kept on a personal Google Drive account.
Figure 4.1: Original ASVS spreadsheet by OWASP
4.3.4 Participant selection
The goal with selecting participants is to do “purposeful sampling” [7,
p. 152], i.e. pick people at DHIS2 with different areas of expertise that
can provide different viewpoints for the assessment. For example, one
participant in this study is a backend developer, while another helps
with implementation. Whereas the former might evaluate a security
control form a technical point of view, the latter might look at it from
the imlementor’s point of view. The goal was to get as many people
involved as possible, but this was not a priority. Nor was it necessarily
required. Alsaawi argues that having several people involved is good, but
that you should be careful of saturation, wherein “the interviewer begins to
hear the same information he/she has already obtained from the previous
interviews” [7, p. 152]. The DHIS2 team is relatively small, with few people
who have a technical overview of the entire system. For example, there
40
are presently two backend tech leads. The remaining backend developers
mainly work on specific modules, and therefore might lack the same level
of knowledge of the entire system to be able to contribute to the audit.
In total 5 people participated in this project, all of whom are either a part of
the DHIS2 development team or part of HISP, all with different roles within
the organization. Not all participated in each phase of the project, but for
every phase, there were always at least two participants. The following is
an overview of the five participants.
Participant 1. Participant number 1 is a backend developer. Having joined
the company in 2015 on a part-time basis, he is now one of the two backend
tech leads.
Participant 2. Number 2 has worked as a frontend tech lead and product
manager for the platform’s web app development since 2017.
Participant 3. The third participant joined the DHIS2 core team in late 2019
as a software security engineer, whose job is to oversee the entire security
framework of the platform.
Participant 4. The fourth participant is responsible for quality assurance for
new releases of DHIS, and has been with the company for approximately
two years. In this text, this participant is commonly referred to as the
release manager.
Participant 5. The last participant is a senior implementation engineer
and was part of the group who proposed this project. This person works
directly with implementation and helps set up new instances of DHIS2,
and has a good overview of the challenges with security in DHIS2 at the
implementation level. In this text, this person will be referred to as the
implementor or implementation engineer.
41
4.3.5 Approach to interviews
The interview approach differed for each phase and with each participant,
but there were also similarities, which this section will highlight. First,
each participant was given a clean copy of an ASVS spreadsheet. During
the interview, the interviewer would sit down with the interviewee and
go through all of the 286 controls on the list. In a couple cases, this was
also done through a video call. What is meant by clean copy is that the
participants were not aware of each other’s answers. This was done for two
reasons. The first is so a participant would not be influenced by another
participant’s answer, and the second was to gather an alternative opinion
and point of view on an already checked and/or unchecked control. Given
that group sessions was not an option, it was important to gather each set of
data in isolation. However, the results from one session were occasionally
used during another session to gather more data on specific controls. For
example, if one participant was unsure about a control’s applicability or
pass/fail status, or a particular comment was unclear, then an effort was
made on the interviewers part to draw the interviewees attention towards
that control.
Second, during each interview, the participant would either write down
their opinion directly in the spreadsheet themselves, or the interviewee
would. Simple note-taking is generally not ideal, due to the large amount
of data that can come from an interview [7]. However, that which was
written down was often a summarization of participant’s words and not
a direct transcription of every word spoken. Recording audio, while also
registering which of the 286 controls the participant was currently looking
at, would have been problematic and could possibly have prolonged
the interview. Their spoken word was written down and refined in the
moment.
When needed, an email was sent to a participant asking to clarify or
elaborate their opinion on a particular control.
42
4.4 Approach to the Applicability Phase
The first phase of this project is to establish which ASVS security require-
ments apply to the DHIS2 platform. The spreadsheet will differentiate
between four different states of applicability and non-applicability.
• Software. The first state are controls that are directly applicable to
and can only be addressed by the DHIS2 development team.
• Implementation. The second state concerns controls that target
security aspects outside of the development team’s control, such as
server setup, firewalls, and configuration. The responsibility for
securing these controls lies with the implementors.
• Semi-applicable. This revolves around controls that apply both to
the development team and the implementors.
• Non-applicable. The last state are controls that do not apply to
DHIS2, either due to irrelevant functionality or other causes.
While controls that are implementation only are technically non-applicable
- and the results chapter will list them as such, it was important to register
the cause for why they are not applicable. The interesting context of DHIS2
is the difference between software and implementation, which separates
DHIS2 from other software products.
4.4.1 The checklist
The original ASVS spreadsheet was forked and modified to include
additional columns, as seen in figure 4.2. First is an Applicable column,
used to register a control as applicable to software and the responsibility of
the development team. Second is a column for comments. And the third is
to register a control as applicable to Implementation, either exclusively or in
combination with software.
43
Figure 4.2: ASVS applicability spreadsheet
4.4.2 The procedure
Four people participated in this phase of the project. The following
paragraphs describe the process for each participant.
Implementation engineer. The participant lives in the United Kingdom,
and the interviews were therefore done through video calls. Due to time
limitations, all but the last two chapters of ASVS were covered.
Release manager. This interview took place at UiO. Here, approximately
half the controls were covered.
Frontend developer. This interview took place at UiO. All comments were
written by the participant during the interview.
Backend developer. This session occurred simultaneously with the scoring
phase, since contact with the participant was not established until after
the first phase had been completed. During this session, several controls
skipped over by the previous participants were looked over.
4.4.3 Combining the data
The data from the participants was copied into a single document that lists
their responses side-by-side for comparison. Then, a set of criteria was
44
applied to combine the responses and create a single column of applicable
requirements that can be used in the next phase. An example of this is
shown in figure 4.3. The frontend developer, for example, selected 242
controls as applicable out of 286.
Figure 4.3: ASVS applicably spreadsheets combined
The following is the criteria by which the collected checkboxes were
evaluated:
• A control remains checked if all participants have checked it.
• A control remains checked if three of the four participants have
checked it.
• A control remains checked if two of the four participants have
checked it.
For example, in figure 4.3, 3 of 4 participants selected control 1.1.1 as
applicable. Therefore, the control is checked in the rightmost column.
For all these criteria, there are exceptions. A comment may be provided that
tips the scale in one direction or another. For example, a control wherein
only one participant checked it as applicable is checked as applicable in the
final list only if a good argument was provided. Ideally, the interviewer,
whose knowledge of DHIS2 is that of an outside party, should not be the
one to evaluate the strength of the argument. In a few instances, however,
strength of the argument could not be ignored and the comment was taken
45
into consideration. Where comments and opinions differed, and there was
no clear resolution, the control was checked, to be re-evaluated in the next
phase. The same set of criteria was applied on the implementation column.
4.5 Approach to the Scoring Phase
The second phase of this project is to score the applicable controls from the
previous phase, as either pass or fail. While controls for all three levels of
ASVS will be graded, the primary goal is to establish a benchmark against
the first level.
4.5.1 The checklist
The applicable results from the previous phase were copied into a new
spreadsheet and new columns were added. A pass column was added
to register when a control passed, and an uknown column was used to
register when a participant did not have an answer. This is show in figure
4.4.
Figure 4.4: ASVS scoring spreadsheet
46
4.5.2 The procedure
Three people participated in this phase of the project. The discussion
around each control was kept open, though a few guidelines were
given before the interviews began. In particular, the participants were
encouraged to comment on the failed controls. For both the frontend and
backend developer, the interview sessions took place at their offices at UiO.
The third participant, the security engineer, was initially only approached
to contribute to the third phase of the project. However, several controls
had been left unresolved from the second phase due to conflicting answers.
The security engineer offered to provide a third opinion on these controls.
The participant was given full editing rights to a copy of the results, and
scored them at his own time.
4.5.3 Combining the data
The data from the participants was copied into a single document that lists
their responses side-by-side for comparison. Then, a set of criteria was
applied to combine the responses and create a single column, to set the
controls in one of four states: pass, fail, unknown, or conflict. An example
of which is shown in figure 4.5, where the first three columns belong to the
participants, and the rightmost column is the combined result.
Figure 4.5: ASVS scoring spreadsheets combined
The following is the criteria by which the checkboxes were evaluated:
47
• A control is passed (green) if two out of three participants passed it.
• A control is passed (green) if checked by at least one participant and
skipped by the rest.
• A control is marked as a conflict (yellow) if the responses differ.
• A control is marked as unknown (pink) if all participants skipped the
control.
• A control is marked as failed (red) if failed by majority.
Unlike in the previous phase, no attempt was made by the author to resolve
the conflicts by evaluating the comments given by the participants. The
final results should stand as they are, a reflection of the agreements and
disagreements between the participants.
4.6 Approach to the Ranking Phase
In the third and final phase of this project, we rank the severity and
importance of the failed controls from the previous phase. This phase is
not part of the official audit process. Rather, the purpose of this phase
is primarily to gather data on the relevance of ASVS controls. The idea
is to replicate a process or discussion that could occur after an audit is
completed where the participants deliberate and prioritize which issues are
most critical to fix. All controls that are unequivocally failed are evaluated
here, regardless of level.
4.6.1 The checklist
The aggregated spreadsheet from the previous phase was copied and a new
column added for comments.
48
Figure 4.6: ASVS ranking spreadsheet
4.6.2 The procedure
Two participants were involved in this phase of the project: the frontend
developer and the security engineer. Both interviews occurred in early
December 2019, through a video call with the security engineer, and at UiO
with the frontend developer. For each failed control, the participants were
encouraged to answer these three questions:
• How important is this requirement? If so, why?
• Has DHIS2 experience and/or is experiencing any issues related to
this control?
• Are there any challenges to implementing this control?
The participants were also asked to give a control a rank from a scale of 1
to 5, where 5 is high and 1 is low. The qualitative data would give insight
into what the participants think is most important to fix and not to fix,
whereas the scales would be used to get an overview of the number of
critical and non-critical controls. A scale of a 1-5 range was selected due to
its simplicity, which is particularly useful to get concise and direct answers
that do not require interpretation or deep analysis.
49
4.7 Data analysis
The data analysis will be used as a means to make sense of the audit results.
In analyzing the data, the first and partially the second research question is
answered. To address the first objective, the quantitative results from the
scoring phase are merged, and a final verdict is given on DHIS2’s coverage
against ASVS.
To answer the second research question, all three phases will need to
be analyzed to find patterns and themes in both the quantitative and
qualitative results. For example, controls will be categorized based on
responses. A control relevant to implementation due to regulatory reasons,
is marked to one category, and a control relevant to implementation due
to configuration, is marked to another category. This separation allows us
to discover controls/vulnerabilities of similar types that can be addressed
through similar measures.
4.8 Reflections
4.8.1 Discussion between participants
For the interviews, the decision was made not to let the participants see
each other’s answers. The benefit this approach yielded the project is
that each participant was given the opportunity to provide an alternative
opinion or background information on a given control. The concern with
letting the participants see each other’s contributions was that they would
be less encouraged to elaborate or provide an alternative argument if
already covered by someone else.
Had the participants been able to view their predecessors’ answers, this
would result in a different set of data, one in which the participants would
be given a chance to weigh in on the previous answers, and possibly
explain why they are wrong. By reading the previous responses, the
50
participants would also have the opportunity to discover an angle they
had not considered. In the selected approach, this is not possible, and for
this reason, the interviewer has to evaluate comments that contradict one
another.
However, this alternate approach is still not ideal. The last participant
always has the last say, and could, in theory, be wrong in their stance. In
these situations, the interviewer would still need to evaluate the comments,
both the last and the ones that came before. The previous participants
are also unable to give a rebuttal. For these reasons, the data in this
approach, while does form more of a discussion, is not necessarily more
correct. Would this alternative approach have resulted in fewer conflicting
opinions? This is difficult to determine without repeating the study.
4.8.2 Ethical considerations
“Sensitive information is data that must be protected for the privacy or
security of an individual, group, or organization” [58]. There was concern
that releasing this thesis could potentially disclose damaging security
vulnerabilities in DHIS2. Disclosing such information, and if exploited
by an attacker, could result in damage to the organization, DHIS2, and
indirectly to the health and personal information stored within. Before the
publication of this thesis, the data was looked over by DHIS2’s security
engineer and the content cleared for publication. The verdict was that
the majority of information on vulnerabilities is abstract, and while may
provide hints, the attacker will still need to do a lot of work to exploit the
vulnerabilities found in this audit.
51
52
Chapter 5
Results
The results presented in this chapter were generated from conducting the
three phases of data gathering, as described in previous chapter. Due to the
size of the spreadsheets, this chapter will present an abridged, summarized
version of the results. The results in full can be found in Appendix A,
Appendix B, and Appendix C.
The first two phases are presented in section 5.1. In presenting the results,
the first two phases will answer the first research question of this thesis:
How does DHIS2’s security compare against ASVS?
The full context and meaning of the results will be given in the next chapter.
Here, the results will be presented quantitatively and qualitatively, giving
the statistical results from the audit, as well as highlighting discovered
patterns and themes in the answers gathered through the interviews. First
will be given an overview of the results from the entire audit, followed
by a deeper dive into a select few ASVS categories. These sections will
highlight four types of themes: 1) applicable controls; 2) non-applicable
controls; 3) controls applicable both to software and implementation; 4)
and disagreements between the participants. The results from the third
phase are then presented in section 5.2.
53
5.1 Part 1: Security audit results
5.1.1 Applicability
The following is an overview of the results from the applicability sessions,
as show in table 5.1. The full results from this phase can be found in
Appendix A.
• Applicable. 258 out of 286 ASVS controls are applicable to the DHIS2
development team.
• Semi-applicable. 69 of the 258 apply to software and implementation
both. These are controls that have to be implemented both by the
DHIS2 development team and by the local implementors.
• Non-applicable. 28 controls from ASVS are non-applicable. 16 of
these concern implementation and 12 functionality that DHIS2 does
not have.
Table 5.1: Results from the applicability phase
5.1.2 Scoring
Table 5.2 shows the results from the scoring phase. The color-coding in the
table reflects the colors assigned to the four states a control could be in:
passed (green), fail (red), conflict (yellow) and unknown (pink). The full
results from this phase can be found in Appendix B.
• Passed. 174 of the 258 applicable controls were assessed as pass. This
equals to approximately 67% of all controls.
54
• Fail. 50 controls were assessed as fail. This equals to approximately
19% of all controls.
• Conflict. 5 controls had conflicting answers from the participants.
• Unknown. No one could give a definite score to 29 of the controls
Table 5.2: Results from the scoring phase
As the last two points illustrate, the results in this phase are inconclusive.
Scoring by level
One goal of the assessment was to see how DHIS2 compares against the
first level of ASVS, labeled by OWASP as the "bare minimum that all
applications should strive for" [9, p. 10]. Achieving this level (and higher
levels) is important to DHIS2 given its status as a health information
management platform. Table 5.3 gives an overview of the results in each
level.
For the first level, 92 out of 128 applicable controls are a pass, approxim-
ately 71% of all controls. The remaining controls are either fail or unre-
solved. The percentage number is 62 and 53 for the second and third level
respectively.
Table 5.3: Results from the scoring phase by level
55
5.1.3 ASVS V1: Architecture, Design and Threat Modeling
This chapter covers all things related to secure software development,
including many aspects of secure architecture: integrity, availability, non-
repudiation, confidentiality, and privacy. Spanning 14 subcategories,
covering the architectural requirements of each of the base ASVS sections,
this chapter is the only section with level 2 and above requirements.
Table 5.4: Results from ASVS section V1
Applicability
As table 5.4 shows, 37 of the 42 controls in this section are applicable
to DHIS2. The remaining 5 apply to implementation only, one example
of which is control 1.2.1, describing the testing of “unique or special
low-privilege operating system accounts for all application components,
services, and servers”. This control, like many others, is only relevant for
someone who is hosting the platform, as affirmed by all participants. The
remaining 4 are similarly unchecked, dealing with firewalls, proxies and
policies, all implementor responsibility.
Of the 37 applicable to software, 17 are also partly applicable to imple-
mentation. Control 1.7.1, concerning data and activity logging, is one such
example. The frontend developer writes: “for DHIS2 this is applicable for
the core team, for surrounding software such as Nginx (webserver), the im-
plementor is responsible”. In other words, most things logging-related on
the server-side are an implementation responsibility, who themselves need
to analyze the data.
An occurrence of disagreement was with control 1.8.1, dealing with
the identification and classification of data into protection levels. The
implementor left is unchecked, arguing that the local governments classify
56
the data, not the developers. Though left unchecked, the implementor also
added that it is up to the developers to allow the application to classify
data, an opinion seconded by the frontend developer, who, in contrast,
checked it as applicable.
A correct configuration of DHIS2 is important to ensure that the platform
is secure. A control applicable to implementation in this context is 1.12.2,
which states: “Verify that user-uploaded files are stored outside of the web
root”. According to the release manager, this is configurable, and data can
be configured to be stored inside the web root. An attacker or even a local
user can then willingly or unwillingly upload a malicious file onto their
DHIS2 instance.
Scoring
In the scoring phase, 23 controls passed, 11 failed, and 2 are unresolved.
A control of interest is 1.14.6, which illustrates the point of needing to
consult with different people with different areas of expertise. The control,
dealing with the use of unsupported, insecure or deprecated technologies
such as Flash (among the many listed), was checked as pass by the frontend
developer. The backend developer, on the other hand, failed it, stating that
DHIS2 currently uses other client technology that they know to be insecure.
However, the control was still marked as a yellow, due to the conflicting
scores.
5.1.4 ASVS V2: Authentication
“Authentication is the act of establishing, or confirming, someone [or
something] as authentic and that claims made by a person or about a device
are correct, resistant to impersonation, and prevent recovery or interception
of passwords” [9, p. 20].
57
Table 5.5: Results from ASVS section V2
Applicability
Table 5.5 shows that 44 out of 57 controls in this section are applicable
to DHIS2. The remaining 13 requirements either address functionality
that DHIS2 does not have or concern implementation. With the latter,
an example is with control 2.2.6 on the use of one-time passwords (OTP),
lookup codes or cryptographic authenticators for replay resistance. These
services, according to all participants, are not provided by DHIS2, with
the backend developer noting that they use another form of protection.
The question here is whether the alternative method is good enough or
is better than the solution proposed by ASVS. Although the control was
marked as an implementation issue by all but one of the participants, it is
not immediately clear why it is an implementor responsibility.
A selection of the 44 applicable controls are semi-applicable to implement-
ation. For example, control 2.10.1, on the safe storage of secrets and creden-
tials, was marked by two participants as applicable to software only. The
frontend developer, however, argued that while the “DHIS2 core team is
responsible for not putting credentials in the source code”, it is also the im-
plementor’s responsibility for storing information securely on the server.
Another example is control 2.5.4, which concerns the removal of default
accounts from production, such as "root" or "admin". The release man-
ager noted that there is a built-in admin account when the system is boot-
strapped, used to create other accounts, that has to be disabled by the im-
plementors. The implementation engineer added that the implementors
often do not disable it and leave it present.
58
Scoring
In the scoring phase, 27 controls passed, 9 failed, and 8 are unresolved.
Initially, the unresolved number was higher. The security engineer was
brought on board to resolve as many conflicts as possible. One such
issue now resolved as fail is control 2.4.4, dealing with password hashing
function bcrypt for which “the work factor SHOULD be as large as
verification server performance will also, typically at 13”. The work factor,
according to the security engineer, is currently set to 10, and it cannot be
reconfigured by the implementors. This illustrates the need for a varied
pool of opinions and expertise.
Control 2.1.1 brings up the issue of configuration. The control asks to
verify that user passwords are at least 12 characters in length. The control
was failed by the frontend developer. The backend developer, on the
other hand, passed it, arguing that passwords can be configured to be 12
characters long. A possible question that could be raised is whether or not
the implementors should be able to configure a password to be shorter than
12 characters long. It is unclear to me if any password-length restrictions
are present.
5.1.5 ASVS V3: Session Management
This ASVS chapter concerns web-based applications and stateful API’s,
and the mechanisms by which they control and maintain the state of a user
or a device. The technique used today are session tokens, unique to each
individual and ideally not guessable.
Table 5.6: Results from ASVS section V3
59
Applicability & scoring
In this chapter, 19 of 20 controls are applicable to DHIS2, 11 of which
pass and 4 fail. The single non-applicable control was 5.3.5, which states:
“Verify that stateless session tokens use digital signatures, encryption, and
other countermeasures to protect against tampering, enveloping, replay,
null cipher, and key substitution attacks”. Two participants marked is as
non-applicable, and two marked is as applicable. The frontend developer
expressed that while it is not applicable right now, stateless session cookies
are being worked on. Due to this argument, the deadlock was tipped
towards non-applicable. Interestingly, the language in this control assumes
that stateless session tokens are already in place. Based on these semantics,
the control is not applicable if stateless cookies are not used. Nonetheless,
work on stateless session cookies was already in progress with the DHIS2
development team, and for this reason, it can be argued that the control
should have been applicable.
5.1.6 ASVS V4: Access Control
“Authorization is the concept of allowing access to resources only to those
permitted to use them” [9, p. 33]. This ASVS chapter ensures that access
is granted to persons with valid credentials and that users are associated
with a defined set of roles or privileges.
Table 5.7: Results from ASVS section V4
Applicability & scoring
In this ASVS category, all 10 controls are applicable, and 2 controls fail.
Here we explore a control applicable to software and scored as fail by all
60
participants: 4.2.2. This control aims to ensure that “the application or
framework enforces a strong anti-CSRF mechanism to protect authentic-
ated functionality, and effective anti-automation or anti-CSRF protects un-
authenticated functionality”. First, some background. OWASP describes
CSRF as a “attack that forces the end-user to execute unwanted actions on
a web application in which they’re currently authenticated” [18]. When the
browser requests a resource from a website, it creates a cookie that stores
the user’s session information. When the user sends a request to the server,
the browser will automatically include the cookie for authentication. An
example attack scenario is one where the victim is logged in to a bank, and
the attacker exploits this by sending a hyperlink in an email with a request
for a transfer of money to the attacker’s bank account. Because the cookie
is included in the request, the transaction goes through.
One solution is to set the SameSite flag in the cookie. To summarize
the fix, setting this flag ensures that the cookie is ignored for POST
based CSRF attacks, meaning, the attacker’s hyperlinks will be ignored
[33]. This specific CSRF-fix is addressed in control 3.4.3, with half the
participants checking it as an implementor responsibility also. Setting the
SameSite attribute, according to the implementor, is a controversial topic
amongst the DHIS2 team. Presently, strong anti-CSRF mechanisms are not
implemented, mainly due to legacy reasons and how the API is used, and
the SameSite attribute is therefore set by the implementors (with guidance
provided by HISP).
This issue is elaborated on and its implications discussed in section 6.3.2.
5.1.7 ASVS V8: Data Protection
There are three key elements to data protection: confidentiality, integrity
and availability (CIA). This ASVS chapter addresses the CIA, seeking to
ensure that data is protected from unauthorized disclosures, that data is
protected from unauthorized altering or deletion, and that data is available
61
to authorized users.
Table 5.8: Results from ASVS section V8
Applicability & scoring
In this chapter, 13 out of 17 controls were selected as applicable, with 7 that
pass and 4 that fail. Here two prominent examples will be showcased. The
first is 8.3.4, an example of an implementation-only control. The control’s
description states: “Verify that all sensitive data created and processed by
the application has been identified, and ensure that a policy is in place on
how to deal with the sensitive data”. As the frontend developer writes,
policy is set by the district, ministry, country et cetera. In other words,
while DHIS2 can allow for the classification of data, how the data is dealt
with is entirely up to the implementors. The same is true for controls 8.1.1
and 8.2.2 also.
Control 8.3.2 is the second example. The control description states: “Verify
that users have a method to remove or export their data on demand”. To
reiterate, DHIS2 stores two types of data: aggregated and patient data.
Though the control is applicable, the frontend developer writes that there
is a difference between exporting aggregated data and patient data, though
does not elaborate further. During the scoring phase, the same participant
gave the control a fail. The backend developer, on the other hand, gave it a
pass, explaining that the user can export all their data on demand. Whether
or not the participant considered the "aggregated" angle is unclear.
5.1.8 ASVS V10: Malicious Code
“Finding malicious code is proof of the negative, which is impossible to
completely validate” [9, p. 50]. This ASVS chapter tackles many attacker-
62
centric requirements, such as handling malicious activity.
Table 5.9: Results from ASVS section V10
Applicability & scoring
As seen in table 5.9, all 10 controls are applicable, 7 of which pass and
3 fail. One control of interest here is 10.3.1, which states: “Verify that
if the application has a client or server auto-update feature, updates
should be obtained over secure channels and digitally signed”. During
the applicability phase, the implementor said that when the DHIS2 file
is downloaded, there is no hash code present to verify the validity of
the package. However, it is unclear if this is true for updates as well.
During the scoring phase - which the implementor did not participate
in, the backend developer scored the control as a pass. This raises the
issue of whether the control was properly scored. Security requirements
unaddressed can result in severe consequences if the vulnerability is left
unpatched and then exploited by an attacker.
5.1.9 ASVS V12: File and Resources
This ASVS chapter seeks to ensure that untrusted files are handled
accordingly and securely, such as stored outside the web root and with
limited permissions.
Table 5.10: Results from ASVS section V12
63
Applicability & scoring
As seen in table 5.10, all controls are applicable, with 10 that pass and 5
that fail. Control 12.3.6 is an example of conflicting point of views. The
control description states: “Verify that the application does not include and
execute functionality from untrusted sources, such as unverified content
distribution networks, JavaScript libraries, node npm libraries, or server-
side DLLs”. The frontend developer checked it as fail, though also noting
that they attempt to code review libraries they rely on. This can be a
difficult and time consuming task, and developers must consider risk
versus probability. For these reasons, both the backend developer and
security engineer on the other hand gave it a pass.
5.1.10 ASVS V14: Configuration
The aim of this chapter, per ASVS’ description, is to create “secure,
repeatable, automatable building environment” and “secure-by-default
configuration, such that administrators and users have to weaken the
default security posture” [9, p. 60].
Table 5.11: Results from ASVS section V14
Applicability
Out of 25 controls in this category, 23 are applicable. In this ASVS
chapter, only one control applies both to software and implementation.
Control 14.5.3 asks to “verify that the cross-domain resource sharing
(CORS) Access-Control-Allow-Origin header uses a strict whitelist of
trusted domains to match against and does not support the "null" origin”.
Both the frontend- and backend developer noted that the CORS whitelist
64
is controlled by the implementors or system administrator. This control is
applicable to software also because the main functionality, and the check
against the "null" origin, needs to be build by the core development team.
Scoring
In this phase, 16 controls are a pass, 4 fail, and a further 3 are unresolved.
One control of interest is applicable both to software and implementation.
This control, 14.3.2, concerns the use of a debug mode, used during devel-
opment to display relevant information during the software’s execution.
If left on during production, it can reveal sensitive information, such as
developer secrets and security disclosures, e.g. whatever the developer
puts there. While the control was evaluated to a pass, the implementor ex-
pressed concern during the applicability phase, given that the implement-
ors can turn on the debug operation in their local implementations. Though
not activated by default, the implementors still need to be given guidance
on what to do and not to do.
5.1.11 Updated scoring
In early April 2020, the security engineer asked to give a status update on
the failed controls. Since our last conversation in early December, many
vulnerabilities had been fixed or are in the process of being addressed.
This section will present these results. However, the original audit results
still stand and will be the focus of the coming discussions. The purpose of
presenting the updated results here is to show the improvement that can
be made in a relatively small amount of time. The full spreadsheet for this
result can be seen in Appendix B, section B.1.
Table 5.12 summarizes the new results. The number of controls that passed
went from 174 to 189, and the number of controls that failed went from
50 down to 35. Furthermore, an additional 8 controls are in the process of
being fixed and should be available in the next DHIS2 release. This also
65
Table 5.12: Updated results from the scoring phase
means that for level 1 of ASVS, the number of failed controls is now 14,
down from 19. For the next release, the number will be 11.
An example of a planned functionality is control 2.1.7. The control deals
with checking a user-entered password against a list of the most common
passwords. This check can be against a list of one thousand or ten thousand
of the most common passwords. This control is presently a fail, but the
functionality should be coming soon.
5.2 Part 2: Ranking results
In this phase, the severity and importance of the failed controls was ranked.
However, only a subset was ranked, 39 out of 50, due to there originally
being a greater number of controls with conflicting results. These were
later resolved by the security engineer, many as pass, most as fail, but this
occurred after this phase had been completed.
First, the results are presented statistically, giving an overall overview
of the results from each participant. Then, examples are hand-picked to
illustrate instances of agreements and disagreements, and the implications
of this.
5.2.1 Statistical results
Each ranked control was given a score from 1 to 5. Tables 5.13 and
5.14 show the security engineer and front-end developer’s distribution
of controls across these five rankings. As seen in table 5.13, the security
engineer gave the majority of controls a rank 4. The frontend developer, on
66
the other hand, ranked the majority of issues as rank 3.
Table 5.13: Phase 3 results from the security engineer
Both participants placed the majority of controls in rank 3 and above.
How each control is ranked is dependent on the participants’ view and
knowledge of the issue. As the next section illustrates, the results for
several controls varied significantly.
Table 5.14: Phase 3 results from the frontend developer
5.2.2 Critical and non-critical controls
The key takeaway from the previous section is that there were a lot of dif-
ferences in the rankings given by the participants. This section highlights
three sets of examples: critical controls in which both participants agreed,
non-critical controls in which both participants agree, and controls with
radically different rankings.
Critical controls
Two instances where both participants gave a control a rank 5 was with
controls 1.1.1 and 1.2.3, both in the Architecture chapter of ASVS. The first
example is on the use of a secure software development life cycle, such
that “security is addressed in all stages of development”. The frontend
developer looked at the entirety of the process, writing that he considers
“security a process more than an end state”. The security engineer focused
on one particular activity in software development: code commitment.
67
Like many other open-source projects, the DHIS2 codebase is located in a
(public available) Github repository. When a developer is ready to integrate
their changes with the central repository, they commit their changes and
can then choose to either push the changes directly or, create a pull
request in which their work is peer-reviewed. The concern expressed by
the engineer is an attacker gaining access to an account and committing
malicious code to the DHIS2 repo. However, this is a general concern
with all software that utilize such a service. In an email correspondence,
the security engineer provided more details. No commit is merged into
master without approval from at least two reviewers. Furthermore, many
developers sign their commits with a digital signature, thus verifying the
validity of the source. According to Github’s help page, it is possible to set
a "branch" as a protected resource and block all non-verified commits. It is
unclear to me if that is the case with DHIS2.
The other control, 1.2.3, is described in ASVS as such: “Verify that the
application uses a single vetted authentication mechanism that is known
to be secure, can be extended to include strong authentication and has
sufficient logging and monitoring to detect account abuse or breaches”.
The frontend developer stressed the severity of this vulnerability, writing
that “it is only a matter of time until the first breach happens as a result
of this [vulnerability]”. The security engineer expressed that the control is
broad in its description, and could be broken into smaller pieces. The basics
of logging and monitoring, though not perfect, are in place. For example,
the user is unable to do an unlimited number of password recoveries, thus
limiting "account abuse".
With the April 2020 update, both controls are scored as pass by the security
engineer. For 1.1.1, the security engineer expressed that for an open-
source system, the development cycle is good enough, and on 2.2.3, a lot
of improvements had been done in the last six months: DHIS2 now uses
an industry-standard authentication system, like password algorithms and
2-factor authentication, and there have been improvements in logging and
68
monitoring as well.
Non-critical
Two instances where both participants gave a control a rank 1/2 are with
controls 2.1.8 and 2.1.12. On the first, the control deals with the use of
a password strength meter when setting or updating a password. Both
participants expressed that while this feature is helpful for the user, it does
not necessarily improve security. The second control also concerns the
user experience, allowing the user to “temporarily view the entire masked
password, or temporarily view the last typed character of the password on
platforms that do not have this as native functionality”. Both again agreed
that this is a user interface concern, and not of the highest priority from a
security standpoint.
Conflicting results
Two instances where the two participants gave vastly different rankings
to controls occur with 4.3.1 and 12.4.2. The first control aims to test that
“administrative interfaces use appropriate multi-factor authentication to
prevent unauthorized use”. This control was given a rank 2 by the security
engineer, arguing that while two-factor is enabled, it is not enforced,
because 2FA is more of a UI decision, rather than a technical one. The
same control was given a rank 5 by the frontend developer, who remarked
that DHIS2 is particularly vulnerable to it if the aforementioned CSRF
vulnerability is not corrected (also ranked 5 by the participant).
The second control deals with ensuring that files obtained from untrusted
sources are scanned and blocked if malicious. DHIS2 can be extended with
additional applications developed by third-parties, and this is where the
security engineer chose to focus on. Discovering a malicious application
is difficult unless strict guidelines and measures are put in place. Apple,
for instance, reviews every application before it is allowed on the App
69
Store [38]. For DHIS2, this is significantly harder to do. The frontend
developer took a different approach, emphasizing that the implementors
are themselves in charge of ensuring that no malicious application is
uploaded onto their DHIS2 instance. The control was therefore given a
rank 1.
70
Chapter 6
Discussion and analysis
In this chapter, I will first give a summary of the results from the audit,
and then discuss their implications. This discussion is accomplished by
comparing the results against what is expected from an HMIS, presented
in section 6.2. Then I turn to the second objective of this thesis, to analyze
the auditing process and the results to answer this research question:
What are the benefits and challenges of using ASVS to assess DHIS2’s
security?
First, section 6.3 leverages the results from the audit by giving possible
suggestions for addressing the discovered shortcomings. Then, by
combining the results with the supporting literature, this thesis can broadly
explore both the relevance of an ASVS audit and standards in general. This
topic is presented in section 6.4. This is followed by a reflection on the
challenges and limitations of the project in section 6.5. Finally, section 6.6
reflects on the conducted research.
6.1 Summary of the results
Chapter 5 presented the results from the audit. 258 out of 286 ASVS
controls were applicable to DHIS2, either in part or semi-applicable to
71
implementation also. 178 out of those 258 were assessed as pass, whereas
50 controls failed (as seen in table 6.1). The main focus of this chapter
will be on the failed controls, discussing what they tell us about DHIS2’s
security and how to address these shortcomings.
Table 6.1: Failed ASVS controls
Note that while 12 of the 50 controls that failed also concern implementa-
tion, they do not necessarily fail on the implementation side – or vise-versa.
This distinction in the results is difficult to make due to insufficient data -
with the exception of a few controls that were commented on by the par-
ticipant. Nonetheless, for the purpose of the discussion, these "exception"
controls are sufficient to be able to draw examples from.
6.1.1 Factors in applicability
The non-applicability of ASVS controls was due to two reasons. The
first are requirements that target services and components DHIS2 does
not have. And the second leading factor was requirements applicable
to implementation, either in part or wholly. Within the implementation
category, four unique factors were identified.
• Implementation due to local laws. DHIS2 is used in many countries
and contexts. Therefore, controls that deal with configuring DHIS2
to suit local laws and regulations to satisfy the different requirements
on different districts are implementor responsibility.
• Implementation due to configuration. Several security features have
to be configured and activated by the implementors.
• Implementation due to sensitive data classification. The developers
do not know what is sensitive in each context DHIS2 is used in.
72
The core team can provide the functionality to classify data, but
the ultimate responsibility to classify data correctly falls on the
implementors.
• Implementation due to web-server setup. Several controls concern
the web-server and the application of firewalls, proxies and the like
to secure the hosted platform and the data server. This also includes
logging and analyzing the data.
The coming sections will discuss how to address some of these categories.
6.2 DHIS2 and the expectations of security in an
HMIS
High-tier security for an HMIS is critical, as established in section 3.3.1:
Security in an HMIS. The results established a baseline, which we can
utilize to evaluate the strength of DHIS2’s security as compared against
what is expected of general data security and the health sector. This section
examines this, first by looking at the results compared to what ASVS says
and then seeing what inspiration can be taken from the GDPR in building
secure applications.
6.2.1 Auditing results compared to ASVS levels
OWASP describes a level 1 coverage as “bare minimum that all applications
should strive for” [9, p. 10]. For software that handles health information
and personal data, a level 2 coverage is recommended, where “failure
could significantly impact the organization’s operations, and even its
survivability” [9, p. 11]. A level 3 is recommended for applications whose
failure could jeopardize operations or even human life. DHIS2 falls into
the level 2/3 category. As seen in table 6.1, DHIS2 falls short of a level 1
coverage with 19 failed controls, and 27 and 4 failed controls on levels 2
and 3 respectively.
73
However, not all security controls are equally important, and it can be
argued that organizations are unlikely to view the results in such black
and white colors. The purpose of adding a third phase to the assessment
process: Ranking, was to register a risk assessment process of a sort, meant
to give insight to how the participants ranked the importance and severity
of each control. As seen in section 5.2, the ranking given to each control
varied. For instance, a small subset of the controls from level 1 concern
the frontend interface, as in the case of two controls: 2.1.8, on the use of
password strength meters, ranked as a level 1 issue by both participants;
and 2.2.3 on allowing the user to temporarily view the masked password
(ranked as a level 2 issue). In a few instances, one participant gave a control
a rank 5, another a rank 1.
With that said, each failed control is an opportunity for the attacker
to penetrate the system and steal or corrupt the data. The majority
of the issues in the ASVS failed list were ranked as level 3 or above.
Vulnerabilities such as the CSRF attack were given a level 5 ranking,
issues the development team have been aware of and are highly vulnerable
against, but have yet to fix.
6.2.2 GDPR as a reference point for DHIS2
At the time when this audit was conducted, DHIS2 had not been used
in Norway before. This changed with the outbreak of COVID-19. As of
May 2020, DHIS2 now is being implemented by municipalities in Norway
to track contact tracing between individuals, and DHIS2 is therefore now
directly subject to GDPR. How HISP and the DHIS2 development team
indents to handle this is immediately unknown to me.
A single control in ASVS makes a direct reference to GDPR: “Verify
that regulated private data is stored encrypted while at rest, such as
personally identifiable information (PII), sensitive personal information,
or data assessed likely to be subject to EU’s GDPR” (6.1.1). Outside the
74
EU, DHIS2 is not subject to GDPR. Even before the recent development
in Norway, the control was still selected as applicable, likely due to the
GDPR’s principles and guidelines on handling private data securely. In the
international context, we do not need to be GDPR compliant, and specific
articles of GDPR can only be accomplished at the implementation level, but
developers can still take inspiration from its contents, specifically Article 25
on data privacy by design and data privacy by default (outlined in section 3.5.2)
[10], the purpose of which is to protect the personal data of its citizens. As
outlined in section 3.3.2, several African countries are taking inspiration
from and implementing a similar set of laws as those found in GDPR. By
using the GDPR as a point of reference, the DHIS2 development team can
help ensure that the core software not only takes personal data protection
to heart but is configurable enough to meet the different contexts it is used
in.
6.3 Possible solutions to software and implementa-
tion
The separation between software and implementation is an important
distinction to consider with DHIS2. Due to this, software security must
be approached from two different angles. This section seeks to leverage the
benefits of an ASVS audit and give context to the results, exploring possible
solutions to addressing the discovered vulnerabilities, both from a software
angle and an implementation angle. To this end, this discussion will take
a broad approach, with solutions that address the issues at the root, rather
than for each control.
6.3.1 Solving software related controls
Failed controls that are applicable to software are the responsibility of
the DHIS2 development team. There are multiple, varied approaches to
75
addressing them, and the selection(s) depends on the available manpower
and the team’s willingness to invest in sophisticated processes. A relatively
simple, straightforward approach is to raise the security requirements as
tasks and fix the vulnerabilities. However, this is still reactive, rather
than proactive. In the past, “it was common practice to perform security-
related activities only as part of testing” [43]. This meant that security
vulnerabilities were discovered either too late or not at all. The first control
of ASVS recommends the use of a “secure software development lifecycle
that addresses security in all stages of development”. The idea is that by
making security a continuous activity, you make security proactive, rather
than reactive.
This topic brings up the Secure Software Development Lifecycle approach
presented in section 3.1.1. Here the discussion turns to embedding security
into the Agile development method (currently followed by the DHIS2
team), but other development models, such as DevOps [21], are also viable.
Implementing security activities into the SDLC can be categorized into
these three levels [42].
• Every Sprint (Most critical): These are the security activities that
should be repeated in every sprint, such as code analysis, following
secure coding checklists (relevant to control 1.1.7), and threat model-
ing (relevant to control 1.1.2).
• One-time (non-repeating): These activities are performed at the start
of a new project, like risk assessment and analyzing attack surfaces.
• Bucket (all other): These activities are performed regularly, spread
across multiple Sprints, such as random testing, attack surface review,
and dynamic analysis.
A benefit of ASVS is that the requirements are highly testable, and the
controls from the list can be incorporated into several of theses phases,
either during every sprint, every couple of months, or once a year. This
task of embedding security into the SDLC and approaching security with
76
a Security by Design mindset might be challenging. In fact, "security" and
"agile-development" have often been referred to as incompatible, due to
the short sprints and iterative deliveries [11]. However, the Agile method
is known to be highly flexible and adaptable [42]. A proposed solution
is to raise issues discovered in the audit as tasks in the product backlog.
This, the OWASP team notes, “helps with prioritization of specific tasks (or
grooming), and makes security visible in the agile process” [9, p. 13].
Security by Design and Default, Data Protection by Design and Default,
all share similarities. All four need not be followed, and the latter two
are only applicable to GDPR-compliant countries. Nonetheless, their core
principles, which stress the importance of having security be a founding
and continuous activity in a software’s life cycle, can be useful to any
organization seeking to become better at security.
6.3.2 Solving implementation related controls
Addressing software on the implementation side comes with a different
set of challenges. First, there is the initial security configuration of a
local DHIS2 instance, which if improperly set up will leave the platform
vulnerable. Secondly, security-related activities must continue throughout
the platform’s lifecycle, in activities such as monitoring and updating to
newer versions of DHIS2. Security at the implementation level is an
ongoing issue, as laid out in section 2.2.6, with poor proxy setup, no
firewalls, and often no monitoring, to name a few. Presently, local HISP
groups provide guidance to address these shortcomings. This section will
reaffirm the importance of the guidance and training that HISP provides.
Also, it will propose security by default - addressing implementation
through software - as a development strategy to ensure that DHIS2 is as
secure as possible by default.
Note that during the scoring phase, only controls applicable to software
and semi-applicable to implementation were scored. Non-applicable
77
controls that concerned implementation-only were not scored. The
majority of participants were from the development team, and the intention
was to keep the focus on controls that concerned them the most. The
solutions proposed in this section, however, could, in theory, be applied
to the implementation-only controls also.
Addressing implementation through guidance
According to Sæbø, Adu-Gyamfi and Nielsen, the extent of the expertise
that HISP provides with supporting implementation includes the “training
of users at different levels, system implementation, maintenance, integra-
tion with other systems and software development of extensions and apps”
[6, p. 75]. This section will attempt to give context to this in light of the res-
ults, by selecting examples that could be addressed through guidance.
The first example is control 1.1.5, which asks to “verify definition and se-
curity analysis of the application’s high-level architecture and all connected
remote services”. According to the frontend developer, this is an imple-
mentation issue, but that HISP should “provide clear guidance on what
the sysadmins MUST and MUST NOT do in terms of maintaining a se-
cure system”. A similar sentiment is true with 8.1.4: “Verify the application
can detect and alert on abnormal numbers of requests, such as by IP, user,
total per hour or day, or whatever makes sense application”. This control
is handled at the server level, and it is the responsibility of the system ad-
ministrators to monitor the API traffic, not DHIS2 itself.
During the audit, the participants noted several examples where a bad
configuration could leave DHIS2 vulnerable. For instance, one control
1.12.1, which asks to verify that “user-uploaded files are stored outside of
the web root”, the release manager explained that this feature is configured
by the implementors. The consequence of this is a system administrator
that - unaware of the repercussions - alters the configuration to store files
inside the webroot itself. So, for example, if a user or the attacker then
78
uploads a malicious file and that file is stored inside the webroot, the
system could be compromised.
The danger is arguably higher with the next example: control 2.5.4, a
requirement the implementor considers to be an ongoing issue. When an
instance of the DHIS2 platform is initialized, there is a default "admin"
account present. Alternatively, this can be referred as the "root". This
account has higher privileges and is used to create other accounts. After
the bootstrap is completed, the admin should be deleted, but often is not.
It is unclear to me the full scope of what the DHIS2 admin accounts have
access to, in terms of both read and write. In general, the presence of an
admin account is dangerous. OWASP writes that, for a threat agent to
accomplish their goal, they “have to gain access to only a few accounts,
or just one admin account to compromise the system” [2]. Further, it is
essential that software is not shipped or deployed with default credentials,
such as admin/admin for username and password. It is unknown to me
if that is the case with DHIS2. If it is, then the admin user must either be
disabled, or the password has to be changed after the bootstrap and kept
confidential.
DHIS2 supports multi-factor authentication to prevent unauthorized use,
the topic of control 4.3.1, but, according to the release manager, it is
configurable and is not enforced. There are multiple cases like these to
find in ASVS with DHIS2. In these instances, the users and administrators
themselves have to consider usability versus security and decide if it is
worth implementing. These examples underline the importance of good
on-site training and guidance. In a paper on digital health intelligence and
security in HMIS’s, the writers state that “there is an increasing concern that
cloud server in general, and Amazon’s in particular, have vulnerabilities
poorly understood by regulators and users who rely on their security” [12,
p. 16]. As the reach of the internet and DHIS2 expands, particularly in
Africa, these vulnerabilities and many more discovered in the ASVS audit
could be prime targets for an exploitation.
79
Addressing implementation through software
The concept of Secure by Default is important to this discussion, and
was originally brought to my attention as a potential remedy by the
implementor during a presentation of DHIS2’s security landscape. As
outlined in section 3.1.2, the philosophy of this approach is to build
software that is secure by default. Of particular interest to DHIS2,
in the context of implementation, is the following principle: “security
should not require extensive configuration to work, and should just
work reliably where implemented” [56]. A few ’by default’ examples
is setting the firewall by default, requiring authentication by default,
enabling encryption by default and setting password complexity by
default. By configuring the software to be secure out-of-the-box, we
lessen the burden on the implementors. Security configuration is the
sixth entry in OWASP’s Top 10 list, addressing issues like “insecure
default configurations, incomplete or ad hoc configurations, open cloud
storage, misconfigured HTTP headers, or verbose error message containing
sensitive information” [48]. Chapter 14 of ASVS is also dedicated to
configuration.
An example of this configuration concern is the failed control 4.2.2 on
Cross-Site Request Forgery, as explained at length in section 5.1.6, an
issue that has been previously raised by external security groups. In short,
the issue arises when an attacker uses the authenticated state of a user to
commit fraudulent transactions. The solution is also addressed in control
3.4.3, whereby setting a SameSite attribute in the cookie prevents this form
of attack [33]. As discussed previously, this control is a point of argument
issue among the HISP developers and implementors. Setting in on by
default would ensure that the instance of DHIS2 given to implementors is
as secure as possible without needing to configure it. Presently, it is not set,
the reason being that developers make apps which they test against online
test/demo servers, and if the sameSite attribute was enabled, testing would
be difficult. In an email exchange sometime after the assessment had been
80
completed, the implementor reaffirmed his stance on the issue, arguing that
“better that devs have to do a bit of work to workaround its inclusion, than
implementers have to do workaround its exclusion”.
There is possibly a balance to find here, between what is best for the
implementors and what is best for the developers. And if that balance is
struck - even if all the details of the control are not accomplished, given the
intricacies of addressing it, it could be safe to check the control as passed.
6.4 Relevance of an ASVS assessment
The audit needs to provide benefit to the organization. This section argues
for those benefits and discusses ASVS’ relevance, comparing it towards
other methods of establishing security and looks at how developers can
best utilize the standard.
6.4.1 OWASP’s Top 10 as security standard
The ASVS is first and foremost not an awareness project. Its purpose
is to provide a more proactive approach to application security, offering
detailed requirements suited to organizations of different sizes. This is
in stark contrast to OWASP’s Top 10, which was specifically designed to
be an awareness document, representing a “broad consensus about the
most critical security risks to web applications” [48]. The authors of ASVS
tailored the level 1 requirements of ASVS to reflect the Top 10 list, thus
“making it easier for OWASP Top 10 adopters to step up to an actual
security standard” [9, p. 10]. The question this section wants to answer
is whether adapting the ASVS is worth the time and effort.
One important factor to answering this question is raised by OWASP
themselves. The first is that the Top 10 is only reflected in the first level
of ASVS, the bare minimum for entry-level awareness. For a smaller team
new to security, the Top 10 or level 1 of ASVS is a good starting point.
81
DHIS2, on the other hand, needs to look beyond the simplicity of the
Top 10. The Top 10 provides sufficient background on a particular issue,
including possible mitigations and example attack scenarios. Leveraging
and adopting the Top 10 remains good practice, but it does not help
developers create a secure application, nor is addressing the current Top
10 vulnerabilities enough to cover all of the todays biggest vulnerabilities.
The current version of the Top 10, updated last in 2017, saw the removal
of Cross-Site Request Forgery from the list, due to more applications
and frameworks having anti-CSRF protection than when the entry was
originally introduced [49]. As been previously discussed, CSRF is an
ongoing issue with DHIS2. The same is true for other issues uncovered
in the audit, some previously known to the DHIS2 developers, others not.
Looking to the Top 10 is a good strategy, but arguably insufficient for
DHIS2.
6.4.2 Relevance of ASVS in a mature organization
When no dedicated security team or role is present within the organization
or team, the responsibility for driving or enforcing security related features
and activities falls on the developers or team lead. In this case, these
people must have or must acquire the necessary expertise to make the
correct security decisions for their software. ASVS can be the guiding
star that educates developers on the industry’s best practices. However,
the question this section wants to address is whether an ASVS audit is of
worth to an arguably mature organization such as DHIS2, with a multitude
of security features already in place, and whether it can provide value to
developers who are already decently knowledgable in security.
Until the recent hiring of a security engineer, the DHIS2 team had no
dedicated individual driving security within the organization. Therefore,
security-related features received lower prioritization. Only in the closing
months of 2019 had security become a focus. The auditing process
82
established that a significant number of controls fail. However, the
qualitative data also showed that the participants collectively had a good
overview of the many security vulnerabilities that are present in DHIS2,
particularly within their areas of expertise, be it backend, frontend or
implementation-related vulnerabilities.
It is difficult to say if the audit provided any benefit to the participants, and
if it drew their attention to any particular vulnerability they were either
not aware of or had dismissed as less-than critical. This is particularly
difficult to evaluate from the author’s perspective, as this form of data
was not part of the official data gathering, and would require additional
interviews. In an email correspondence on March 2020, however, the
security engineer re-scored the previously failed controls, and exclaimed
the learning experience – having recently been hired – of seeing how
DHIS2 compares against ASVS. Since our first chat in early December
2019, the number of failed controls had been reduced significantly. While
I am unable to draw a direct causality between my project and the
improvements, I would argue that the new results highlight the relevance
of ASVS’s controls to DHIS2.
In general to all software teams, ASVS’s relevance is dependent on the
team’s or individual’s maturity level on the subject of security. Rather
than do a systematic audit using ASVS, a developer is perhaps more likely
to seek out individual solutions to the problems they are facing or have
been reported in the field, or implement a security feature in response to
a vulnerability they read in an article or paper. During a DHIS2 security
seminar in April 2019, the implementor expressed that vulnerability
management was done on an ad hoc (less than ideal) basis, and to address
DHIS2’s security vulnerabilities, there must be more "external" pressure
from management and users. Using ASVS to inform the organization of its
vulnerabilities as deemed important by the many experts involved in the
making of ASVS is one approach to making the vulnerabilities more visible.
83
6.4.3 Time estimates for the audit
The previous section reflected on the need for ASVS in an organization
with a mature security infrastructure already in place. This section builds
on this by giving time estimates for the audit as conducted in this project.
A significant factor in the willingness to invest in a standard is the time
it takes to complete the exercise and is therefore important to explore. In
general, there are three main time factors to consider:
• ASVS level. Doing an audit against level 1 takes significantly less
time than doing all three, as the control complexity increases with
each level, thus adding to the time it takes to possibly research and
confirm a control’s status.
• Method of assessment. The approach to the data gathering was split
into two phases. This was done out of necessity, due to the challenges
of finding participants. Potentially, these two phases would occur
concurrently, which could drive down the time significantly.
• Thoroughness of the assessment. The participants scored each
control on a best-guess basis. This is not necessarily ideal, depending
on the risk level, as controls can be scored incorrectly if not properly
researched and/or tested and verified.
These three factors impact the potential time estimates for the audit. This is
a student project and is therefore not necessarily a reflection of an audit
as it would have occurred had this been done by a member of HISP.
Nonetheless, the following is a time estimate for the entire project.
• Applicability phase: Four participants were interviewed, each
session taking approximately two hours each, for a total of eight
hours.
• Scoring phase: Two participants were initially interviewed, for
approximately two hours each. Adding up the contribution by the
security engineer, this brings up the tally to four and a half hours.
84
To summarize, the auditing process (excluding the ranking phase) took 12,5
hours. This is excluding the organization of responses and analysis that
occurred thereafter.
6.5 Challenges and limitations to the audit
Among the other issues listed throughout this thesis, the main challenges
and limitations of the auditing process are examined below.
6.5.1 Developer participation and consulting with multiple
people
The leading issue throughout the process was finding and engaging with
the participants. The process could not be realized without the contribution
of HISP employees and especially the DHIS2 development team, who have
intimate, technical knowledge of the platform. There was an expectation
on the author’s part that there would be a larger engagement from the
group. Several leading members of the DHIS2 team were contacted
by email but never responded. The number of participants for each
phase also dwindled, who where either too preoccupied or unresponsive
when contacted by email. The consequence of this is that the results
are inconclusive. 29 controls remain unresolved, and 5 have conflicting
opinions. It is also entirely possible that some controls were scored
incorrectly. Instances where one participant skipped on a control, and
another gave it a pass or fail, received the latter’s score, meaning their
evaluation of said control is unchallenged and is possibly incorrect.
Luckily, the group that participated in this exercise all had vastly different
jobs within HISP. This is important because a developer might have one
perspective on an issue, a release manager, or implementor another. Had
all participated in all phases - in the first two phases in particular - the final
set of data would in all likelihood be different. The key takeaway from
85
this experience is that when doing an audit it is important to get people
with different areas of expertise. DHIS2 consists of a lot of moving pieces:
multiple modules, apps, API, and a frontend and a backend, and a single
individual is unlikely to have a comprehensive overview over it all. An
example: during the scoring phase, the frontend- and backend developer
scored 122 and 146 controls as pass respectively. However, this left 104 and
69 controls unresolved for each. By combining their results, the number
was brought down to 29, thus filling in the areas left blank by the other.
Finding and engaging with the relevant people is likely to be easier if the
project is instigated by people within the company, be it an internal or
external audit. In both cases, the lead in this endeavor is likely to have
access to all documentation and better access to the developers (if needed).
6.5.2 Outdated data
The security engineer re-scored the previously failed controls, and the
number of failed controls went from 50 to 34, with several more fixes
planned for future releases. This new data shows that the results of this
thesis were built on is now outdated. And this was to be expected. The
last scoring sessions occurred approximately half a year before the planned
publication of this paper. These new results reflect HISP’s increased focus
on DHIS2’s security, which had never been of particular focus within the
organization until now. This thesis is then an interesting time capsule that
lets the reader see how DHIS2 was half a year ago, and the improvements
that can be made within a relatively short amount of time.
6.6 Reflections upon the research conducted
6.6.1 Errors in the applicability spreadsheets
The initial spreadsheet downloaded from OWASP’s ASVS site contained no
checkboxes. These were added to register the applicability of a control to
86
software and to implementation. However, the single Applicable checkbox
could only register if a control was applicable or not applicable to software;
it could not register if the participant was unsure and skipped the control.
This error was not discovered until late in the process. Where possible,
the participants or the interviewer would note this in the comments field,
but this was not always done due to negligence. The implication of
this is that the applicability of some control might have been judged
erroneously. However, if this happened, the errors would be far in between.
The majority of controls are applicable, and for the most part, the non-
applicable controls all have comments. The same mistake occurred in the
second phase, but was discovered immediately during the first session and
corrected by adding an Uknown column of checkboxes.
6.6.2 The author’s involvement in selecting applicability
Chapter 4 presented a list of criteria for how the results from the
participants would be merged. For example, during the applicability
phase, a control is checked in the final list if a majority of the participants
have checked it. If, however, an argument is provided arguing for the
inclusion or exclusion of a control, that argument is evaluated and taken
into consideration. This can call into question the validity of the audit
results and the influence the author had over them. I will present two
counter-arguments against this.
The first is that the author’s influence over the results was inevitable. The
data had to be combined for the next phase, and lest a member of HISP
aided in this task, someone had to make these decisions. It is possible
that controls were erroneously selected as applicable, and vise-versa. But
this leads us to my next point. On the majority of the controls, in the
case of uncertainty, a control was checked as applicable. Better a control
was wrongly included, rather than excluded. The consequence of possibly
including irrelevant controls is that it adds to the total number of applicable
controls, which in turn lowers the percentage of passed controls given that
87
it is calculated from the total.
88
Chapter 7
Conclusion
By conducting an audit of DHIS2 using the Application Security Verific-
ation Standard, this thesis has explored the process, the results, and the
merits of this exercise. The importance of a security standard has been
much written about by security experts. Yet, to my knowledge, there has
not been a study done that has explored the benefits and challenges to an
ASVS assessment through first-hand experience.
The research project was based on an interview method as a tool for
data collection. Three phases of data collection were utilized in this
thesis, wherein members of HISP and the DHIS2 development team were
interviewed. The first two phases concerned the audit, in which the
participants would select security controls applicable to DHIS2 in the first
phase and then score them in the second. The third phase was created to
evaluate the relevance of ASVS’s controls to DHIS2. For each phase, the
data was collected in Excel spreadsheets and then analyzed for patterns
and themes.
7.1 Research summary
This thesis aimed to answer the following research questions:
89
How does DHIS2’s security compare against ASVS?
What are the benefits and challenges of using ASVS to assess DHIS2’s
security?
Both of these questions were answered by conducting a security audit of
DHIS2. The first of these were answered by the quantitative data that was
gathered by scoring the ASVS controls. The data revealed that DHIS2 fell
short of what ASVS and the general literature recommends for security in
a health information system. In the third phase, it was discovered that
several of the controls that failed were critical. The second question was
answered by analyzing all three sets of data and reflecting on the process
of doing this exercize and the relevance of the ASVS standard to DHIS2.
The results are key challenges and benefits which are as follows:
• Relevance of ASVS controls
• Leveraging the results to strengthen security
• The benefit of ASVS over OWASP’s Top 10
• Relevance of ASVS in a mature organization
• Challenges to the ASVS assessment
The relevance of ASVS controls to DHIS2 is clear. The majority of controls
applied to the platform. Many controls concern issues that the team is
currently dealing with, and many have subsequently been fixed. In the
context of DHIS2, implementation was the biggest decider of applicability.
Even then, the relevance of these controls is not diminished, as HISP and
other organizations strive to guide local governments and health facilities
in the secure implementation of the DHIS2 platform.
An ASVS audit can be best utilized to align your security solutions with
an internationally-recognized standard and strengthen security. The audit
revealed vulnerabilities. In DHIS2, these vulnerabilities can be addressed
from two different angles. For controls applicable to software, this thesis
proposed the adoption of a Secure Software Development Life Cycle
90
(SDLC) approach, such that security activities are made proactive, rather
than reactive. For controls applicable to implementation, there are two
approaches: (1) the continuing of the training and guidance provided by
HISP, such that the local instances of DHIS2 set up by the implementors
are secure; (2) and address implementation at the software level, embracing
the concept of Secure by Default to build software that is inherently secure
and that does not require extensive configuration to work reliably.
The benefit of ASVS over security awareness documents like OWASP’s
Top 10 and other similar publications is that it provides a more proactive
approach to application security, offering clear, detailed guidelines on how
to best create a secure web application. For a smaller team and software
of lesser significance, the Top 10 is a good starting point, but for DHIS2 a
more complex set of guidelines is required.
The relevance of ASVS in a mature organization with a comprehensive
security infrastructure was discussed. Collectively the participants were
very knowledgable about the strengths and weaknesses present in DHIS2.
If the exercise had any impact on the participants, and if it revealed
anything new and of worth to them, is difficult to determine – with one
exception. The exercise allowed the security engineer to see how DHIS2
compares against ASVS, and to get a birds-eye view of the platform’s
current security solutions. The relevance of ASVS is ultimately dependent
on the individual’s existing knowledge on the issues or the organization’s
willingness to embrace and invest in this process.
The assessment of DHIS2 came with a set of challenges. An audit can be
done in many ways. Ideally, if one person does not have an overview of
the entire system, multiple people with different areas of expertise should
be consulted. Finding relevant participants proved to be a major challenge
throughout the entire process and contributed to the inconclusiveness of
the final results. Time is also a major factor to consider when investing in
this process. The audit takes time. The time needed is dependent on the
selected ASVS level, method of assessment, and the thoroughness of the
91
audit.
92
Bibliography
[1] 21.3. Exporting data and meta-data. DHIS2. URL: https://docs.dhis2.org/
2.22/en/user/html/ch21s03.html. [Accessed 15-April-2020].
[2] A2-Broken Authentication. OWASP. URL: https : / / owasp . org / www -
project - top - ten / OWASP_Top_Ten_ 2017 / Top_ 10 - 2017 _ A2 -
Broken_Authentication. [Accessed 15-April-2020].
[3] Ahmed Abdel-Aziz. Scoping Security Assessments - A Project Man-
agement Approach. May 2011. URL: https : / /www . sans . org / reading -
room/whitepapers / leadership / scoping - security - assessments - project -
management-approach-33673. SANS Institute.
[4] About DHIS2. DHIS2. URL: https://www.dhis2.org/about. [Accessed
15-April-2020].
[5] About Microsoft SDLC. Microsoft. URL: https://www.microsoft.com/en-
us/securityengineering/sdl/about. [Accessed 15-April-2020].
[6] Eric Adu-Gyamfi, Petter Nielsen and Johan Ivar Sæbø. ‘The Dy-
namics of a Global Health Information Systems Research and Im-
plementation Project’. In: Proceedings of the 17th Scandinavian Con-
ference on Health Informatics. Linköping Electronic Conference Pro-
ceedings 161. Linköping University Electronic Press, 2019, pp. 73–
77. URL: https://www.researchgate.net/publication/337276393_The_
Dynamics_of_a_Global_Health_Information_Systems_Research_
and_Implementation_Project.
93
[7] Ali Alsaawi. ‘A Critical Review of Qualitative Interviews’. In: SSRN
Electronic Journal 3.4 (Jan. 2014), pp. 149–156. DOI: 10 . 2139 / ssrn .
2819536. URL: https://www.researchgate.net/publication/280155117_
A_Critical_Review_of_Qualitative_Interviews.
[8] Adel Alshamrani1 and Abdullah Bahattab2. ‘A Comparison Between
Three SDLC Models Waterfall Model, Spiral Model, and Incre-
mental/Iterative Model’. In: IJCSI International Journal of Computer
Science Issues 12.1 (Jan. 2015), pp. 106–111. URL: https ://www. ijcsi .
org/papers/IJCSI-12-1-1-106-111.pdf.
[9] Application Security Verification Standard 4.0. OWASP. URL: https ://
github.com/OWASP/ASVS/blob/master/4.0/OWASP%20Application%
20Security%20Verification%20Standard%204.0- en.pdf. [Accessed 15-
April-2020].
[10] Art. 25 GDPR Data protection by design and by default. European Union.
URL: https://gdpr-info.eu/art-25-gdpr/. [Accessed 15-April-2020].
[11] Charlie Belmer. Integrating Security With Agile Development. Apr.
2019. URL: https : / / nullsweep . com / integrating - security - with - agile -
development. [Accessed 15-April-2020].
[12] Margaret Bourdeaux et al. Weaponizing Digital Health Intelligence. Jan.
2020. URL: https : / /www . belfercenter . org / publication /weaponizing -
digital-health-intelligence#toc-9-0-0. [Accessed 15-April-2020].
[13] Jørn Braa and Sundeep Sahay. ‘The DHIS2 open source software
platform: evolution over time and space’. In: Global Health Informatics.
Principles of eHealth and mHealth to Improve Quality of Care. The MIT
Press, Apr. 2017. ISBN: 9780262338127. URL: https://www.researchgate.
net/publication/316619278_The_DHIS2_Open_Source_Software_
Platform_Evolution_Over_Time_and_Space.
[14] CIS Controls. Center for Internet Security (CIS). URL: https ://www.
cisecurity. org / blog / cis - controls - version - 7 - whats - old - whats - new/.
[Accessed 15-April-2020].
94
[15] Complete guide to GDPR compliance. Gdpr.eu. URL: https : //gdpr . eu.
[Accessed 15-April-2020].
[16] Coronavirus disease 2019. Wikipedia. URL: https ://en.wikipedia .org/
wiki/Coronavirus_disease_2019. [Accessed 15-April-2020].
[17] Michael Coughlan. ‘Interviewing in qualitative research’. In: Interna-
tional Journal of Therapy and Rehabilitation 16.6 (June 2009), pp. 309–
314. DOI: 10 . 12968 / ijtr . 2009 . 16 . 6 . 42433. URL: https : / / www .
researchgate.net/publication/261471599_Interviewing_in_qualitative_
research.
[18] Cross Site Request Forgery (CSRF). OWASP. URL: https://owasp.org/
www-community/attacks/csrf. [Accessed 15-April-2020].
[19] Cyber-security regulation. Wikipedia. URL: https ://en .wikipedia .org/
wiki/Cyber-security_regulation. [Accessed 15-April-2020].
[20] Definition of standard. Webster. URL: https ://www.merriam-webster .
com/dictionary/standard. [Accessed 15-April-2020].
[21] DevOps. Wikipedia. URL: https : / / en . wikipedia . org / wiki / DevOps.
[Accessed 15-April-2020].
[22] DHIS2 Cloud hosting. DHIS2. URL: https : //www.dhis2 . org/hosting.
[Accessed 15-April-2020].
[23] DHIS2 Jira. DHIS2. URL: https://jira.dhis2.org/secure/Dashboard.jspa.
[Accessed 27-April-2020].
[24] Eric Dosal. 4 Reasons to Run a Security Assessment. June 2018. URL:
https : / /www . compuquip . com/blog / 4 - reasons - to - run - a - security -
assessment. [Accessed 15-April-2020].
[25] Jim Finkle and Jonathan Stempel. Yahoo says all three billion accounts
hacked in 2013 data theft. Reuters. Oct. 2017. URL: https://www.reuters.
com/article/us - yahoo - cyber/yahoo - says - all - three - billion - accounts -
hacked - in - 2013 - data - theft - idUSKCN1C82O1. [Accessed 15-April-
2020].
95
[26] Framework and Standards for Country Health Information Systems Second
Edition. World Health Organization (WHO). 2012. URL: https : / /
www.who. int/healthinfo/country_monitoring_evaluation/who- hmn-
framework-standards-chi.pdf. [Accessed 15-April-2020].
[27] Piccoli Gabriele and Pigni Federico. ‘Information systems for man-
agers: with cases’. In: 4.0. Prospect Press, 2018, p. 28.
[28] GDPR official page. URL: https://eur-lex.europa.eu/eli/reg/2016/679/oj.
[Accessed 7-Mail-2020].
[29] General Data Protection Regulation (GDPR). European Union. URL:
https://gdpr-info.eu. [Accessed 15-April-2020].
[30] Dieter Gollmann. ‘Computer Security’. In: 3rd edition. John Wiley &
Sons, Ltd, 2011.
[31] Peter Leo Gorski et al. ‘Warn if Secure or How to Deal with Security
by Default in Software Development?’ In: The Twelfth International
Symposium on Human Aspects of Information Security & Assurance.
2018. URL: https : / /www . researchgate . net / publication / 327797790_
Warn_if_Secure_or_How_to_Deal_with_Security_by_Default_in_
Software_Development.
[32] Daniel H Grossoehme. ‘Overview of Qualitative Research’. In: Journal
of Health Care Chaplaincy 20.3 (July 2014), pp. 109–122. DOI: 10.1080/
08854726.2014.925660. URL: https://www.researchgate.net/publication/
263097154_Overview_of_Qualitative_Research.
[33] Scott Helme. Cross-Site Request Forgery is dead! Feb. 2017. URL: https:
//scotthelme.co.uk/csrf-is-dead/. [Accessed 15-April-2020].
[34] Information Security Management. Iso.org. URL: https://www.iso.org/
isoiec-27001-information-security.html. [Accessed 15-April-2020].
[35] Trisha Jalan. MEITY to brief Joint Committee on Personal Data Protection
Bill on January 14. URL: https://www.medianama.com/2020/01/223-
personal-data-protection-bill-2019/. [Accessed 15-April-2020].
96
[36] Yomi Kazeem. Kenya is stepping up its citizens’ digital security with a
new EU-inspired data protection law. Nov. 2019. URL: https://qz.com/
africa / 1746202 / kenya - has - passed - new - data - protection - laws - in -
compliance-with-gdpr/. [Accessed 15-April-2020].
[37] Nir Kshetri. ‘Cybercrime and Cybersecurity in Africa’. In: Journal of
Global Information Technology Management 22.2 (2019), pp. 77–81.
[38] Kif Lesling. Inside Apple’s team that greenlights iPhone apps for the App
Store. CNBC. June 2019. URL: https://www.cnbc.com/2019/06/21/
how-apples-app-review-process-for-the-app-store-works.html. [Accessed
15-April-2020].
[39] Magnus Li. Development in Platform Ecosystems. Lecture slides from
course in platforms and DHIS2. 2019. URL: https : / /www . uio . no /
studier / emner / matnat / ifi / IN5320 / h19 / timeplan / in5320 - 19 - 8 -
isintroduction.pdf. [Accessed 15-April-2020].
[40] Hogan Lovells. Overview of data protection laws in Africa. Oct. 2019.
URL: https://www.lexology.com/library/detail.aspx?g=82196d1c-2faa-
43c2-983b-be3b0f1747f2. [Accessed 15-April-2020].
[41] Jim Manico. Secure Development Lifecycle. Powerpoint by OWASP
volunteer. URL: https://owasp.org/www-pdf- archive/Jim_Manico_
(Hamburg)_-_Securiing_the_SDLC.pdf. [Accessed 15-April-2020].
[42] Somesh Mohanty. Adopting Secure SDLC Practice for Agile. DZONE.
Apr. 2018. URL: https : / / dzone . com/articles / adopting - secure - sdlc -
practice-for-agile. [Accessed 15-April-2020].
[43] Ernest Mougoue. SSDLC 101: What Is the Secure Software Development
Life Cycle? July 2017. URL: https://dzone.com/articles/ssdlc-101-what-
is-the-secure-software-development. [Accessed 15-April-2020].
[44] NIST Special Publication 800-53 Revision 4. NIST. Jan. 2015. URL: https:
//nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
[Accessed 15-April-2020].
97
[45] Ny sikkerhetslov stiller strengere krav til IT-systemer [New security law
places stricter requirements on IT systems ]. Standard Norge. 2020. URL:
https://www.standard.no/nyheter/nyhetsarkiv/ikt/nyheter-2019/ny-
sikkerhetslov-stiller-strengere-krav-til-it-systemer-/. [Accessed 15-April-
2020].
[46] Shannon M Oltmann. ‘Qualitative Interviews: A Methodological
Discussion of the Interviewer and Respondent Contexts’. In: Forum
Qualitative Sozialforschung 17.2 (May 2016). URL: https : / / www .
researchgate.net/publication/304876962_Qualitative_Interviews_A_
Methodological_Discussion_of_the_Interviewer_and_Respondent_
Contexts.
[47] OWASP Application Security Verification Standard. OWASP. URL: https:
//owasp.org/www-project- application- security- verification- standard/.
[Accessed 15-April-2020].
[48] OWASP Top 10. OWASP. URL: https://owasp.org/www-project- top-
ten/. [Accessed 15-April-2020].
[49] OWASP Top 10 Release Notes. OWASP. URL: https://owasp.org/www-
project- top- ten/OWASP_Top_Ten_2017/Top_10-2017_Release_
Notes. [Accessed 15-April-2020].
[50] PCI Security Standards Council. URL: https://www.pcisecuritystandards.
org. [Accessed 10-Mail-2020].
[51] Red Hat Enterprise Linux 4 Security Guide. Red Hat Enterprise. Mar.
2020. URL: https://access.redhat.com/documentation/en-us/red_hat_
enterprise_linux/4/pdf/security_guide/Red_Hat_Enterprise_Linux-4-
Security_Guide-en-US.pdf. [Accessed 15-April-2020].
[52] Duncan Riley. Ransomware targets hospitals and medical providers during
coronavirus pandemic. Mar. 2020. URL: https://siliconangle.com/2020/
03/16 / ransomware - targets - hospitals - medical - providers - coronavirus -
pandemic/. [Accessed 15-April-2020].
98
[53] Margaret Rouse. Confidentiality, integrity, and availability (CIA triad).
Apr. 2020. URL: https : / / whatis . techtarget . com / definition /
Confidentiality-integrity-and-availability-CIA. [Accessed 16-April-2020].
[54] Karen Scarfone, Dan Benigni and Tim Grance. ‘Cyber Security
Standards’. In: Wiley Handbook of Science and Technology for Homeland
Security. John Wiley & Sons, Inc, 2008.
[55] SDLC - Overview. Tutorialspoint. URL: https : / /www . tutorialspoint .
com/sdlc/sdlc_overview.htm. [Accessed 16-April-2020].
[56] Secure by Default. National Cyber Security Centre. URL: https://www.
ncsc.gov.uk/information/secure-default. [Accessed 15-April-2020].
[57] Security-by-design Framework. Cyber Security Agency of Singapore.
Nov. 2017. URL: https://www.csa.gov.sg/legislation/supplementary-
references. [Accessed 15-April-2020].
[58] Sensitive information. TechTarget. 2014. URL: https://whatis.techtarget.
com/definition/sensitive-information. [Accessed 15-April-2020].
[59] Linda Shields and Alison Twycross. ‘The difference between quantit-
ative and qualitative research’. In: Paediatric nursing 15 (2003), p. 24.
URL: https : / / www . researchgate . net / publication / 8964072 _ The _
difference_between_quantitative_and_qualitative_research.
[60] Software Development Process. Wikipedia. URL: https ://en.wikipedia .
org/wiki/Software_development_process. [Accessed 15-April-2020].
[61] Software development with Data Protection by Design and by Default.
Datatilsynet. URL: https : //www.datatilsynet . no/en/about - privacy/
virksomhetenes-plikter/innebygd-personvern/data-protection-by-design-
and-by-default/?print=true. [Accessed 15-April-2020].
[62] Summary of the HIPAA Security Rule. HIPAA. URL: https://www.hhs.
gov / hipaa / for - professionals / security / laws - regulations / index . html.
[Accessed 15-April-2020].
99
[63] The 20 CIS Controls & Resources. Center for Internet Secufrity (CIS).
URL: https://www.cisecurity.org/controls/cis-controls- list/. [Accessed
15-April-2020].
[64] Amrit Tiwana. ‘Platform Ecosystems: Aligning Architecture, Gov-
ernance, and Strategy’. In: 1.0. Morgan Kaufmann, 2014. Chap. 1, p. 5.
URL: https://www.researchgate.net/publication/286345261_Platform_
Ecosystems_Aligning_Architecture_Governance_and_Strategy.
[65] Dan Constantin Tofan. ‘Information Security Standards’. In: Journal
of Mobile, Embedded and Distributed Systems III.3 (2011), pp. 128–
129. URL: https : / / www . researchgate . net / publication / 279679417_
Information_Security_Standards.
[66] What are the Software Development Models? TRYQA. URL: http://tryqa.
com/what-are-the-software-development-models/. [Accessed 15-April-
2020].
[67] What does data protection ‘by design’ and ‘by default’ mean? European
Comission. URL: https : / / ec . europa . eu / info / law / law - topic / data -
protection/reform/rules- business- and-organisations/obligations/what-
does-data-protection-design-and-default-mean_en. [Accessed 15-April-
2020].
[68] What is Cybersecurity? CISCO. URL: https://www.cisco.com/c/en/us/
products/security/what-is-cybersecurity.html. [Accessed 15-April-2020].
[69] What is Security Requirement. IGI Global. URL: https://www.igi-global.
com / dictionary / discovering - core - security - requirements - drm / 26121.
[Accessed 15-April-2020].
[70] Who is the OWASP Foundation? OWASP. URL: https://owasp.org.
[71] Ian Willoughby. Cyber-attack causes majoR disruptions to small-town
CZECH hospital. Dec. 2019. URL: https://www.radio.cz/en/section/
curraffrs/cyber-attack-causes-major-disruptions- to- small- town-czech-
hospital. [Accessed 15-April-2020].
100
Appendices
101
Phase 1: Applicability spread-
sheet
This spreadsheet shows the results from the applicability phase. To explain
the spreadsheet:
• A check for Applicable means the control is applicable to software
and the DHIS2 development team.
• A check for Implementation means the control is applicable to the
implementors.
• A check for both Applicable and Implementation means the control
has to be implemented both by the DHIS2 development team and by
the local implementors.
Four people participated in this phase. All four responses are shown
side-by-side, both for applicability to software, and applicability to
implementation. For every four sets of columns, the responses were
combined into a new column.
For each participant, a counter shows the number of checked controls and
the total number of ASVS controls. The frontend developer, for example,
checked 242 out of 286 as applicable to DHIS2.
103
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79A
SV
S 4
.0Fr
ont-e
ndR
elea
se m
.Im
plem
ento
rB
acke
ndC
ombi
ned
Fron
t-end
dev
elop
erR
elea
se m
anag
erIm
plem
ento
rB
acke
nd d
evel
oper
Fron
tend
Rel
ease
M.
Impl
emen
tor
Bac
kend
Com
bine
dSe
ction
Nam
eItem
Descriptio
nL1
L2L3
App
licable
App
licable
App
licable
App
licable
App
licable
Com
ments
Com
ments
Com
ments
Com
ments
Impl.
Impl.
Impl.
Impl.
Impl.
V1
Arc
hite
ctur
e1.
1.1
Ver
ify th
e us
e of
a s
ecur
e so
ftwar
e de
velo
pmen
t life
cycl
e th
at a
ddre
sses
se
curit
y in
all
stag
es o
f dev
elop
men
t. [C
1]X
X
V1
Arc
hite
ctur
e1.
1.2
Ver
ify th
e us
e of
thre
at m
odel
ing
for e
very
des
ign
chan
ge o
r spr
int p
lann
ing
to id
entif
y th
reat
s, p
lan
for c
ount
erm
easu
res,
faci
litat
e ap
prop
riate
risk
re
spon
ses,
and
gui
de s
ecur
ity te
stin
g.X
X
V1
Arc
hite
ctur
e1.
1.3
Ver
ify th
at a
ll us
er s
torie
s an
d fe
atur
es c
onta
in fu
nctio
nal s
ecur
ity c
onst
rain
ts,
such
as
"As
a us
er, I
sho
uld
be a
ble
to v
iew
and
edi
t my
prof
ile. I
sho
uld
not
be a
ble
to v
iew
or e
dit a
nyon
e el
se's
pro
file"
XX
V1
Arc
hite
ctur
e1.
1.4
Ver
ify d
ocum
enta
tion
and
just
ifica
tion
of a
ll th
e ap
plic
atio
n's
trust
bou
ndar
ies,
co
mpo
nent
s, a
nd s
igni
fican
t dat
a flo
ws.
XX
V1
Arc
hite
ctur
e1.
1.5
Ver
ify d
efin
ition
and
sec
urity
ana
lysi
s of
the
appl
icat
ion'
s hi
gh-le
vel
arch
itect
ure
and
all c
onne
cted
rem
ote
serv
ices
. [C
1]X
X
The
user
can
opt
to
use
exte
rnal
ser
vice
s su
ch a
s A
maz
on
clou
d. It
is p
art
impl
emen
tatio
n, in
th
at th
ey a
re
them
selv
es in
cha
rge
of s
ecur
ing
it, b
ut
from
DH
IS2s
st
andp
oint
, if t
hey
are
abbl
e to
sec
ure
it,
then
they
do.
V1
Arc
hite
ctur
e1.
1.6
Ver
ify im
plem
enta
tion
of c
entra
lized
, sim
ple
(eco
nom
y of
des
ign)
, vet
ted,
se
cure
, and
reus
able
sec
urity
con
trols
to a
void
dup
licat
e, m
issi
ng, i
neffe
ctiv
e,
or in
secu
re c
ontro
ls. [
C10
]X
X
V1
Arc
hite
ctur
e1.
1.7
Ver
ify a
vaila
bilit
y of
a s
ecur
e co
ding
che
cklis
t, se
curit
y re
quire
men
ts,
guid
elin
e, o
r pol
icy
to a
ll de
velo
pers
and
test
ers.
XX
Ther
e is
an
abse
nce
of re
quire
men
ts a
nd
guid
elin
es d
urin
g de
velo
pmen
t
V1
Arc
hite
ctur
e1.
2.1
Ver
ify th
e us
e of
uni
que
or s
peci
al lo
w-p
rivile
ge o
pera
ting
syst
em a
ccou
nts
for a
ll ap
plic
atio
n co
mpo
nent
s, s
ervi
ces,
and
ser
vers
. [C
3]X
X
DH
IS2
is d
eplo
yed
"in-h
ouse
" so
serv
ers,
etc
nee
ds to
be
sec
ured
by
the
impl
emen
tors
.
Rev
elan
t for
so
meb
ody
who
's
host
ing
the
plat
form
(n
ot d
evel
oper
s)
V1
Arc
hite
ctur
e1.
2.2
Ver
ify th
at c
omm
unic
atio
ns b
etw
een
appl
icat
ion
com
pone
nts,
incl
udin
g A
PIs
, m
iddl
ewar
e an
d da
ta la
yers
, are
aut
hent
icat
ed. C
ompo
nent
s sh
ould
hav
e th
e le
ast n
eces
sary
priv
ilege
s ne
eded
. [C
3]X
X
Last
sen
tenc
e is
an
impl
emen
tatio
n (c
onfig
ure
issu
e).
To e
nsur
e th
ey a
re
auth
entic
ated
, is
an
appl
icat
ion
issu
e.
In im
plem
enta
tion,
ev
ery
user
sho
uld
have
an
uniq
ue d
ata
base
etc
. App
licab
le
to d
ocum
enta
tion.
V1
Arc
hite
ctur
e1.
2.3
Ver
ify th
at th
e ap
plic
atio
n us
es a
sin
gle
vette
d au
then
ticat
ion
mec
hani
sm th
at
is k
now
n to
be
secu
re, c
an b
e ex
tend
ed to
incl
ude
stro
ng a
uthe
ntic
atio
n, a
nd
has
suffi
cien
t log
ging
and
mon
itorin
g to
det
ect a
ccou
nt a
buse
or b
reac
hes.
XX
Aut
hent
icat
ion
need
s to
be
impl
emen
ted
by th
e de
velo
pers
for t
he
core
sof
twar
e, b
ut
logg
ing/
mon
itorin
g is
do
ne o
n a
serv
er
basi
s, a
nd
auth
entic
atio
n fo
r ad
ditio
nal s
erve
r so
ftwar
e ne
eds
to b
e do
ne b
y th
e im
plem
ento
rs.
V1
Arc
hite
ctur
e1.
2.4
Ver
ify th
at a
ll au
then
ticat
ion
path
way
s an
d id
entit
y m
anag
emen
t AP
Is
impl
emen
t con
sist
ent a
uthe
ntic
atio
n se
curit
y co
ntro
l stre
ngth
, suc
h th
at th
ere
are
no w
eake
r alte
rnat
ives
per
the
risk
of th
e ap
plic
atio
n.X
X
V1
Arc
hite
ctur
e1.
4.1
Ver
ify th
at tr
uste
d en
forc
emen
t poi
nts
such
as
at a
cces
s co
ntro
l gat
eway
s,
serv
ers,
and
ser
verle
ss fu
nctio
ns e
nfor
ce a
cces
s co
ntro
ls. N
ever
enf
orce
ac
cess
con
trols
on
the
clie
nt.
XX
/por
tal g
ives
aw
ay
user
nam
e an
d pa
ssw
ord,
i.e.
no
acce
ss c
ontro
ls o
n th
e cl
ient
(wor
ds c
ase
exam
ple)
.
Do
not e
nfor
ce
acce
ss c
ontro
l on
the
clie
nt. D
on't
have
any
se
rvic
e fu
nctio
ns,
soun
ds li
ke a
n im
plem
enta
tion
issu
e.
V1
Arc
hite
ctur
e1.
4.2
Ver
ify th
at th
e ch
osen
acc
ess
cont
rol s
olut
ion
is fl
exib
le e
noug
h to
mee
t the
ap
plic
atio
n's
need
s.X
X
V1
Arc
hite
ctur
e1.
4.3
Ver
ify e
nfor
cem
ent o
f the
prin
cipl
e of
leas
t priv
ilege
in fu
nctio
ns, d
ata
files
, U
RLs
, con
trolle
rs, s
ervi
ces,
and
oth
er re
sour
ces.
Thi
s im
plie
s pr
otec
tion
agai
nst s
poof
ing
and
elev
atio
n of
priv
ilege
.X
X
The
syst
em is
in
plac
e, b
ut th
e im
plem
ento
rs
conf
igur
e it.
Hav
e th
e ab
ility
to c
onfig
ure
the
acce
ss to
thes
e th
ings
, but
don
't ha
ve
any
setu
p to
hin
der
spoo
fing,
for
exam
ple.
In th
e ca
se
of e
leva
tion,
you
ca
nnot
giv
e m
ore
acce
ss th
an w
hat t
he
user
has
.
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79
V1
Arc
hite
ctur
e1.
4.4
Ver
ify th
e ap
plic
atio
n us
es a
sin
gle
and
wel
l-vet
ted
acce
ss c
ontro
l m
echa
nism
for a
cces
sing
pro
tect
ed d
ata
and
reso
urce
s. A
ll re
ques
ts m
ust
pass
thro
ugh
this
sin
gle
mec
hani
sm to
avo
id c
opy
and
past
e or
inse
cure
al
tern
ativ
e pa
ths.
[C7]
XX
True
for r
esou
rces
in
tern
al to
DH
IS2,
bu
t an
appl
icat
ion
can
requ
est
addi
tiona
l un
prot
ecte
d re
sour
ces
out o
f the
se
curit
y m
easu
res
dhis
2 pr
ovid
es.
V1
Arc
hite
ctur
e1.
4.5
Ver
ify th
at a
ttrib
ute
or fe
atur
e-ba
sed
acce
ss c
ontro
l is
used
whe
reby
the
code
ch
ecks
the
user
's a
utho
rizat
ion
for a
feat
ure/
data
item
rath
er th
an ju
st th
eir
role
. Per
mis
sion
s sh
ould
stil
l be
allo
cate
d us
ing
role
s. [C
7]X
X
We
don'
t aut
horiz
e w
hen
we
chec
k th
is
type
of a
cces
s co
ntro
l; on
ly c
heck
pe
rmis
sion
s.
V1
Arc
hite
ctur
e1.
5.1
Ver
ify th
at in
put a
nd o
utpu
t req
uire
men
ts c
lear
ly d
efin
e ho
w to
han
dle
and
proc
ess
data
bas
ed o
n ty
pe, c
onte
nt, a
nd a
pplic
able
law
s, re
gula
tions
, and
ot
her p
olic
y co
mpl
ianc
e.X
X
DH
IS2
is a
sel
f-ho
sted
sof
twar
e, a
nd
thus
the
need
to
com
ply
with
law
s an
d re
gula
tions
fall
on th
e im
plem
ento
rs. (
kan
ikke
end
re s
yste
m ti
l å
være
kom
plia
nt,
men
kan
dea
ktiv
etet
fu
nksj
onal
itete
n).
App
licab
le, b
ut le
ans
tow
ards
im
plem
enta
tion.
D
esig
ned
for m
any
envi
ronm
ents
, but
it's
an
impl
emen
tatio
n is
sue.
Dep
ends
on
wha
t is
repo
rted
from
th
e fie
ld.
Hav
e su
ppor
t for
this
, bu
t is
an
impl
emen
tatio
n is
sue
V1
Arc
hite
ctur
e1.
5.2
Ver
ify th
at s
eria
lizat
ion
is n
ot u
sed
whe
n co
mm
unic
atin
g w
ith u
ntru
sted
cl
ient
s. If
this
is n
ot p
ossi
ble,
ens
ure
that
ade
quat
e in
tegr
ity c
ontro
ls (a
nd
poss
ibly
enc
rypt
ion
if se
nsiti
ve d
ata
is s
ent)
are
enfo
rced
to p
reve
nt
dese
rializ
atio
n at
tack
s in
clud
ing
obje
ct in
ject
ion.
XX
Rel
ated
to
impl
emen
tatio
n. A
t th
e m
omen
t, no
way
to
kno
w if
a c
lient
sh
ould
be
trust
ed. I
n U
S re
gula
tions
on
patie
nt s
yste
m y
ou
are
not a
llow
ed to
ac
cess
the
reso
urce
if
the
devi
ce is
n't
trust
ed. I
ssue
in
And
roid
; eas
ily
hack
ed.
V1
Arc
hite
ctur
e1.
5.3
Ver
ify th
at in
put v
alid
atio
n is
enf
orce
d on
a tr
uste
d se
rvic
e la
yer.
[C5]
XX
V1
Arc
hite
ctur
e1.
5.4
Ver
ify th
at o
utpu
t enc
odin
g oc
curs
clo
se to
or b
y th
e in
terp
rete
r for
whi
ch it
is
inte
nded
. [C
4]X
X
V1
Arc
hite
ctur
e1.
6.1
Ver
ify th
at th
ere
is a
n ex
plic
it po
licy
for m
anag
emen
t of c
rypt
ogra
phic
key
s an
d th
at a
cry
ptog
raph
ic k
ey li
fecy
cle
follo
ws
a ke
y m
anag
emen
t sta
ndar
d su
ch a
s N
IST
SP
800
-57.
XX
Uns
ure
if w
e ha
ve
cryp
to p
arts
in th
e co
deba
se, i
f so,
is
appl
icab
le (n
eeds
m
ore
rese
arch
). If
we
have
it, t
hen
it is
ap
plic
able
. If n
ot,
then
it is
not
ap
plic
able
.
V1
Arc
hite
ctur
e1.
6.2
Ver
ify th
at c
onsu
mer
s of
cry
ptog
raph
ic s
ervi
ces
prot
ect k
ey m
ater
ial a
nd
othe
r sec
rets
by
usin
g ke
y va
ults
or A
PI b
ased
alte
rnat
ives
.X
X
Uns
ure
if w
e ha
ve
cryp
to p
arts
in th
e co
deba
se, i
f so,
is
appl
icab
le (n
eeds
m
ore
rese
arch
). If
we
have
it, t
hen
it is
ap
plic
able
. If n
ot,
then
it is
not
ap
plic
able
.
Pas
s on
thei
r end
, but
up
to th
e im
plem
ento
rs to
ha
ndle
it. D
oesn
t in
volv
e th
e ba
cken
d.
V1
Arc
hite
ctur
e1.
6.3
Ver
ify th
at a
ll ke
ys a
nd p
assw
ords
are
repl
acea
ble
and
are
part
of a
wel
l-de
fined
pro
cess
to re
-enc
rypt
sen
sitiv
e da
ta.
XX
Uns
ure
if w
e ha
ve
cryp
to p
arts
in th
e co
deba
se, i
f so,
is
appl
icab
le (n
eeds
m
ore
rese
arch
). If
we
have
it, t
hen
it is
ap
plic
able
. If n
ot,
then
it is
not
ap
plic
able
.
V1
Arc
hite
ctur
e1.
6.4
Ver
ify th
at s
ymm
etric
key
s, p
assw
ords
, or A
PI s
ecre
ts g
ener
ated
by
or
shar
ed w
ith c
lient
s ar
e us
ed o
nly
in p
rote
ctin
g lo
w ri
sk s
ecre
ts, s
uch
as
encr
yptin
g lo
cal s
tora
ge, o
r tem
pora
ry e
phem
eral
use
s su
ch a
s pa
ram
eter
ob
fusc
atio
n. S
harin
g se
cret
s w
ith c
lient
s is
cle
ar-te
xt e
quiv
alen
t and
ar
chite
ctur
ally
sho
uld
be tr
eate
d as
suc
h.X
X
Uns
ure
if w
e ha
ve
cryp
to p
arts
in th
e co
deba
se, i
f so,
is
appl
icab
le (n
eeds
m
ore
rese
arch
). If
we
have
it, t
hen
it is
ap
plic
able
. If n
ot,
then
it is
not
ap
plic
able
.
This
is u
nrel
ated
to
softw
are
deve
lopm
ent.
V1
Arc
hite
ctur
e1.
7.1
Ver
ify th
at a
com
mon
logg
ing
form
at a
nd a
ppro
ach
is u
sed
acro
ss th
e sy
stem
. [C
9]X
X
For D
HIS
2 th
is is
ap
plic
able
for t
he
core
team
, for
su
rrou
ndin
g so
ftwar
e su
ch a
s ng
inx
(web
ser
ver)
, th
e im
plem
ento
r is
resp
onsi
ble.
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79
V1
Arc
hite
ctur
e1.
7.2
Ver
ify th
at lo
gs a
re s
ecur
ely
trans
mitt
ed to
a p
refe
rabl
y re
mot
e sy
stem
for
anal
ysis
, det
ectio
n, a
lerti
ng, a
nd e
scal
atio
n. [C
9]X
X
V1
Arc
hite
ctur
e1.
8.1
Ver
ify th
at a
ll se
nsiti
ve d
ata
is id
entif
ied
and
clas
sifie
d in
to p
rote
ctio
n le
vels
.X
X
For n
on-a
ggre
gate
d da
ta, s
uch
as d
ata
rela
ted
to in
divi
dual
s in
Tra
cker
, the
re
shou
ld b
e so
me
form
of p
rote
ctio
n le
vels
.D
on't
know
wha
t's
sens
itive
Not
pos
sibl
e fo
r de
velo
pmen
ts to
cl
assi
fy d
ata;
up
to
loca
l gov
ernm
ents
. U
p to
dev
elop
ers
to
allo
w th
e ap
plic
atio
n to
cla
ssify
dat
a.
V1
Arc
hite
ctur
e1.
8.2
Ver
ify th
at a
ll pr
otec
tion
leve
ls h
ave
an a
ssoc
iate
d se
t of p
rote
ctio
n re
quire
men
ts, s
uch
as e
ncry
ptio
n re
quire
men
ts, i
nteg
rity
requ
irem
ents
, re
tent
ion,
priv
acy
and
othe
r con
fiden
tialit
y re
quire
men
ts, a
nd th
at th
ese
are
appl
ied
in th
e ar
chite
ctur
e.X
X
V1
Arc
hite
ctur
e1.
9.1
Ver
ify th
e ap
plic
atio
n en
cryp
ts c
omm
unic
atio
ns b
etw
een
com
pone
nts,
pa
rticu
larly
whe
n th
ese
com
pone
nts
are
in d
iffer
ent c
onta
iner
s, s
yste
ms,
si
tes,
or c
loud
pro
vide
rs. [
C3]
XX
The
core
DH
IS2
softw
are
need
s to
gu
aran
tee
use
of
HTT
PS
, and
on
the
impl
emen
tatio
n si
de,
SS
L te
rmin
atio
n m
ust b
e do
ne
acco
rdin
g to
sec
ure
stan
dard
s.
Sup
port
for u
sing
ht
tps
and
ssl,
but a
lso
impl
emen
tatio
n
V1
Arc
hite
ctur
e1.
9.2
Ver
ify th
at a
pplic
atio
n co
mpo
nent
s ve
rify
the
auth
entic
ity o
f eac
h si
de in
a
com
mun
icat
ion
link
to p
reve
nt p
erso
n-in
-the-
mid
dle
atta
cks.
For
exa
mpl
e,
appl
icat
ion
com
pone
nts
shou
ld v
alid
ate
TLS
cer
tific
ates
and
cha
ins.
XX
Val
id fo
r des
ktop
us
ers,
but
and
roid
is
ano
ther
di
men
sion
. A
ndro
id re
late
d, u
sing
P
KI,
VP
N.
Hav
e su
ppor
t for
TL
S, b
ut u
nsur
e if
they
val
idat
e ce
rtific
ates
V1
Arc
hite
ctur
e1.
10.1
Ver
ify th
at a
sou
rce
code
con
trol s
yste
m is
in u
se, w
ith p
roce
dure
s to
ens
ure
that
che
ck-in
s ar
e ac
com
pani
ed b
y is
sues
or c
hang
e tic
kets
. The
sou
rce
code
con
trol s
yste
m s
houl
d ha
ve a
cces
s co
ntro
l and
iden
tifia
ble
user
s to
al
low
trac
eabi
lity
of a
ny c
hang
es.
XX
V1
Arc
hite
ctur
e1.
11.1
Ver
ify th
e de
finiti
on a
nd d
ocum
enta
tion
of a
ll ap
plic
atio
n co
mpo
nent
s in
term
s of
the
busi
ness
or s
ecur
ity fu
nctio
ns th
ey p
rovi
de.
XX
V1
Arc
hite
ctur
e1.
11.2
Ver
ify th
at a
ll hi
gh-v
alue
bus
ines
s lo
gic
flow
s, in
clud
ing
auth
entic
atio
n,
sess
ion
man
agem
ent a
nd a
cces
s co
ntro
l, do
not
sha
re u
nsyn
chro
nize
d st
ate.
XX
V1
Arc
hite
ctur
e1.
11.3
Ver
ify th
at a
ll hi
gh-v
alue
bus
ines
s lo
gic
flow
s, in
clud
ing
auth
entic
atio
n,
sess
ion
man
agem
ent a
nd a
cces
s co
ntro
l are
thre
ad s
afe
and
resi
stan
t to
time-
of-c
heck
and
tim
e-of
-use
race
con
ditio
ns.
X
Don
t hav
e ra
ce
cond
ition
s po
sibl
ities
in
acc
ess
cont
orls
. E
very
thin
g is
don
e in
on
e th
read
.
V1
Arc
hite
ctur
e1.
12.1
Ver
ify th
at u
ser-
uplo
aded
file
s ar
e st
ored
out
side
of t
he w
eb ro
ot.
XX
It ha
s to
be
a co
nfig
urat
ion.
If th
e sy
stem
sto
res
the
files
insi
de th
e ro
ot,
som
eone
cou
ld
conf
igur
e th
e di
rect
ory
whe
re th
e da
ta is
sto
red
insi
de th
e w
eb ro
ot
V1
Arc
hite
ctur
e1.
12.2
Ver
ify th
at u
ser-
uplo
aded
file
s - i
f req
uire
d to
be
disp
laye
d or
dow
nloa
ded
from
the
appl
icat
ion
- are
ser
ved
by e
ither
oct
et s
tream
dow
nloa
ds, o
r fro
m
an u
nrel
ated
dom
ain,
suc
h as
a c
loud
file
sto
rage
buc
ket.
Impl
emen
t a
suita
ble
cont
ent s
ecur
ity p
olic
y to
redu
ce th
e ris
k fro
m X
SS
vec
tors
or o
ther
at
tack
s fro
m th
e up
load
ed fi
le.
XX
One
use
cas
e is
in
stal
ling
web
app
s fro
m th
e D
HIS
2 A
pp
Sto
re.
V1
Arc
hite
ctur
e1.
14.1
Ver
ify th
e se
greg
atio
n of
com
pone
nts
of d
iffer
ing
trust
leve
ls th
roug
h w
ell-
defin
ed s
ecur
ity c
ontro
ls, f
irew
all r
ules
, AP
I gat
eway
s, re
vers
e pr
oxie
s, c
loud
-ba
sed
secu
rity
grou
ps, o
r sim
ilar m
echa
nism
s.X
X
Sec
uriy
fire
wal
ls
and
prox
y ar
e al
l de
pend
endi
ng o
n ho
w y
ou im
plem
ent
it.
V1
Arc
hite
ctur
e1.
14.2
Ver
ify th
at if
dep
loyi
ng b
inar
ies
to u
ntru
sted
dev
ices
mak
es u
se o
f bin
ary
sign
atur
es, t
rust
ed c
onne
ctio
ns, a
nd v
erifi
ed e
ndpo
ints
.X
X
V1
Arc
hite
ctur
e1.
14.3
Ver
ify th
at th
e bu
ild p
ipel
ine
war
ns o
f out
-of-d
ate
or in
secu
re c
ompo
nent
s an
d ta
kes
appr
opria
te a
ctio
ns.
XX
V1
Arc
hite
ctur
e1.
14.4
Ver
ify th
at th
e bu
ild p
ipel
ine
cont
ains
a b
uild
ste
p to
aut
omat
ical
ly b
uild
and
ve
rify
the
secu
re d
eplo
ymen
t of t
he a
pplic
atio
n, p
artic
ular
ly if
the
appl
icat
ion
infra
stru
ctur
e is
sof
twar
e de
fined
, suc
h as
clo
ud e
nviro
nmen
t bui
ld s
crip
ts.
XX
Don
e fo
r e.g
. the
A
pp S
tore
bac
kend
.
V1
Arc
hite
ctur
e1.
14.5
Ver
ify th
at a
pplic
atio
n de
ploy
men
ts a
dequ
atel
y sa
ndbo
x, c
onta
iner
ize
and/
or
isol
ate
at th
e ne
twor
k le
vel t
o de
lay
and
dete
r atta
cker
s fro
m a
ttack
ing
othe
r ap
plic
atio
ns, e
spec
ially
whe
n th
ey a
re p
erfo
rmin
g se
nsiti
ve o
r dan
gero
us
actio
ns s
uch
as d
eser
ializ
atio
n. [C
5]X
XD
HIS
2 he
lps
with
im
plem
enta
tion
V1
Arc
hite
ctur
e1.
14.6
Ver
ify th
e ap
plic
atio
n do
es n
ot u
se u
nsup
porte
d, in
secu
re, o
r dep
reca
ted
clie
nt-s
ide
tech
nolo
gies
suc
h as
NS
AP
I plu
gins
, Fla
sh, S
hock
wav
e, A
ctiv
eX,
Silv
erlig
ht, N
AC
L, o
r clie
nt-s
ide
Java
app
lets
.X
X
Peo
ple
can
crea
te
thei
r ow
n cl
ient
s fo
r th
e A
PI,
whi
ch
DH
IS2
can'
t co
ntro
l. H
ave
to
mak
e su
re th
e A
PI
is s
ecur
e.
App
licab
le fo
r the
co
re a
pps
whi
ch
shou
ld b
e se
cure
.
Do
not u
se a
ny o
f th
ese
thin
gs, b
ut
have
clie
nt
tech
nolo
gies
that
they
kn
ow a
re in
sequ
ece,
bu
t tha
t the
y ar
e w
orki
ng o
n se
curin
g
V2
Aut
hent
icat
ion
2.1.
1V
erify
that
use
r set
pas
swor
ds a
re a
t lea
st 1
2 ch
arac
ters
in le
ngth
. [C
6]X
XX
You
can
con
figur
e it
to b
e 12
cha
ract
ers.
V2
Aut
hent
icat
ion
2.1.
2V
erify
that
pas
swor
ds 6
4 ch
arac
ters
or l
onge
r are
per
mitt
ed. [
C6]
XX
X
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79
V2
Aut
hent
icat
ion
2.1.
3V
erify
that
pas
swor
ds c
an c
onta
in s
pace
s an
d tru
ncat
ion
is n
ot p
erfo
rmed
. C
onse
cutiv
e m
ultip
le s
pace
s M
AY
opt
iona
lly b
e co
ales
ced.
[C6]
XX
X
V2
Aut
hent
icat
ion
2.1.
4
Ver
ify th
at U
nico
de c
hara
cter
s ar
e pe
rmitt
ed in
pas
swor
ds. A
sin
gle
Uni
code
co
de p
oint
is c
onsi
dere
d a
char
acte
r, so
12
emoj
i or 6
4 ka
nji c
hara
cter
s sh
ould
be
valid
and
per
mitt
ed.
XX
XV
2A
uthe
ntic
atio
n2.
1.5
Ver
ify u
sers
can
cha
nge
thei
r pas
swor
d.X
XX
V2
Aut
hent
icat
ion
2.1.
6V
erify
that
pas
swor
d ch
ange
func
tiona
lity
requ
ires
the
user
's c
urre
nt a
nd n
ew
pass
wor
d.X
XX
V2
Aut
hent
icat
ion
2.1.
7
Ver
ify th
at p
assw
ords
sub
mitt
ed d
urin
g ac
coun
t reg
istra
tion,
logi
n, a
nd
pass
wor
d ch
ange
are
che
cked
aga
inst
a s
et o
f bre
ache
d pa
ssw
ords
eith
er
loca
lly (s
uch
as th
e to
p 1,
000
or 1
0,00
0 m
ost c
omm
on p
assw
ords
whi
ch
mat
ch th
e sy
stem
's p
assw
ord
polic
y) o
r usi
ng a
n ex
tern
al A
PI.
If us
ing
an A
PI
a ze
ro k
now
ledg
e pr
oof o
r oth
er m
echa
nism
sho
uld
be u
sed
to e
nsur
e th
at
the
plai
n te
xt p
assw
ord
is n
ot s
ent o
r use
d in
ver
ifyin
g th
e br
each
sta
tus
of
the
pass
wor
d. If
the
pass
wor
d is
bre
ache
d, th
e ap
plic
atio
n m
ust r
equi
re th
e us
er to
set
a n
ew n
on-b
reac
hed
pass
wor
d. [C
6]X
XX
V2
Aut
hent
icat
ion
2.1.
8V
erify
that
a p
assw
ord
stre
ngth
met
er is
pro
vide
d to
hel
p us
ers
set a
stro
nger
pa
ssw
ord.
XX
X
V2
Aut
hent
icat
ion
2.1.
9
Ver
ify th
at th
ere
are
no p
assw
ord
com
posi
tion
rule
s lim
iting
the
type
of
char
acte
rs p
erm
itted
. The
re s
houl
d be
no
requ
irem
ent f
or u
pper
or l
ower
ca
se o
r num
bers
or s
peci
al c
hara
cter
s. [C
6]X
XX
Sho
uld
have
the
poss
iblit
y to
rem
ove
the
conf
igur
atio
n in
th
e fu
ture
V2
Aut
hent
icat
ion
2.1.
10V
erify
that
ther
e ar
e no
per
iodi
c cr
eden
tial r
otat
ion
or p
assw
ord
hist
ory
requ
irem
ents
.X
XX
Diff
eren
t re
quire
men
ts o
n di
ffere
nt d
istri
cts.
Can
opt
out
V2
Aut
hent
icat
ion
2.1.
11V
erify
that
"pas
te" f
unct
iona
lity,
bro
wse
r pas
swor
d he
lper
s, a
nd e
xter
nal
pass
wor
d m
anag
ers
are
perm
itted
.X
XX
V2
Aut
hent
icat
ion
2.1.
12
Ver
ify th
at th
e us
er c
an c
hoos
e to
eith
er te
mpo
raril
y vi
ew th
e en
tire
mas
ked
pass
wor
d, o
r tem
pora
rily
view
the
last
type
d ch
arac
ter o
f the
pas
swor
d on
pl
atfo
rms
that
do
not h
ave
this
as
nativ
e fu
nctio
nalit
y.X
XX
V2
Aut
hent
icat
ion
2.2.
1
Ver
ify th
at a
nti-a
utom
atio
n co
ntro
ls a
re e
ffect
ive
at m
itiga
ting
brea
ched
cr
eden
tial t
estin
g, b
rute
forc
e, a
nd a
ccou
nt lo
ckou
t atta
cks.
Suc
h co
ntro
ls
incl
ude
bloc
king
the
mos
t com
mon
bre
ache
d pa
ssw
ords
, sof
t loc
kout
s, ra
te
limiti
ng, C
AP
TCH
A, e
ver i
ncre
asin
g de
lays
bet
wee
n at
tem
pts,
IP a
ddre
ss
rest
rictio
ns, o
r ris
k-ba
sed
rest
rictio
ns s
uch
as lo
catio
n, fi
rst l
ogin
on
a de
vice
, re
cent
atte
mpt
s to
unl
ock
the
acco
unt,
or s
imila
r. V
erify
that
no
mor
e th
an
100
faile
d at
tem
pts
per h
our i
s po
ssib
le o
n a
sing
le a
ccou
nt.
XX
X
Hav
e po
ssib
lity
to
opt-i
n an
d us
e C
AP
TCH
A
V2
Aut
hent
icat
ion
2.2.
2
Ver
ify th
at th
e us
e of
wea
k au
then
ticat
ors
(suc
h as
SM
S a
nd e
mai
l) is
lim
ited
to s
econ
dary
ver
ifica
tion
and
trans
actio
n ap
prov
al a
nd n
ot a
s a
repl
acem
ent
for m
ore
secu
re a
uthe
ntic
atio
n m
etho
ds. V
erify
that
stro
nger
met
hods
are
of
fere
d be
fore
wea
k m
etho
ds, u
sers
are
aw
are
of th
e ris
ks, o
r tha
t pro
per
mea
sure
s ar
e in
pla
ce to
lim
it th
e ris
ks o
f acc
ount
com
prom
ise.
XX
X
V2
Aut
hent
icat
ion
2.2.
3
Ver
ify th
at s
ecur
e no
tific
atio
ns a
re s
ent t
o us
ers
afte
r upd
ates
to
auth
entic
atio
n de
tails
, suc
h as
cre
dent
ial r
eset
s, e
mai
l or a
ddre
ss c
hang
es,
logg
ing
in fr
om u
nkno
wn
or ri
sky
loca
tions
. The
use
of p
ush
notif
icat
ions
- ra
ther
than
SM
S o
r em
ail -
is p
refe
rred
, but
in th
e ab
senc
e of
pus
h no
tific
atio
ns, S
MS
or e
mai
l is
acce
ptab
le a
s lo
ng a
s no
sen
sitiv
e in
form
atio
n is
dis
clos
ed in
the
notif
icat
ion.
XX
X
V2
Aut
hent
icat
ion
2.2.
4
Ver
ify im
pers
onat
ion
resi
stan
ce a
gain
st p
hish
ing,
suc
h as
the
use
of m
ulti-
fact
or a
uthe
ntic
atio
n, c
rypt
ogra
phic
dev
ices
with
inte
nt (s
uch
as c
onne
cted
ke
ys w
ith a
pus
h to
aut
hent
icat
e), o
r at h
ighe
r AA
L le
vels
, clie
nt-s
ide
certi
ficat
es.
X
2FA
is a
set
ting,
not
m
anda
tory
, so
up to
th
e im
plem
ento
r to
enab
le/re
quire
itH
ave
the
poss
iblit
y to
en
ale
mul
ti-fa
ctor
.
V2
Aut
hent
icat
ion
2.2.
5
Ver
ify th
at w
here
a c
rede
ntia
l ser
vice
pro
vide
r (C
SP
) and
the
appl
icat
ion
verif
ying
aut
hent
icat
ion
are
sepa
rate
d, m
utua
lly a
uthe
ntic
ated
TLS
is in
pla
ce
betw
een
the
two
endp
oint
s.X
Ext
erna
l ser
vice
to
conf
igur
e 2F
A
V2
Aut
hent
icat
ion
2.2.
6V
erify
repl
ay re
sist
ance
thro
ugh
the
man
date
d us
e of
OTP
dev
ices
, cr
ypto
grap
hic
auth
entic
ator
s, o
r loo
kup
code
s.X
"Man
date
d" is
im
pora
nt. B
ut th
e sy
stem
has
to
supp
ort i
t.
Don
't pr
ovid
e th
ose
serv
ices
. Im
lem
enta
tion
issu
e.
Don
't us
e O
TP. H
ave
toke
ns w
hen
you
rese
t pas
swor
d,
whi
ch a
re te
mpo
rariy
un
til y
ou h
ave
alte
red
your
pas
swor
d
V2
Aut
hent
icat
ion
2.2.
7V
erify
inte
nt to
aut
hent
icat
e by
requ
iring
the
entry
of a
n O
TP to
ken
or u
ser-
initi
ated
act
ion
such
as
a bu
tton
pres
s on
a F
IDO
har
dwar
e ke
y.X
V2
Aut
hent
icat
ion
2.3.
1
Ver
ify s
yste
m g
ener
ated
initi
al p
assw
ords
or a
ctiv
atio
n co
des
SH
OU
LD b
e se
cure
ly ra
ndom
ly g
ener
ated
, SH
OU
LD b
e at
leas
t 6 c
hara
cter
s lo
ng, a
nd
MA
Y c
onta
in le
tters
and
num
bers
, and
exp
ire a
fter a
sho
rt pe
riod
of ti
me.
Th
ese
initi
al s
ecre
ts m
ust n
ot b
e pe
rmitt
ed to
bec
ome
the
long
term
pa
ssw
ord.
XX
X
V2
Aut
hent
icat
ion
2.3.
2V
erify
that
enr
ollm
ent a
nd u
se o
f sub
scrib
er-p
rovi
ded
auth
entic
atio
n de
vice
s ar
e su
ppor
ted,
suc
h as
a U
2F o
r FID
O to
kens
.X
XH
ave
to s
uppo
rt it.
Har
d to
do
over
seas
.
V2
Aut
hent
icat
ion
2.3.
3V
erify
that
rene
wal
inst
ruct
ions
are
sen
t with
suf
ficie
nt ti
me
to re
new
tim
e bo
und
auth
entic
ator
s.X
X
V2
Aut
hent
icat
ion
2.4.
1
Ver
ify th
at p
assw
ords
are
sto
red
in a
form
that
is re
sist
ant t
o of
fline
atta
cks.
P
assw
ords
SH
ALL
be
salte
d an
d ha
shed
usi
ng a
n ap
prov
ed o
ne-w
ay k
ey
deriv
atio
n or
pas
swor
d ha
shin
g fu
nctio
n. K
ey d
eriv
atio
n an
d pa
ssw
ord
hash
ing
func
tions
take
a p
assw
ord,
a s
alt,
and
a co
st fa
ctor
as
inpu
ts w
hen
gene
ratin
g a
pass
wor
d ha
sh. [
C6]
XX
V2
Aut
hent
icat
ion
2.4.
2
Ver
ify th
at th
e sa
lt is
at l
east
32
bits
in le
ngth
and
be
chos
en a
rbitr
arily
to
min
imiz
e sa
lt va
lue
colli
sion
s am
ong
stor
ed h
ashe
s. F
or e
ach
cred
entia
l, a
uniq
ue s
alt v
alue
and
the
resu
lting
has
h S
HA
LL b
e st
ored
. [C
6]X
X
We
use
a di
ffere
nt
fram
ewor
k, S
prin
t S
ecur
ity. D
on't
do th
e la
st b
it.
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79
V2
Aut
hent
icat
ion
2.4.
3
Ver
ify th
at if
PB
KD
F2 is
use
d, th
e ite
ratio
n co
unt S
HO
ULD
be
as la
rge
as
verif
icat
ion
serv
er p
erfo
rman
ce w
ill a
llow
, typ
ical
ly a
t lea
st 1
00,0
00 it
erat
ions
. [C
6]X
X
V2
Aut
hent
icat
ion
2.4.
4V
erify
that
if b
cryp
t is
used
, the
wor
k fa
ctor
SH
OU
LD b
e as
larg
e as
ve
rific
atio
n se
rver
per
form
ance
will
allo
w, t
ypic
ally
at l
east
13.
[C6]
XX
V2
Aut
hent
icat
ion
2.4.
5
Ver
ify th
at a
n ad
ditio
nal i
tera
tion
of a
key
der
ivat
ion
func
tion
is p
erfo
rmed
, us
ing
a sa
lt va
lue
that
is s
ecre
t and
kno
wn
only
to th
e ve
rifie
r. G
ener
ate
the
salt
valu
e us
ing
an a
ppro
ved
rand
om b
it ge
nera
tor [
SP
800
-90A
r1] a
nd
prov
ide
at le
ast t
he m
inim
um s
ecur
ity s
treng
th s
peci
fied
in th
e la
test
revi
sion
of
SP
800
-131
A. T
he s
ecre
t sal
t val
ue S
HA
LL b
e st
ored
sep
arat
ely
from
the
hash
ed p
assw
ords
(e.g
., in
a s
peci
aliz
ed d
evic
e lik
e a
hard
war
e se
curit
y m
odul
e).
XX
V2
Aut
hent
icat
ion
2.5.
1V
erify
that
a s
yste
m g
ener
ated
initi
al a
ctiv
atio
n or
reco
very
sec
ret i
s no
t sen
t in
cle
ar te
xt to
the
user
. [C
6]X
XX
V2
Aut
hent
icat
ion
2.5.
2V
erify
pas
swor
d hi
nts
or k
now
ledg
e-ba
sed
auth
entic
atio
n (s
o-ca
lled
"sec
ret
ques
tions
") a
re n
ot p
rese
nt.
XX
X
V2
Aut
hent
icat
ion
2.5.
3V
erify
pas
swor
d cr
eden
tial r
ecov
ery
does
not
reve
al th
e cu
rren
t pas
swor
d in
an
y w
ay. [
C6]
XX
X
V2
Aut
hent
icat
ion
2.5.
4V
erify
sha
red
or d
efau
lt ac
coun
ts a
re n
ot p
rese
nt (e
.g. "
root
", "a
dmin
", or
"s
a").
XX
X
The
acco
unts
is
som
ethi
ng
impl
emen
tatio
n co
nfig
ures
th
emse
lves
. The
re
is a
bui
lt in
adm
in
acco
unt w
hen
you
boot
stra
p th
e sy
stem
that
is u
sed
to c
reat
e ot
her
acco
unts
Thi
s sh
ould
be
disa
bled
la
ter o
n. D
HIS
2 ca
n't d
o an
ythi
ng
abou
t it
Adm
in s
houl
d be
di
sabl
ed in
im
plem
enta
tion.
P
eopl
e in
oth
er
coun
tries
don
't di
sabl
e it
them
selv
es
and
leav
e it
pres
ent.
V2
Aut
hent
icat
ion
2.5.
5V
erify
that
if a
n au
then
ticat
ion
fact
or is
cha
nged
or r
epla
ced,
that
the
user
is
notif
ied
of th
is e
vent
.X
XX
V2
Aut
hent
icat
ion
2.5.
6
Ver
ify fo
rgot
ten
pass
wor
d, a
nd o
ther
reco
very
pat
hs u
se a
sec
ure
reco
very
m
echa
nism
, suc
h as
TO
TP o
r oth
er s
oft t
oken
, mob
ile p
ush,
or a
noth
er
offli
ne re
cove
ry m
echa
nism
. [C
6]X
XX
V2
Aut
hent
icat
ion
2.5.
7V
erify
that
if O
TP o
r mul
ti-fa
ctor
aut
hent
icat
ion
fact
ors
are
lost
, tha
t evi
denc
e of
iden
tity
proo
fing
is p
erfo
rmed
at t
he s
ame
leve
l as
durin
g en
rollm
ent.
XX
Don
t use
muc
h m
ulti
auth
entic
atio
n
Impl
emen
atio
n be
caus
e th
e w
ay y
ou
reco
ver i
s th
at y
ou
get i
n to
uch
with
the
syst
em a
dmin
stra
tor.
V2
Aut
hent
icat
ion
2.6.
1V
erify
that
look
up s
ecre
ts c
an b
e us
ed o
nly
once
.X
X
Unk
now
n to
me
if w
e us
e lo
okup
sec
rets
in
this
form
V2
Aut
hent
icat
ion
2.6.
2
Ver
ify th
at lo
okup
sec
rets
hav
e su
ffici
ent r
ando
mne
ss (1
12 b
its o
f ent
ropy
), or
if
less
than
112
bits
of e
ntro
py, s
alte
d w
ith a
uni
que
and
rand
om 3
2-bi
t sal
t an
d ha
shed
with
an
appr
oved
one
-way
has
h.X
X
V2
Aut
hent
icat
ion
2.6.
3V
erify
that
look
up s
ecre
ts a
re re
sist
ant t
o of
fline
atta
cks,
suc
h as
pre
dict
able
va
lues
.X
X
V2
Aut
hent
icat
ion
2.7.
1
Ver
ify th
at c
lear
text
out
of b
and
(NIS
T "r
estri
cted
") a
uthe
ntic
ator
s, s
uch
as
SM
S o
r PS
TN, a
re n
ot o
ffere
d by
def
ault,
and
stro
nger
alte
rnat
ives
suc
h as
pu
sh n
otifi
catio
ns a
re o
ffere
d fir
st.
XX
X
I bel
ieve
the
2FA
im
plem
enta
tion
uses
S
MS
/E-m
ail t
hat
may
cou
nt a
s ou
t of
band
aut
hent
icat
ion,
so
may
be
appl
icab
le u
nles
s I
am m
ista
ken.
V2
Aut
hent
icat
ion
2.7.
2V
erify
that
the
out o
f ban
d ve
rifie
r exp
ires
out o
f ban
d au
then
ticat
ion
requ
ests
, cod
es, o
r tok
ens
afte
r 10
min
utes
.X
XX
V2
Aut
hent
icat
ion
2.7.
3V
erify
that
the
out o
f ban
d ve
rifie
r aut
hent
icat
ion
requ
ests
, cod
es, o
r tok
ens
are
only
usa
ble
once
, and
onl
y fo
r the
orig
inal
aut
hent
icat
ion
requ
est.
XX
X
V2
Aut
hent
icat
ion
2.7.
4V
erify
that
the
out o
f ban
d au
then
ticat
or a
nd v
erifi
er c
omm
unic
ates
ove
r a
secu
re in
depe
nden
t cha
nnel
.X
XX
V2
Aut
hent
icat
ion
2.7.
5V
erify
that
the
out o
f ban
d ve
rifie
r ret
ains
onl
y a
hash
ed v
ersi
on o
f the
au
then
ticat
ion
code
.X
X
V2
Aut
hent
icat
ion
2.7.
6
Ver
ify th
at th
e in
itial
aut
hent
icat
ion
code
is g
ener
ated
by
a se
cure
rand
om
num
ber g
ener
ator
, con
tain
ing
at le
ast 2
0 bi
ts o
f ent
ropy
(typ
ical
ly a
six
dig
ital
rand
om n
umbe
r is
suffi
cien
t).X
X
V2
Aut
hent
icat
ion
2.8.
1V
erify
that
tim
e-ba
sed
OTP
s ha
ve a
def
ined
life
time
befo
re e
xpiri
ng.
XX
XN
ot s
ure
if th
ey
have
OTP
's
Con
fiden
t the
re is
a
lifet
ime,
but
uns
ure
if th
ere
are
OTP
's.
V2
Aut
hent
icat
ion
2.8.
2
Ver
ify th
at s
ymm
etric
key
s us
ed to
ver
ify s
ubm
itted
OTP
s ar
e hi
ghly
pr
otec
ted,
suc
h as
by
usin
g a
hard
war
e se
curit
y m
odul
e or
sec
ure
oper
atin
g sy
stem
bas
ed k
ey s
tora
ge.
XX
Mos
t of t
ime-
base
d is
re
leva
nt if
goo
gles
2F
U is
use
d.
V2
Aut
hent
icat
ion
2.8.
3V
erify
that
app
rove
d cr
ypto
grap
hic
algo
rithm
s ar
e us
ed in
the
gene
ratio
n,
seed
ing,
and
ver
ifica
tion.
XX
V2
Aut
hent
icat
ion
2.8.
4V
erify
that
tim
e-ba
sed
OTP
can
be
used
onl
y on
ce w
ithin
the
valid
ity p
erio
d.X
X
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79
V2
Aut
hent
icat
ion
2.8.
5
Ver
ify th
at if
a ti
me-
base
d m
ulti
fact
or O
TP to
ken
is re
-use
d du
ring
the
valid
ity
perio
d, it
is lo
gged
and
reje
cted
with
sec
ure
notif
icat
ions
bei
ng s
ent t
o th
e ho
lder
of t
he d
evic
e.X
X
V2
Aut
hent
icat
ion
2.8.
6
Ver
ify p
hysi
cal s
ingl
e fa
ctor
OTP
gen
erat
or c
an b
e re
voke
d in
cas
e of
thef
t or
othe
r los
s. E
nsur
e th
at re
voca
tion
is im
med
iate
ly e
ffect
ive
acro
ss lo
gged
in
sess
ions
, reg
ardl
ess
of lo
catio
n.X
X
V2
Aut
hent
icat
ion
2.8.
7
Ver
ify th
at b
iom
etric
aut
hent
icat
ors
are
limite
d to
use
onl
y as
sec
onda
ry
fact
ors
in c
onju
nctio
n w
ith e
ither
som
ethi
ng y
ou h
ave
and
som
ethi
ng y
ou
know
.o
X
We
don'
t hav
e bi
omet
ric a
uth
yet,
but i
t is
som
ethi
ng
we
are
look
ing
into
an
d w
ill b
ecom
e ap
plic
able
at t
hat
poin
t
Pos
sibl
y fo
r and
roid
ap
p, b
ut th
e pr
imar
y go
al w
ith b
iom
etric
s
is v
erifi
catio
n of
pe
ople
, pat
ient
s et
c.
V2
Aut
hent
icat
ion
2.9.
1
Ver
ify th
at c
rypt
ogra
phic
key
s us
ed in
ver
ifica
tion
are
stor
ed s
ecur
ely
and
prot
ecte
d ag
ains
t dis
clos
ure,
suc
h as
usi
ng a
TP
M o
r HS
M, o
r an
OS
ser
vice
th
at c
an u
se th
is s
ecur
e st
orag
e.X
X
V2
Aut
hent
icat
ion
2.9.
2V
erify
that
the
chal
leng
e no
nce
is a
t lea
st 6
4 bi
ts in
leng
th, a
nd s
tatis
tical
ly
uniq
ue o
r uni
que
over
the
lifet
ime
of th
e cr
ypto
grap
hic
devi
ce.
XX
V2
Aut
hent
icat
ion
2.9.
3V
erify
that
app
rove
d cr
ypto
grap
hic
algo
rithm
s ar
e us
ed in
the
gene
ratio
n,
seed
ing,
and
ver
ifica
tion.
XX
V2
Aut
hent
icat
ion
2.10
.1V
erify
that
inte
grat
ion
secr
ets
do n
ot re
ly o
n un
chan
ging
pas
swor
ds, s
uch
as
AP
I key
s or
sha
red
priv
ilege
d ac
coun
ts.
OS
as
sist
ed
HS
M
V2
Aut
hent
icat
ion
2.10
.2V
erify
that
if p
assw
ords
are
requ
ired,
the
cred
entia
ls a
re n
ot a
def
ault
acco
unt.
OS
as
sist
ed
HS
M
V2
Aut
hent
icat
ion
2.10
.3V
erify
that
pas
swor
ds a
re s
tore
d w
ith s
uffic
ient
pro
tect
ion
to p
reve
nt o
fflin
e re
cove
ry a
ttack
s, in
clud
ing
loca
l sys
tem
acc
ess.
OS
as
sist
ed
HS
M
V2
Aut
hent
icat
ion
2.10
.4
Ver
ify p
assw
ords
, int
egra
tions
with
dat
abas
es a
nd th
ird-p
arty
sys
tem
s, s
eeds
an
d in
tern
al s
ecre
ts, a
nd A
PI k
eys
are
man
aged
sec
urel
y an
d no
t inc
lude
d in
th
e so
urce
cod
e or
sto
red
with
in s
ourc
e co
de re
posi
torie
s. S
uch
stor
age
SH
OU
LD re
sist
offl
ine
atta
cks.
The
use
of a
sec
ure
softw
are
key
stor
e (L
1),
hard
war
e tru
sted
pla
tform
mod
ule
(TP
M),
or a
har
dwar
e se
curit
y m
odul
e (L
3)
is re
com
men
ded
for p
assw
ord
stor
age.
OS
as
sist
ed
HS
M
DH
IS2
core
team
is
resp
onsi
ble
for n
ot
putti
ng c
rede
ntia
ls in
th
e so
urce
cod
e, b
ut
impl
emen
tors
for
secu
rely
sto
ring
the
info
rmat
ion
on th
e se
rver
.P
assw
ords
sto
red
in
sour
ce c
ode.
Hav
e an
ext
erna
l co
nfig
for t
his,
but
im
plem
ento
rs a
re in
ch
arge
of u
sing
it
corr
ectly
.
V3
Ses
sion
3.1.
1V
erify
the
appl
icat
ion
neve
r rev
eals
ses
sion
toke
ns in
UR
L pa
ram
eter
s or
er
ror m
essa
ges.
XX
X
V3
Ses
sion
3.2.
1V
erify
the
appl
icat
ion
gene
rate
s a
new
ses
sion
toke
n on
use
r aut
hent
icat
ion.
[C
6]X
XX
V3
Ses
sion
3.2.
2V
erify
that
ses
sion
toke
ns p
osse
ss a
t lea
st 6
4 bi
ts o
f ent
ropy
. [C
6]X
XX
V3
Ses
sion
3.2.
3
Ver
ify th
e ap
plic
atio
n on
ly s
tore
s se
ssio
n to
kens
in th
e br
owse
r usi
ng s
ecur
e m
etho
ds s
uch
as a
ppro
pria
tely
sec
ured
coo
kies
(see
sec
tion
3.4)
or H
TML
5 se
ssio
n st
orag
e.X
XX
Sam
eSite
coo
kies
ne
ed to
be
enab
led
on th
e ng
inx
conf
igur
atio
n
V3
Ses
sion
3.2.
4V
erify
that
ses
sion
toke
n ar
e ge
nera
ted
usin
g ap
prov
ed c
rypt
ogra
phic
al
gorit
hms.
[C6]
XX
V3
Ses
sion
3.3.
1
Ver
ify th
at lo
gout
and
exp
iratio
n in
valid
ate
the
sess
ion
toke
n, s
uch
that
the
back
but
ton
or a
dow
nstre
am re
lyin
g pa
rty d
oes
not r
esum
e an
aut
hent
icat
ed
sess
ion,
incl
udin
g ac
ross
rely
ing
parti
es. [
C6]
XX
X
V3
Ses
sion
3.3.
2If
auth
entic
ator
s pe
rmit
user
s to
rem
ain
logg
ed in
, ver
ify th
at re
-aut
hent
icat
ion
occu
rs p
erio
dica
lly b
oth
whe
n ac
tivel
y us
ed o
r afte
r an
idle
per
iod.
[C6]
30 d
ays12
ho
urs
or 3
0 m
inut
es
of
inac
tivit
y, 2
FA
optio
nal
12
hour
s or
15
m
inut
es o
f in
acti
vity
, w
ith
2FA
DH
IS2
has
a m
echa
nism
for
dete
ctin
g if
its o
nlin
e or
not
. Is
used
to
send
per
iodi
c pi
ngs,
so
the
clie
nt w
ould
kn
ow if
onl
ine
or n
ot.
The
prob
lem
was
that
th
e us
er w
as n
ever
of
fline
, was
alw
ays
logg
ed in
. The
def
ault
is 1
hou
r. B
anki
ng is
10
min
utes
.
V3
Ses
sion
3.3.
3
Ver
ify th
at th
e ap
plic
atio
n te
rmin
ates
all
othe
r act
ive
sess
ions
afte
r a
succ
essf
ul p
assw
ord
chan
ge, a
nd th
at th
is is
effe
ctiv
e ac
ross
the
appl
icat
ion,
fe
dera
ted
logi
n (if
pre
sent
), an
d an
y re
lyin
g pa
rties
.X
X
V3
Ses
sion
3.3.
4V
erify
that
use
rs a
re a
ble
to v
iew
and
log
out o
f any
or a
ll cu
rren
tly a
ctiv
e se
ssio
ns a
nd d
evic
es.
XX
V3
Ses
sion
3.4.
1V
erify
that
coo
kie-
base
d se
ssio
n to
kens
hav
e th
e 'S
ecur
e' a
ttrib
ute
set.
[C6]
XX
X
Do
it on
the
impl
emen
tatio
n si
de
with
the
web
pro
xy.
Dev
elop
ers
wan
t to
run
it w
ithou
t HTT
PS
. V
3S
essi
on3.
4.2
Ver
ify th
at c
ooki
e-ba
sed
sess
ion
toke
ns h
ave
the
'Http
Onl
y' a
ttrib
ute
set.
[C6]
XX
X
V3
Ses
sion
3.4.
3V
erify
that
coo
kie-
base
d se
ssio
n to
kens
util
ize
the
'Sam
eSite
' attr
ibut
e to
lim
it ex
posu
re to
cro
ss-s
ite re
ques
t for
gery
atta
cks.
[C6]
XX
X
This
is n
ot p
art o
f th
e Ja
va S
ervl
et
spec
s, s
o ne
eds
to
be c
onfig
ured
th
roug
h ng
inx
(see
m
106)
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79
V3
Ses
sion
3.4.
4V
erify
that
coo
kie-
base
d se
ssio
n to
kens
use
"__H
ost-"
pre
fix (s
ee re
fere
nces
) to
pro
vide
ses
sion
coo
kie
conf
iden
tialit
y.X
XX
V3
Ses
sion
3.4.
5
Ver
ify th
at if
the
appl
icat
ion
is p
ublis
hed
unde
r a d
omai
n na
me
with
oth
er
appl
icat
ions
that
set
or u
se s
essi
on c
ooki
es th
at m
ight
ove
rrid
e or
dis
clos
e th
e se
ssio
n co
okie
s, s
et th
e pa
th a
ttrib
ute
in c
ooki
e-ba
sed
sess
ion
toke
ns
usin
g th
e m
ost p
reci
se p
ath
poss
ible
. [C
6]X
XX
Pos
sibl
y im
plem
enta
tion.
Th
e im
pelm
ento
rs
mus
t con
figur
e do
mai
ns, n
etw
ork
aspe
cts.
V3
Ses
sion
3.5.
1
Ver
ify th
e ap
plic
atio
n do
es n
ot tr
eat O
Aut
h an
d re
fresh
toke
ns &
mda
sh; o
n th
eir o
wn
&m
dash
; as
the
pres
ence
of t
he s
ubsc
riber
and
allo
ws
user
s to
te
rmin
ate
trust
rela
tions
hips
with
link
ed a
pplic
atio
ns.
XX
V3
Ses
sion
3.5.
2V
erify
the
appl
icat
ion
uses
ses
sion
toke
ns ra
ther
than
sta
tic A
PI s
ecre
ts a
nd
keys
, exc
ept w
ith le
gacy
impl
emen
tatio
ns.
XX
V3
Ses
sion
3.5.
3
Ver
ify th
at s
tate
less
ses
sion
toke
ns u
se d
igita
l sig
natu
res,
enc
rypt
ion,
and
ot
her c
ount
erm
easu
res
to p
rote
ct a
gain
st ta
mpe
ring,
env
elop
ing,
repl
ay, n
ull
ciph
er, a
nd k
ey s
ubst
itutio
n at
tack
s.X
X
Not
app
licab
le ri
ght
now
, but
we
are
wor
king
on
stat
eles
s se
ssio
n to
kens
, so
it w
ill b
e at
som
e po
int.
V3
Ses
sion
3.6.
1
Ver
ify th
at re
lyin
g pa
rties
spe
cify
the
max
imum
aut
hent
icat
ion
time
to C
SP
s an
d th
at C
SP
s re
-aut
hent
icat
e th
e su
bscr
iber
if th
ey h
aven
't us
ed a
ses
sion
w
ithin
that
per
iod.
X
V3
Ses
sion
3.6.
2V
erify
that
CS
Ps
info
rm re
lyin
g pa
rties
of t
he la
st a
uthe
ntic
atio
n ev
ent,
to
allo
w R
Ps
to d
eter
min
e if
they
nee
d to
re-a
uthe
ntic
ate
the
user
.X
V3
Ses
sion
3.7.
1
Ver
ify th
e ap
plic
atio
n en
sure
s a
valid
logi
n se
ssio
n or
requ
ires
re-
auth
entic
atio
n or
sec
onda
ry v
erifi
catio
n be
fore
allo
win
g an
y se
nsiti
ve
trans
actio
ns o
r acc
ount
mod
ifica
tions
.X
XX
V4
Acc
ess
4.1.
1
Ver
ify th
at th
e ap
plic
atio
n en
forc
es a
cces
s co
ntro
l rul
es o
n a
trust
ed s
ervi
ce
laye
r, es
peci
ally
if c
lient
-sid
e ac
cess
con
trol i
s pr
esen
t and
cou
ld b
e by
pass
ed.
XX
X
V4
Acc
ess
4.1.
2V
erify
that
all
user
and
dat
a at
tribu
tes
and
polic
y in
form
atio
n us
ed b
y ac
cess
co
ntro
ls c
anno
t be
man
ipul
ated
by
end
user
s un
less
spe
cific
ally
aut
horiz
ed.
XX
X
V4
Acc
ess
4.1.
3
Ver
ify th
at th
e pr
inci
ple
of le
ast p
rivile
ge e
xist
s - u
sers
sho
uld
only
be
able
to
acce
ss fu
nctio
ns, d
ata
files
, UR
Ls, c
ontro
llers
, ser
vice
s, a
nd o
ther
reso
urce
s,
for w
hich
they
pos
sess
spe
cific
aut
horiz
atio
n. T
his
impl
ies
prot
ectio
n ag
ains
t sp
oofin
g an
d el
evat
ion
of p
rivile
ge. [
C7]
XX
X
Dep
ends
on
how
yo
u de
fine
your
ro
les
and
priv
lidge
s. M
ostly
ap
plic
atio
n.
V4
Acc
ess
4.1.
4
Ver
ify th
at th
e pr
inci
ple
of d
eny
by d
efau
lt ex
ists
whe
reby
new
use
rs/ro
les
star
t with
min
imal
or n
o pe
rmis
sion
s an
d us
ers/
role
s do
not
rece
ive
acce
ss to
ne
w fe
atur
es u
ntil
acce
ss is
exp
licitl
y as
sign
ed. [
C7]
XX
X
V4
Acc
ess
4.1.
5V
erify
that
acc
ess
cont
rols
fail
secu
rely
incl
udin
g w
hen
an e
xcep
tion
occu
rs.
[C10
]X
XX
V4
Acc
ess
4.2.
1
Ver
ify th
at s
ensi
tive
data
and
AP
Is a
re p
rote
cted
aga
inst
dire
ct o
bjec
t atta
cks
targ
etin
g cr
eatio
n, re
adin
g, u
pdat
ing
and
dele
tion
of re
cord
s, s
uch
as c
reat
ing
or u
pdat
ing
som
eone
els
e's
reco
rd, v
iew
ing
ever
yone
's re
cord
s, o
r del
etin
g al
l rec
ords
.X
XX
V4
Acc
ess
4.2.
2
Ver
ify th
at th
e ap
plic
atio
n or
fram
ewor
k en
forc
es a
stro
ng a
nti-C
SR
F m
echa
nism
to p
rote
ct a
uthe
ntic
ated
func
tiona
lity,
and
effe
ctiv
e an
ti-au
tom
atio
n or
ant
i-CS
RF
prot
ects
una
uthe
ntic
ated
func
tiona
lity.
XX
X
Con
trove
rsia
l: th
e st
anda
rd p
rote
ctio
n is
to
use
non
se to
kens
. N
ot im
plem
ente
d in
D
HIS
2, fo
r a v
arie
ty
of le
gact
y re
ason
s an
d du
e to
how
the
AP
I is
used
. Onl
y pr
otec
tion
is s
erve
r-si
de c
ooki
es,
curr
ently
. Wan
ts
serv
er-s
ide
cook
ie to
be
on
defa
ult
V4
Acc
ess
4.3.
1V
erify
adm
inis
trativ
e in
terfa
ces
use
appr
opria
te m
ulti-
fact
or a
uthe
ntic
atio
n to
pr
even
t una
utho
rized
use
.X
XX
We
dont
enf
orce
m
ulti-
fact
or, b
ut w
e m
ake
it av
aila
ble.
Des
ign
choi
ce
V4
Acc
ess
4.3.
2
Ver
ify th
at d
irect
ory
brow
sing
is d
isab
led
unle
ss d
elib
erat
ely
desi
red.
A
dditi
onal
ly, a
pplic
atio
ns s
houl
d no
t allo
w d
isco
very
or d
iscl
osur
e of
file
or
dire
ctor
y m
etad
ata,
suc
h as
Thu
mbs
.db,
.DS
_Sto
re, .
git o
r .sv
n fo
lder
s.X
XX
Dep
ends
on
how
you
se
t up
your
apa
che
serv
er
V4
Acc
ess
4.3.
3
Ver
ify th
e ap
plic
atio
n ha
s ad
ditio
nal a
utho
rizat
ion
(suc
h as
ste
p up
or
adap
tive
auth
entic
atio
n) fo
r low
er v
alue
sys
tem
s, a
nd /
or s
egre
gatio
n of
du
ties
for h
igh
valu
e ap
plic
atio
ns to
enf
orce
ant
i-fra
ud c
ontro
ls a
s pe
r the
risk
of
app
licat
ion
and
past
frau
d.X
X
V5
Val
idat
ion
5.1.
1
Ver
ify th
at th
e ap
plic
atio
n ha
s de
fens
es a
gain
st H
TTP
par
amet
er p
ollu
tion
atta
cks,
par
ticul
arly
if th
e ap
plic
atio
n fra
mew
ork
mak
es n
o di
stin
ctio
n ab
out
the
sour
ce o
f req
uest
par
amet
ers
(GE
T, P
OS
T, c
ooki
es, h
eade
rs, o
r en
viro
nmen
t var
iabl
es).
XX
X
V5
Val
idat
ion
5.1.
2
Ver
ify th
at fr
amew
orks
pro
tect
aga
inst
mas
s pa
ram
eter
ass
ignm
ent a
ttack
s,
or th
at th
e ap
plic
atio
n ha
s co
unte
rmea
sure
s to
pro
tect
aga
inst
uns
afe
para
met
er a
ssig
nmen
t, su
ch a
s m
arki
ng fi
elds
priv
ate
or s
imila
r. [C
5]X
XX
V5
Val
idat
ion
5.1.
3
Ver
ify th
at a
ll in
put (
HTM
L fo
rm fi
elds
, RE
ST
requ
ests
, UR
L pa
ram
eter
s,
HTT
P h
eade
rs, c
ooki
es, b
atch
file
s, R
SS
feed
s, e
tc) i
s va
lidat
ed u
sing
po
sitiv
e va
lidat
ion
(whi
telis
ting)
. [C
5]X
XX
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79
V5
Val
idat
ion
5.1.
4
Ver
ify th
at s
truct
ured
dat
a is
stro
ngly
type
d an
d va
lidat
ed a
gain
st a
def
ined
sc
hem
a in
clud
ing
allo
wed
cha
ract
ers,
leng
th a
nd p
atte
rn (e
.g. c
redi
t car
d nu
mbe
rs o
r tel
epho
ne, o
r val
idat
ing
that
two
rela
ted
field
s ar
e re
ason
able
, su
ch a
s ch
ecki
ng th
at s
ubur
b an
d zi
p/po
stco
de m
atch
). [C
5]X
XX
V5
Val
idat
ion
5.1.
5V
erify
that
UR
L re
dire
cts
and
forw
ards
onl
y al
low
whi
telis
ted
dest
inat
ions
, or
show
a w
arni
ng w
hen
redi
rect
ing
to p
oten
tially
unt
rust
ed c
onte
nt.
XX
X
V5
Val
idat
ion
5.2.
1V
erify
that
all
untru
sted
HTM
L in
put f
rom
WY
SIW
YG
edi
tors
or s
imila
r is
prop
erly
san
itize
d w
ith a
n H
TML
sani
tizer
libr
ary
or fr
amew
ork
feat
ure.
[C5]
XX
X
Cur
rent
ly a
pro
blem
. A
feat
ure
calle
d In
terp
reta
tions
, whi
ch
has
a ric
h te
xt e
dito
r w
here
peo
ple
can
writ
e an
ythi
ng. H
as
been
a p
robl
em w
ith
XS
S b
efor
e, d
ue to
sa
tinaz
ing.
V5
Val
idat
ion
5.2.
2V
erify
that
uns
truct
ured
dat
a is
san
itize
d to
enf
orce
saf
ety
mea
sure
s su
ch a
s al
low
ed c
hara
cter
s an
d le
ngth
.X
XX
V5
Val
idat
ion
5.2.
3V
erify
that
the
appl
icat
ion
sani
tizes
use
r inp
ut b
efor
e pa
ssin
g to
mai
l sys
tem
s to
pro
tect
aga
inst
SM
TP o
r IM
AP
inje
ctio
n.X
XX
V5
Val
idat
ion
5.2.
4
Ver
ify th
at th
e ap
plic
atio
n av
oids
the
use
of e
val()
or o
ther
dyn
amic
cod
e ex
ecut
ion
feat
ures
. Whe
re th
ere
is n
o al
tern
ativ
e, a
ny u
ser i
nput
bei
ng
incl
uded
mus
t be
sani
tized
or s
andb
oxed
bef
ore
bein
g ex
ecut
ed.
XX
X
V5
Val
idat
ion
5.2.
5V
erify
that
the
appl
icat
ion
prot
ects
aga
inst
tem
plat
e in
ject
ion
atta
cks
by
ensu
ring
that
any
use
r inp
ut b
eing
incl
uded
is s
aniti
zed
or s
andb
oxed
.X
XX
V5
Val
idat
ion
5.2.
6
Ver
ify th
at th
e ap
plic
atio
n pr
otec
ts a
gain
st S
SR
F at
tack
s, b
y va
lidat
ing
or
sani
tizin
g un
trust
ed d
ata
or H
TTP
file
met
adat
a, s
uch
as fi
lena
mes
and
UR
L in
put f
ield
s, u
se w
hite
listin
g of
pro
toco
ls, d
omai
ns, p
aths
and
por
ts.
XX
X
V5
Val
idat
ion
5.2.
7
Ver
ify th
at th
e ap
plic
atio
n sa
nitiz
es, d
isab
les,
or s
andb
oxes
use
r-su
pplie
d S
VG
scr
ipta
ble
cont
ent,
espe
cial
ly a
s th
ey re
late
to X
SS
resu
lting
from
inlin
e sc
ripts
, and
fore
ignO
bjec
t.X
XX
V5
Val
idat
ion
5.2.
8
Ver
ify th
at th
e ap
plic
atio
n sa
nitiz
es, d
isab
les,
or s
andb
oxes
use
r-su
pplie
d sc
ripta
ble
or e
xpre
ssio
n te
mpl
ate
lang
uage
con
tent
, suc
h as
Mar
kdow
n, C
SS
or
XS
L st
yles
heet
s, B
BC
ode,
or s
imila
r.X
XX
V5
Val
idat
ion
5.3.
1
Ver
ify th
at o
utpu
t enc
odin
g is
rele
vant
for t
he in
terp
rete
r and
con
text
requ
ired.
Fo
r exa
mpl
e, u
se e
ncod
ers
spec
ifica
lly fo
r HTM
L va
lues
, HTM
L at
tribu
tes,
Ja
vaS
crip
t, U
RL
Par
amet
ers,
HTT
P h
eade
rs, S
MTP
, and
oth
ers
as th
e co
ntex
t req
uire
s, e
spec
ially
from
unt
rust
ed in
puts
(e.g
. nam
es w
ith U
nico
de
or a
post
roph
es, s
uch
as ね
こ o
r O'H
ara)
. [C
4]X
XX
V5
Val
idat
ion
5.3.
2V
erify
that
out
put e
ncod
ing
pres
erve
s th
e us
er's
cho
sen
char
acte
r set
and
lo
cale
, suc
h th
at a
ny U
nico
de c
hara
cter
poi
nt is
val
id a
nd s
afel
y ha
ndle
d. [C
4]X
XX
V5
Val
idat
ion
5.3.
3V
erify
that
con
text
-aw
are,
pre
fera
bly
auto
mat
ed -
or a
t wor
st, m
anua
l - o
utpu
t es
capi
ng p
rote
cts
agai
nst r
efle
cted
, sto
red,
and
DO
M b
ased
XS
S. [
C4]
XX
X
V5
Val
idat
ion
5.3.
4
Ver
ify th
at d
ata
sele
ctio
n or
dat
abas
e qu
erie
s (e
.g. S
QL,
HQ
L, O
RM
, NoS
QL)
us
e pa
ram
eter
ized
que
ries,
OR
Ms,
ent
ity fr
amew
orks
, or a
re o
ther
wis
e pr
otec
ted
from
dat
abas
e in
ject
ion
atta
cks.
[C3]
XX
X
V5
Val
idat
ion
5.3.
5
Ver
ify th
at w
here
par
amet
eriz
ed o
r saf
er m
echa
nism
s ar
e no
t pre
sent
, co
ntex
t-spe
cific
out
put e
ncod
ing
is u
sed
to p
rote
ct a
gain
st in
ject
ion
atta
cks,
su
ch a
s th
e us
e of
SQ
L es
capi
ng to
pro
tect
aga
inst
SQ
L in
ject
ion.
[C3,
C4]
XX
X
V5
Val
idat
ion
5.3.
6
Ver
ify th
at th
e ap
plic
atio
n pr
ojec
ts a
gain
st J
avaS
crip
t or J
SO
N in
ject
ion
atta
cks,
incl
udin
g fo
r eva
l atta
cks,
rem
ote
Java
Scr
ipt i
nclu
des,
CS
P
bypa
sses
, DO
M X
SS
, and
Jav
aScr
ipt e
xpre
ssio
n ev
alua
tion.
[C4]
XX
X
V5
Val
idat
ion
5.3.
7
Ver
ify th
at th
e ap
plic
atio
n pr
otec
ts a
gain
st L
DA
P In
ject
ion
vuln
erab
ilitie
s, o
r th
at s
peci
fic s
ecur
ity c
ontro
ls to
pre
vent
LD
AP
Inje
ctio
n ha
ve b
een
impl
emen
ted.
[C4]
XX
X
V5
Val
idat
ion
5.3.
8
Ver
ify th
at th
e ap
plic
atio
n pr
otec
ts a
gain
st O
S c
omm
and
inje
ctio
n an
d th
at
oper
atin
g sy
stem
cal
ls u
se p
aram
eter
ized
OS
que
ries
or u
se c
onte
xtua
l co
mm
and
line
outp
ut e
ncod
ing.
[C4]
XX
X
We
do n
ot u
se
stra
ight
sys
calls
to
the
OS
and
rely
on
the
JVM
to d
o so
, un
sure
if w
e sh
ould
ha
ndle
kno
wn
sysc
alls
sec
urity
ris
ks b
etw
een
the
JVM
and
OS
.
V5
Val
idat
ion
5.3.
9V
erify
that
the
appl
icat
ion
prot
ects
aga
inst
Loc
al F
ile In
clus
ion
(LFI
) or
Rem
ote
File
Incl
usio
n (R
FI) a
ttack
s.X
XX
V5
Val
idat
ion
5.3.
10V
erify
that
the
appl
icat
ion
prot
ects
aga
inst
XP
ath
inje
ctio
n or
XM
L in
ject
ion
atta
cks.
[C4]
XX
X
V5
Val
idat
ion
5.4.
1V
erify
that
the
appl
icat
ion
uses
mem
ory-
safe
stri
ng, s
afer
mem
ory
copy
and
po
inte
r arit
hmet
ic to
det
ect o
r pre
vent
sta
ck, b
uffe
r, or
hea
p ov
erflo
ws.
XX
Ass
umin
g no
rmal
us
e of
Jav
a th
is
shou
ld b
e an
eas
y pa
ss, t
houg
h cu
stom
S
tring
Buf
fer
impl
emen
tatio
ns
coul
d ca
use
JVM
he
ap s
ize
issu
es.
Not
a p
robl
em w
ith
Java
V5
Val
idat
ion
5.4.
2V
erify
that
form
at s
tring
s do
not
take
pot
entia
lly h
ostil
e in
put,
and
are
cons
tant
.X
X
V5
Val
idat
ion
5.4.
3V
erify
that
sig
n, ra
nge,
and
inpu
t val
idat
ion
tech
niqu
es a
re u
sed
to p
reve
nt
inte
ger o
verfl
ows.
XX
Not
a ja
va is
sue
Pos
sibl
y no
t rel
evan
t for
Jav
a.
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79
V5
Val
idat
ion
5.5.
1V
erify
that
ser
ializ
ed o
bjec
ts u
se in
tegr
ity c
heck
s or
are
enc
rypt
ed to
pre
vent
ho
stile
obj
ect c
reat
ion
or d
ata
tam
perin
g. [C
5]X
XX
V5
Val
idat
ion
5.5.
2
Ver
ify th
at th
e ap
plic
atio
n co
rrec
tly re
stric
ts X
ML
pars
ers
to o
nly
use
the
mos
t re
stric
tive
conf
igur
atio
n po
ssib
le a
nd to
ens
ure
that
uns
afe
feat
ures
suc
h as
re
solv
ing
exte
rnal
ent
ities
are
dis
able
d to
pre
vent
XX
E.
XX
X
Had
pro
blem
with
X
XE
ent
ity in
ject
ion
befo
re.
V5
Val
idat
ion
5.5.
3
Ver
ify th
at d
eser
ializ
atio
n of
unt
rust
ed d
ata
is a
void
ed o
r is
prot
ecte
d in
bot
h cu
stom
cod
e an
d th
ird-p
arty
libr
arie
s (s
uch
as J
SO
N, X
ML
and
YA
ML
pars
ers)
.X
XX
All
that
is u
ser
supp
lied,
so
in th
at
sens
e it
is tr
uste
d si
nce
user
s ne
ed to
lo
g in
V5
Val
idat
ion
5.5.
4
Ver
ify th
at w
hen
pars
ing
JSO
N in
bro
wse
rs o
r Jav
aScr
ipt-b
ased
bac
kend
s,
JSO
N.p
arse
is u
sed
to p
arse
the
JSO
N d
ocum
ent.
Do
not u
se e
val()
to p
arse
JS
ON
.X
XX
Rel
evan
t for
the
App
S
tore
bac
kend
.
V6
Cry
ptog
raph
y6.
1.1
Ver
ify th
at re
gula
ted
priv
ate
data
is s
tore
d en
cryp
ted
whi
le a
t res
t, su
ch a
s pe
rson
ally
iden
tifia
ble
info
rmat
ion
(PII)
, sen
sitiv
e pe
rson
al in
form
atio
n, o
r da
ta a
sses
sed
likel
y to
be
subj
ect t
o E
U's
GD
PR
.X
X
Reo
mm
ende
d to
m
ake
sure
the
data
base
is o
n an
en
cryp
ted
disk
V6
Cry
ptog
raph
y6.
1.2
Ver
ify th
at re
gula
ted
heal
th d
ata
is s
tore
d en
cryp
ted
whi
le a
t res
t, su
ch a
s m
edic
al re
cord
s, m
edic
al d
evic
e de
tails
, or d
e-an
onym
ized
rese
arch
reco
rds.
XX
Cou
ld b
e re
leva
nt fo
r Tr
acke
r
V6
Cry
ptog
raph
y6.
1.3
Ver
ify th
at re
gula
ted
finan
cial
dat
a is
sto
red
encr
ypte
d w
hile
at r
est,
such
as
finan
cial
acc
ount
s, d
efau
lts o
r cre
dit h
isto
ry, t
ax re
cord
s, p
ay h
isto
ry,
bene
ficia
ries,
or d
e-an
onym
ized
mar
ket o
r res
earc
h re
cord
s.X
XD
ont d
eal w
ith
finan
cial
dat
a.
Don
't w
ork
with
just
he
alth
dat
a, c
an b
e ot
her f
orm
s of
dat
a.
Impl
emen
tatio
n is
sue
V6
Cry
ptog
raph
y6.
2.1
Ver
ify th
at a
ll cr
ypto
grap
hic
mod
ules
fail
secu
rely
, and
err
ors
are
hand
led
in a
w
ay th
at d
oes
not e
nabl
e P
addi
ng O
racl
e at
tack
s.X
XX
V6
Cry
ptog
raph
y6.
2.2
Ver
ify th
at in
dust
ry p
rove
n or
gov
ernm
ent a
ppro
ved
cryp
togr
aphi
c al
gorit
hms,
m
odes
, and
libr
arie
s ar
e us
ed, i
nste
ad o
f cus
tom
cod
ed c
rypt
ogra
phy.
[C8]
XX
V6
Cry
ptog
raph
y6.
2.3
Ver
ify th
at e
ncry
ptio
n in
itial
izat
ion
vect
or, c
iphe
r con
figur
atio
n, a
nd b
lock
m
odes
are
con
figur
ed s
ecur
ely
usin
g th
e la
test
adv
ice.
XX
V6
Cry
ptog
raph
y6.
2.4
Ver
ify th
at ra
ndom
num
ber,
encr
yptio
n or
has
hing
alg
orith
ms,
key
leng
ths,
ro
unds
, cip
hers
or m
odes
, can
be
reco
nfig
ured
, upg
rade
d, o
r sw
appe
d at
any
tim
e, to
pro
tect
aga
inst
cry
ptog
raph
ic b
reak
s. [C
8]X
XH
ave
the
abili
ty to
re
conf
igur
e an
d sw
ap
V6
Cry
ptog
raph
y6.
2.5
Ver
ify th
at k
now
n in
secu
re b
lock
mod
es (i
.e. E
CB
, etc
.), p
addi
ng m
odes
(i.e
. P
KC
S#1
v1.
5, e
tc.),
cip
hers
with
sm
all b
lock
siz
es (i
.e. T
riple
-DE
S, B
low
fish,
et
c.),
and
wea
k ha
shin
g al
gorit
hms
(i.e.
MD
5, S
HA
1, e
tc.)
are
not u
sed
unle
ss re
quire
d fo
r bac
kwar
ds c
ompa
tibili
ty.
XX
V6
Cry
ptog
raph
y6.
2.6
Ver
ify th
at n
once
s, in
itial
izat
ion
vect
ors,
and
oth
er s
ingl
e us
e nu
mbe
rs m
ust
not b
e us
ed m
ore
than
onc
e w
ith a
giv
en e
ncry
ptio
n ke
y. T
he m
etho
d of
ge
nera
tion
mus
t be
appr
opria
te fo
r the
alg
orith
m b
eing
use
d.X
X
V6
Cry
ptog
raph
y6.
2.7
Ver
ify th
at e
ncry
pted
dat
a is
aut
hent
icat
ed v
ia s
igna
ture
s, a
uthe
ntic
ated
ci
pher
mod
es, o
r HM
AC
to e
nsur
e th
at c
iphe
rtext
is n
ot a
ltere
d by
an
unau
thor
ized
par
ty.
X
Don
t do
digi
tal
sign
atur
es. D
ont d
o a
lot o
f enc
rypt
ion
insi
de D
HIS
.
V6
Cry
ptog
raph
y6.
2.8
Ver
ify th
at a
ll cr
ypto
grap
hic
oper
atio
ns a
re c
onst
ant-t
ime,
with
no
'sho
rt-ci
rcui
t' op
erat
ions
in c
ompa
rison
s, c
alcu
latio
ns, o
r ret
urns
, to
avoi
d le
akin
g in
form
atio
n.X
V6
Cry
ptog
raph
y6.
3.1
Ver
ify th
at a
ll ra
ndom
num
bers
, ran
dom
file
nam
es, r
ando
m G
UID
s, a
nd
rand
om s
tring
s ar
e ge
nera
ted
usin
g th
e cr
ypto
grap
hic
mod
ule'
s ap
prov
ed
cryp
togr
aphi
cally
sec
ure
rand
om n
umbe
r gen
erat
or w
hen
thes
e ra
ndom
va
lues
are
inte
nded
to b
e no
t gue
ssab
le b
y an
atta
cker
.X
X
V6
Cry
ptog
raph
y6.
3.2
Ver
ify th
at ra
ndom
GU
IDs
are
crea
ted
usin
g th
e G
UID
v4
algo
rithm
, and
a
cryp
togr
aphi
cally
-sec
ure
pseu
do-r
ando
m n
umbe
r gen
erat
or (C
SP
RN
G).
GU
IDs
crea
ted
usin
g ot
her p
seud
o-ra
ndom
num
ber g
ener
ator
s m
ay b
e pr
edic
tabl
e.X
X
V6
Cry
ptog
raph
y6.
3.3
Ver
ify th
at ra
ndom
num
bers
are
cre
ated
with
pro
per e
ntro
py e
ven
whe
n th
e ap
plic
atio
n is
und
er h
eavy
load
, or t
hat t
he a
pplic
atio
n de
grad
es g
race
fully
in
such
circ
umst
ance
s.X
V6
Cry
ptog
raph
y6.
4.1
Ver
ify th
at a
sec
rets
man
agem
ent s
olut
ion
such
as
a ke
y va
ult i
s us
ed to
se
cure
ly c
reat
e, s
tore
, con
trol a
cces
s to
and
des
troy
secr
ets.
[C8]
XX
V6
Cry
ptog
raph
y6.
4.2
Ver
ify th
at k
ey m
ater
ial i
s no
t exp
osed
to th
e ap
plic
atio
n bu
t ins
tead
use
s an
is
olat
ed s
ecur
ity m
odul
e lik
e a
vaul
t for
cry
ptog
raph
ic o
pera
tions
. [C
8]X
X
We
dont
do
a lo
t of
cryp
togr
ahpi
cs in
side
th
e D
HIS
2 its
elf.
A
bit.
Impl
emen
tatio
n is
sue.
D
on't
use
keys
.
V7
Err
or7.
1.1
Ver
ify th
at th
e ap
plic
atio
n do
es n
ot lo
g cr
eden
tials
or p
aym
ent d
etai
ls.
Ses
sion
toke
ns s
houl
d on
ly b
e st
ored
in lo
gs in
an
irrev
ersi
ble,
has
hed
form
. [C
9, C
10]
XX
X
V7
Err
or7.
1.2
Ver
ify th
at th
e ap
plic
atio
n do
es n
ot lo
g ot
her s
ensi
tive
data
as
defin
ed u
nder
lo
cal p
rivac
y la
ws
or re
leva
nt s
ecur
ity p
olic
y. [C
9]X
XX
Impl
emen
ted
to s
uit
Nor
weg
ian
law
s, n
ot
inte
rnat
iona
l.
V7
Err
or7.
1.3
Ver
ify th
at th
e ap
plic
atio
n lo
gs s
ecur
ity re
leva
nt e
vent
s in
clud
ing
succ
essf
ul
and
faile
d au
then
ticat
ion
even
ts, a
cces
s co
ntro
l fai
lure
s, d
eser
ializ
atio
n fa
ilure
s an
d in
put v
alid
atio
n fa
ilure
s. [C
5, C
7]X
X
V7
Err
or7.
1.4
Ver
ify th
at e
ach
log
even
t inc
lude
s ne
cess
ary
info
rmat
ion
that
wou
ld a
llow
for
a de
taile
d in
vest
igat
ion
of th
e tim
elin
e w
hen
an e
vent
hap
pens
. [C
9]X
X
V7
Err
or7.
2.1
Ver
ify th
at a
ll au
then
ticat
ion
deci
sion
s ar
e lo
gged
, with
out s
torin
g se
nsiti
ve
sess
ion
iden
tifie
rs o
r pas
swor
ds. T
his
shou
ld in
clud
e re
ques
ts w
ith re
leva
nt
met
adat
a ne
eded
for s
ecur
ity in
vest
igat
ions
.X
X
V7
Err
or7.
2.2
Ver
ify th
at a
ll ac
cess
con
trol d
ecis
ions
can
be
logg
ed a
nd a
ll fa
iled
deci
sion
s ar
e lo
gged
. Thi
s sh
ould
incl
ude
requ
ests
with
rele
vant
met
adat
a ne
eded
for
secu
rity
inve
stig
atio
ns.
XX
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79
V7
Err
or7.
3.1
Ver
ify th
at th
e ap
plic
atio
n ap
prop
riate
ly e
ncod
es u
ser-
supp
lied
data
to
prev
ent l
og in
ject
ion.
[C9]
XX
V7
Err
or7.
3.2
Ver
ify th
at a
ll ev
ents
are
pro
tect
ed fr
om in
ject
ion
whe
n vi
ewed
in lo
g vi
ewin
g so
ftwar
e. [C
9]X
X
V7
Err
or7.
3.3
Ver
ify th
at s
ecur
ity lo
gs a
re p
rote
cted
from
una
utho
rized
acc
ess
and
mod
ifica
tion.
[C9]
XX
V7
Err
or7.
3.4
Ver
ify th
at ti
me
sour
ces
are
sync
hron
ized
to th
e co
rrec
t tim
e an
d tim
e zo
ne.
Stro
ngly
con
side
r log
ging
onl
y in
UTC
if s
yste
ms
are
glob
al to
ass
ist w
ith
post
-inci
dent
fore
nsic
ana
lysi
s. [C
9]X
X
The
appl
icat
ion
in
our c
ase
shou
ld lo
g in
UTC
, as
the
serv
er ti
me
sync
is
out o
f our
con
trol,
whi
ch m
oves
this
to
the
impl
emen
tors
si
de if
we
do n
ot lo
g in
UTC
V7
Err
or7.
4.1
Ver
ify th
at a
gen
eric
mes
sage
is s
how
n w
hen
an u
nexp
ecte
d or
sec
urity
se
nsiti
ve e
rror
occ
urs,
pot
entia
lly w
ith a
uni
que
ID w
hich
sup
port
pers
onne
l ca
n us
e to
inve
stig
ate.
[C
10]
XX
X
V7
Err
or7.
4.2
Ver
ify th
at e
xcep
tion
hand
ling
(or a
func
tiona
l equ
ival
ent)
is u
sed
acro
ss th
e co
deba
se to
acc
ount
for e
xpec
ted
and
unex
pect
ed e
rror
con
ditio
ns. [
C10
]X
X
V7
Err
or7.
4.3
Ver
ify th
at a
"las
t res
ort"
erro
r han
dler
is d
efin
ed w
hich
will
cat
ch a
ll un
hand
led
exce
ptio
ns. [
C10
]X
X
V8
Dat
a8.
1.1
Ver
ify th
e ap
plic
atio
n pr
otec
ts s
ensi
tive
data
from
bei
ng c
ache
d in
ser
ver
com
pone
nts
such
as
load
bal
ance
rs a
nd a
pplic
atio
n ca
ches
.X
X
An
impl
emen
tatio
n re
spon
sibi
lity
also
. D
on't
have
a w
ay to
sp
ecify
thin
gs a
s se
nsiti
ve.
V8
Dat
a8.
1.2
Ver
ify th
at a
ll ca
ched
or t
empo
rary
cop
ies
of s
ensi
tive
data
sto
red
on th
e se
rver
are
pro
tect
ed fr
om u
naut
horiz
ed a
cces
s or
pur
ged/
inva
lidat
ed a
fter t
he
auth
oriz
ed u
ser a
cces
ses
the
sens
itive
dat
a.X
X
V8
Dat
a8.
1.3
Ver
ify th
e ap
plic
atio
n m
inim
izes
the
num
ber o
f par
amet
ers
in a
requ
est,
such
as
hid
den
field
s, A
jax
varia
bles
, coo
kies
and
hea
der v
alue
s.X
X
V8
Dat
a8.
1.4
Ver
ify th
e ap
plic
atio
n ca
n de
tect
and
ale
rt on
abn
orm
al n
umbe
rs o
f req
uest
s,
such
as
by IP
, use
r, to
tal p
er h
our o
r day
, or w
hate
ver m
akes
sen
se fo
r the
ap
plic
atio
n.X
X
This
can
be
hand
led
on th
e se
rver
leve
l by
impl
emen
tors
, but
id
eally
the
appl
icat
ion
shou
ld
also
be
awar
eU
se p
roxy
ser
vers
V8
Dat
a8.
1.5
Ver
ify th
at re
gula
r bac
kups
of i
mpo
rtant
dat
a ar
e pe
rform
ed a
nd th
at te
st
rest
orat
ion
of d
ata
is p
erfo
rmed
.X
V8
Dat
a8.
1.6
Ver
ify th
at b
acku
ps a
re s
tore
d se
cure
ly to
pre
vent
dat
a fro
m b
eing
sto
len
or
corr
upte
d.X
V8
Dat
a8.
2.1
Ver
ify th
e ap
plic
atio
n se
ts s
uffic
ient
ant
i-cac
hing
hea
ders
so
that
sen
sitiv
e da
ta is
not
cac
hed
in m
oder
n br
owse
rs.
XX
X
If im
plem
ento
r is
usin
g a
reve
rse
prox
y, it
mus
t allo
w
the
appl
icat
ion
to s
et
thes
e he
ader
s an
d no
t ove
rwrit
e th
em.
V8
Dat
a8.
2.2
Ver
ify th
at d
ata
stor
ed in
clie
nt s
ide
stor
age
(suc
h as
HTM
L5 lo
cal s
tora
ge,
sess
ion
stor
age,
Inde
xedD
B, r
egul
ar c
ooki
es o
r Fla
sh c
ooki
es) d
oes
not
cont
ain
sens
itive
dat
a or
PII.
XX
X
Sen
sitiv
e da
ta
depe
nds
on th
e na
tiona
l law
s, s
o th
e co
re te
am c
an d
o a
"bes
t effo
rt", b
ut
ultim
ate
resp
onsi
bilit
y fa
lls o
n th
e im
plem
ento
r.
V8
Dat
a8.
2.3
Ver
ify th
at a
uthe
ntic
ated
dat
a is
cle
ared
from
clie
nt s
tora
ge, s
uch
as th
e br
owse
r DO
M, a
fter t
he c
lient
or s
essi
on is
term
inat
ed.
XX
X
V8
Dat
a8.
3.1
Ver
ify th
at s
ensi
tive
data
is s
ent t
o th
e se
rver
in th
e H
TTP
mes
sage
bod
y or
he
ader
s, a
nd th
at q
uery
stri
ng p
aram
eter
s fro
m a
ny H
TTP
ver
b do
not
co
ntai
n se
nsiti
ve d
ata.
XX
X
V8
Dat
a8.
3.2
Ver
ify th
at u
sers
hav
e a
met
hod
to re
mov
e or
exp
ort t
heir
data
on
dem
and.
XX
X
Diff
in a
ggre
gate
d da
ta a
nd in
divi
dual
da
ta
V8
Dat
a8.
3.3
Ver
ify th
at u
sers
are
pro
vide
d cl
ear l
angu
age
rega
rdin
g co
llect
ion
and
use
of
supp
lied
pers
onal
info
rmat
ion
and
that
use
rs h
ave
prov
ided
opt
-in c
onse
nt fo
r th
e us
e of
that
dat
a be
fore
it is
use
d in
any
way
.X
XX
V8
Dat
a8.
3.4
Ver
ify th
at a
ll se
nsiti
ve d
ata
crea
ted
and
proc
esse
d by
the
appl
icat
ion
has
been
iden
tifie
d, a
nd e
nsur
e th
at a
pol
icy
is in
pla
ce o
n ho
w to
dea
l with
se
nsiti
ve d
ata.
[C8]
XX
X
Pol
icy
depe
nds
on
whe
re th
e da
ta is
us
ed, d
iffer
ent p
er
dist
rict/m
inis
try/c
oun
try.
Up
to th
e ju
ristic
tion
on h
ow to
impl
emen
t it
V8
Dat
a8.
3.5
Ver
ify a
cces
sing
sen
sitiv
e da
ta is
aud
ited
(with
out l
oggi
ng th
e se
nsiti
ve d
ata
itsel
f), if
the
data
is c
olle
cted
und
er re
leva
nt d
ata
prot
ectio
n di
rect
ives
or
whe
re lo
ggin
g of
acc
ess
is re
quire
d.X
X
V8
Dat
a8.
3.6
Ver
ify th
at s
ensi
tive
info
rmat
ion
cont
aine
d in
mem
ory
is o
verw
ritte
n as
soo
n as
it is
no
long
er re
quire
d to
miti
gate
mem
ory
dum
ping
atta
cks,
usi
ng z
eroe
s or
rand
om d
ata.
XX
Not
a ja
va th
ing
V8
Dat
a8.
3.7
Ver
ify th
at s
ensi
tive
or p
rivat
e in
form
atio
n th
at is
requ
ired
to b
e en
cryp
ted,
is
encr
ypte
d us
ing
appr
oved
alg
orith
ms
that
pro
vide
bot
h co
nfid
entia
lity
and
inte
grity
. [C
8]X
X
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79
V8
Dat
a8.
3.8
Ver
ify th
at s
ensi
tive
pers
onal
info
rmat
ion
is s
ubje
ct to
dat
a re
tent
ion
clas
sific
atio
n, s
uch
that
old
or o
ut o
f dat
e da
ta is
del
eted
aut
omat
ical
ly, o
n a
sche
dule
, or a
s th
e si
tuat
ion
requ
ires.
XX
V9
Com
mun
icat
ions
9.1.
1V
erify
that
sec
ured
TLS
is u
sed
for a
ll cl
ient
con
nect
ivity
, and
doe
s no
t fal
l ba
ck to
inse
cure
or u
nenc
rypt
ed p
roto
cols
. [C
8]X
XX
V9
Com
mun
icat
ions
9.1.
2
Ver
ify u
sing
onl
ine
or u
p to
dat
e TL
S te
stin
g to
ols
that
onl
y st
rong
alg
orith
ms,
ci
pher
s, a
nd p
roto
cols
are
ena
bled
, with
the
stro
nges
t alg
orith
ms
and
ciph
ers
set a
s pr
efer
red.
XX
X
V9
Com
mun
icat
ions
9.1.
3
Ver
ify th
at o
ld v
ersi
ons
of S
SL
and
TLS
pro
toco
ls, a
lgor
ithm
s, c
iphe
rs, a
nd
conf
igur
atio
n ar
e di
sabl
ed, s
uch
as S
SLv
2, S
SLv
3, o
r TLS
1.0
and
TLS
1.1
. Th
e la
test
ver
sion
of T
LS s
houl
d be
the
pref
erre
d ci
pher
sui
te.
XX
X
V9
Com
mun
icat
ions
9.2.
1
Ver
ify th
at c
onne
ctio
ns to
and
from
the
serv
er u
se tr
uste
d TL
S c
ertif
icat
es.
Whe
re in
tern
ally
gen
erat
ed o
r sel
f-sig
ned
certi
ficat
es a
re u
sed,
the
serv
er
mus
t be
conf
igur
ed to
onl
y tru
st s
peci
fic in
tern
al C
As
and
spec
ific
self-
sign
ed
certi
ficat
es. A
ll ot
hers
sho
uld
be re
ject
ed.
XX
V9
Com
mun
icat
ions
9.2.
2
Ver
ify th
at e
ncry
pted
com
mun
icat
ions
suc
h as
TLS
is u
sed
for a
ll in
boun
d an
d ou
tbou
nd c
onne
ctio
ns, i
nclu
ding
for m
anag
emen
t por
ts, m
onito
ring,
au
then
ticat
ion,
AP
I, or
web
ser
vice
cal
ls, d
atab
ase,
clo
ud, s
erve
rless
, m
ainf
ram
e, e
xter
nal,
and
partn
er c
onne
ctio
ns. T
he s
erve
r mus
t not
fall
back
to
inse
cure
or u
nenc
rypt
ed p
roto
cols
.X
X
V9
Com
mun
icat
ions
9.2.
3V
erify
that
all
encr
ypte
d co
nnec
tions
to e
xter
nal s
yste
ms
that
invo
lve
sens
itive
info
rmat
ion
or fu
nctio
ns a
re a
uthe
ntic
ated
.X
X
V9
Com
mun
icat
ions
9.2.
4V
erify
that
pro
per c
ertif
icat
ion
revo
catio
n, s
uch
as O
nlin
e C
ertif
icat
e S
tatu
s P
roto
col (
OC
SP
) Sta
plin
g, is
ena
bled
and
con
figur
ed.
XX
Uns
ure,
but
I th
ink
this
is d
one
by
impl
emen
tors
on
a se
rver
leve
lV
9C
omm
unic
atio
ns9.
2.5
Ver
ify th
at b
acke
nd T
LS c
onne
ctio
n fa
ilure
s ar
e lo
gged
.X
V10
Mal
icio
us10
.1.1
Ver
ify th
at a
cod
e an
alys
is to
ol is
in u
se th
at c
an d
etec
t pot
entia
lly m
alic
ious
co
de, s
uch
as ti
me
func
tions
, uns
afe
file
oper
atio
ns a
nd n
etw
ork
conn
ectio
ns.
X
V10
Mal
icio
us10
.2.1
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
not
con
tain
un
auth
oriz
ed p
hone
hom
e or
dat
a co
llect
ion
capa
bilit
ies.
Whe
re s
uch
func
tiona
lity
exis
ts, o
btai
n th
e us
er's
per
mis
sion
for i
t to
oper
ate
bef
ore
colle
ctin
g an
y da
ta.
XX
V10
Mal
icio
us10
.2.2
Ver
ify th
at th
e ap
plic
atio
n do
es n
ot a
sk fo
r unn
eces
sary
or e
xces
sive
pe
rmis
sion
s to
priv
acy
rela
ted
feat
ures
or s
enso
rs, s
uch
as c
onta
cts,
ca
mer
as, m
icro
phon
es, o
r loc
atio
n.X
X
V10
Mal
icio
us10
.2.3
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
not
con
tain
ba
ck d
oors
, suc
h as
har
d-co
ded
or a
dditi
onal
und
ocum
ente
d ac
coun
ts o
r ke
ys, c
ode
obfu
scat
ion,
und
ocum
ente
d bi
nary
blo
bs, r
ootk
its, o
r ant
i-de
bugg
ing,
inse
cure
deb
uggi
ng fe
atur
es, o
r oth
erw
ise
out o
f dat
e, in
secu
re,
or h
idde
n fu
nctio
nalit
y th
at c
ould
be
used
mal
icio
usly
if d
isco
vere
d.X
V10
Mal
icio
us10
.2.4
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
es n
ot
cont
ain
time
bom
bs b
y se
arch
ing
for d
ate
and
time
rela
ted
func
tions
.X
V10
Mal
icio
us10
.2.5
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
es n
ot
cont
ain
mal
icio
us c
ode,
suc
h as
sal
ami a
ttack
s, lo
gic
bypa
sses
, or l
ogic
bo
mbs
.X
V10
Mal
icio
us10
.2.6
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
not
con
tain
E
aste
r egg
s or
any
oth
er p
oten
tially
unw
ante
d fu
nctio
nalit
y.X
V10
Mal
icio
us10
.3.1
Ver
ify th
at if
the
appl
icat
ion
has
a cl
ient
or s
erve
r aut
o-up
date
feat
ure,
up
date
s sh
ould
be
obta
ined
ove
r sec
ure
chan
nels
and
dig
itally
sig
ned.
The
up
date
cod
e m
ust v
alid
ate
the
digi
tal s
igna
ture
of t
he u
pdat
e be
fore
inst
allin
g or
exe
cutin
g th
e up
date
.X
XX
Whe
n yo
u do
wnl
oad
the
DH
IS2
.war
file
, th
ere
is n
o ha
sh c
ode
on it
, to
verif
iy is
the
code
is a
ctua
lly v
alid
. C
ould
cau
se a
MIT
M
atta
ck.
V10
Mal
icio
us10
.3.2
Ver
ify th
at th
e ap
plic
atio
n em
ploy
s in
tegr
ity p
rote
ctio
ns, s
uch
as c
ode
sign
ing
or s
ub-r
esou
rce
inte
grity
. The
app
licat
ion
mus
t not
load
or e
xecu
te c
ode
from
un
trust
ed s
ourc
es, s
uch
as lo
adin
g in
clud
es, m
odul
es, p
lugi
ns, c
ode,
or
libra
ries
from
unt
rust
ed s
ourc
es o
r the
Inte
rnet
.X
XX
V10
Mal
icio
us10
.3.3
Ver
ify th
at th
e ap
plic
atio
n ha
s pr
otec
tion
from
sub
-dom
ain
take
over
s if
the
appl
icat
ion
relie
s up
on D
NS
ent
ries
or D
NS
sub
-dom
ains
, suc
h as
exp
ired
dom
ain
nam
es, o
ut o
f dat
e D
NS
poi
nter
s or
CN
AM
Es,
exp
ired
proj
ects
at
publ
ic s
ourc
e co
de re
pos,
or t
rans
ient
clo
ud A
PIs
, ser
verle
ss fu
nctio
ns, o
r st
orag
e bu
cket
s (a
utog
en-b
ucke
t-id.
clou
d.ex
ampl
e.co
m) o
r sim
ilar.
Pro
tect
ions
can
incl
ude
ensu
ring
that
DN
S n
ames
use
d by
app
licat
ions
are
re
gula
rly c
heck
ed fo
r exp
iry o
r cha
nge.
XX
X
V11
Bus
Logi
c11
.1.1
Ver
ify th
e ap
plic
atio
n w
ill o
nly
proc
ess
busi
ness
logi
c flo
ws
for t
he s
ame
user
in
seq
uent
ial s
tep
orde
r and
with
out s
kipp
ing
step
s.X
XX
V11
Bus
Logi
c11
.1.2
Ver
ify th
e ap
plic
atio
n w
ill o
nly
proc
ess
busi
ness
logi
c flo
ws
with
all
step
s be
ing
proc
esse
d in
real
istic
hum
an ti
me,
i.e.
tran
sact
ions
are
not
sub
mitt
ed
too
quic
kly.
XX
X
V11
Bus
Logi
c11
.1.3
Ver
ify th
e ap
plic
atio
n ha
s ap
prop
riate
lim
its fo
r spe
cific
bus
ines
s ac
tions
or
trans
actio
ns w
hich
are
cor
rect
ly e
nfor
ced
on a
per
use
r bas
is.
XX
X
V11
Bus
Logi
c11
.1.4
Ver
ify th
e ap
plic
atio
n ha
s su
ffici
ent a
nti-a
utom
atio
n co
ntro
ls to
det
ect a
nd
prot
ect a
gain
st d
ata
exfil
tratio
n, e
xces
sive
bus
ines
s lo
gic
requ
ests
, exc
essi
ve
file
uplo
ads
or d
enia
l of s
ervi
ce a
ttack
s.X
XX
E.g
. file
upl
oads
are
re
stric
ted
thro
ugh
the
reve
rse
prox
y.
V11
Bus
Logi
c11
.1.5
Ver
ify th
e ap
plic
atio
n ha
s bu
sine
ss lo
gic
limits
or v
alid
atio
n to
pro
tect
aga
inst
lik
ely
busi
ness
risk
s or
thre
ats,
iden
tifie
d us
ing
thre
at m
odel
ling
or s
imila
r m
etho
dolo
gies
.X
XX
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79
V11
Bus
Logi
c11
.1.6
Ver
ify th
e ap
plic
atio
n do
es n
ot s
uffe
r fro
m "t
ime
of c
heck
to ti
me
of u
se"
(TO
CTO
U) i
ssue
s or
oth
er ra
ce c
ondi
tions
for s
ensi
tive
oper
atio
ns.
XX
V11
Bus
Logi
c11
.1.7
Ver
ify th
e ap
plic
atio
n m
onito
rs fo
r unu
sual
eve
nts
or a
ctiv
ity fr
om a
bus
ines
s lo
gic
pers
pect
ive.
For
exa
mpl
e, a
ttem
pts
to p
erfo
rm a
ctio
ns o
ut o
f ord
er o
r ac
tions
whi
ch a
nor
mal
use
r wou
ld n
ever
atte
mpt
. [C
9]X
X
Cou
ld b
e in
tere
stin
g fo
r e.g
. P
roga
mS
tage
s an
d Tr
acke
r pro
gram
s.
V11
Bus
Logi
c11
.1.8
Ver
ify th
e ap
plic
atio
n ha
s co
nfig
urab
le a
lerti
ng w
hen
auto
mat
ed a
ttack
s or
un
usua
l act
ivity
is d
etec
ted.
XX
V12
File
s12
.1.1
Ver
ify th
at th
e ap
plic
atio
n w
ill n
ot a
ccep
t lar
ge fi
les
that
cou
ld fi
ll up
sto
rage
or
caus
e a
deni
al o
f ser
vice
atta
ck.
XX
X
V12
File
s12
.1.2
Ver
ify th
at c
ompr
esse
d fil
es a
re c
heck
ed fo
r "zi
p bo
mbs
" - s
mal
l inp
ut fi
les
that
will
dec
ompr
ess
into
hug
e fil
es th
us e
xhau
stin
g fil
e st
orag
e lim
its.
XX
V12
File
s12
.1.3
Ver
ify th
at a
file
siz
e qu
ota
and
max
imum
num
ber o
f file
s pe
r use
r is
enfo
rced
to
ens
ure
that
a s
ingl
e us
er c
anno
t fill
up
the
stor
age
with
too
man
y fil
es, o
r ex
cess
ivel
y la
rge
files
.X
X
V12
File
s12
.2.1
Ver
ify th
at fi
les
obta
ined
from
unt
rust
ed s
ourc
es a
re v
alid
ated
to b
e of
ex
pect
ed ty
pe b
ased
on
the
file'
s co
nten
t.X
X
V12
File
s12
.3.1
Ver
ify th
at u
ser-
subm
itted
file
nam
e m
etad
ata
is n
ot u
sed
dire
ctly
with
sys
tem
or
fram
ewor
k fil
e an
d U
RL
AP
I to
prot
ect a
gain
st p
ath
trave
rsal
.X
XX
V12
File
s12
.3.2
Ver
ify th
at u
ser-
subm
itted
file
nam
e m
etad
ata
is v
alid
ated
or i
gnor
ed to
pr
even
t the
dis
clos
ure,
cre
atio
n, u
pdat
ing
or re
mov
al o
f loc
al fi
les
(LFI
).X
XX
V12
File
s12
.3.3
Ver
ify th
at u
ser-
subm
itted
file
nam
e m
etad
ata
is v
alid
ated
or i
gnor
ed to
pr
even
t the
dis
clos
ure
or e
xecu
tion
of re
mot
e fil
es (R
FI),
whi
ch m
ay a
lso
lead
to
SS
RF.
XX
X
V12
File
s12
.3.4
Ver
ify th
at th
e ap
plic
atio
n pr
otec
ts a
gain
st re
flect
ive
file
dow
nloa
d (R
FD) b
y va
lidat
ing
or ig
norin
g us
er-s
ubm
itted
file
nam
es in
a J
SO
N, J
SO
NP
, or U
RL
para
met
er, t
he re
spon
se C
onte
nt-T
ype
head
er s
houl
d be
set
to te
xt/p
lain
, an
d th
e C
onte
nt-D
ispo
sitio
n he
ader
sho
uld
have
a fi
xed
filen
ame.
XX
X
V12
File
s12
.3.5
Ver
ify th
at u
ntru
sted
file
met
adat
a is
not
use
d di
rect
ly w
ith s
yste
m A
PI o
r lib
rarie
s, to
pro
tect
aga
inst
OS
com
man
d in
ject
ion.
XX
X
V12
File
s12
.3.6
Ver
ify th
at th
e ap
plic
atio
n do
es n
ot in
clud
e an
d ex
ecut
e fu
nctio
nalit
y fro
m
untru
sted
sou
rces
, suc
h as
unv
erifi
ed c
onte
nt d
istri
butio
n ne
twor
ks,
Java
Scr
ipt l
ibra
ries,
nod
e np
m li
brar
ies,
or s
erve
r-si
de D
LLs.
XX
V12
File
s12
.4.1
Ver
ify th
at fi
les
obta
ined
from
unt
rust
ed s
ourc
es a
re s
tore
d ou
tsid
e th
e w
eb
root
, with
lim
ited
perm
issi
ons,
pre
fera
bly
with
stro
ng v
alid
atio
n.X
XX
V12
File
s12
.4.2
Ver
ify th
at fi
les
obta
ined
from
unt
rust
ed s
ourc
es a
re s
cann
ed b
y an
tiviru
s sc
anne
rs to
pre
vent
upl
oad
of k
now
n m
alic
ious
con
tent
.X
XX
Impl
emen
tor w
ould
ha
ve to
run
a vi
rus
scan
on
the
files
Can
sen
d a
wor
d do
cum
ent w
ith
mal
icio
us c
onte
nt in
it
and
othe
r peo
ple
can
dow
nloa
d it.
V12
File
s12
.5.1
Ver
ify th
at th
e w
eb ti
er is
con
figur
ed to
ser
ve o
nly
files
with
spe
cific
file
ex
tens
ions
to p
reve
nt u
nint
entio
nal i
nfor
mat
ion
and
sour
ce c
ode
leak
age.
For
ex
ampl
e, b
acku
p fil
es (e
.g. .
bak)
, tem
pora
ry w
orki
ng fi
les
(e.g
. .sw
p),
com
pres
sed
files
(.zi
p, .t
ar.g
z, e
tc) a
nd o
ther
ext
ensi
ons
com
mon
ly u
sed
by
edito
rs s
houl
d be
blo
cked
unl
ess
requ
ired.
XX
X
V12
File
s12
.5.2
Ver
ify th
at d
irect
requ
ests
to u
ploa
ded
files
will
nev
er b
e ex
ecut
ed a
s H
TML/
Java
Scr
ipt c
onte
nt.
XX
X
V12
File
s12
.6.1
Ver
ify th
at th
e w
eb o
r app
licat
ion
serv
er is
con
figur
ed w
ith a
whi
telis
t of
reso
urce
s or
sys
tem
s to
whi
ch th
e se
rver
can
sen
d re
ques
ts o
r loa
d da
ta/fi
les
from
.X
XX
impl
. ser
ver
conf
igur
atio
n
V13
AP
I13
.1.1
Ver
ify th
at a
ll ap
plic
atio
n co
mpo
nent
s us
e th
e sa
me
enco
ding
s an
d pa
rser
s to
av
oid
pars
ing
atta
cks
that
exp
loit
diffe
rent
UR
I or f
ile p
arsi
ng b
ehav
ior t
hat
coul
d be
use
d in
SS
RF
and
RFI
atta
cks.
XX
X
V13
AP
I13
.1.2
Ver
ify th
at a
cces
s to
adm
inis
tratio
n an
d m
anag
emen
t fun
ctio
ns is
lim
ited
to
auth
oriz
ed a
dmin
istra
tors
.X
XX
V13
AP
I13
.1.3
Ver
ify A
PI U
RLs
do
not e
xpos
e se
nsiti
ve in
form
atio
n, s
uch
as th
e A
PI k
ey,
sess
ion
toke
ns e
tc.
XX
X
V13
AP
I13
.1.4
Ver
ify th
at a
utho
rizat
ion
deci
sion
s ar
e m
ade
at b
oth
the
UR
I, en
forc
ed b
y pr
ogra
mm
atic
or d
ecla
rativ
e se
curit
y at
the
cont
rolle
r or r
oute
r, an
d at
the
reso
urce
leve
l, en
forc
ed b
y m
odel
-bas
ed p
erm
issi
ons.
XX
V13
AP
I13
.1.5
Ver
ify th
at re
ques
ts c
onta
inin
g un
expe
cted
or m
issi
ng c
onte
nt ty
pes
are
reje
cted
with
app
ropr
iate
hea
ders
(HTT
P re
spon
se s
tatu
s 40
6 U
nacc
epta
ble
or 4
15 U
nsup
porte
d M
edia
Typ
e).
XX
V13
AP
I13
.2.1
Ver
ify th
at e
nabl
ed R
ES
Tful
HTT
P m
etho
ds a
re a
val
id c
hoic
e fo
r the
use
r or
actio
n, s
uch
as p
reve
ntin
g no
rmal
use
rs u
sing
DE
LETE
or P
UT
on p
rote
cted
A
PI o
r res
ourc
es.
XX
X
V13
AP
I13
.2.2
Ver
ify th
at J
SO
N s
chem
a va
lidat
ion
is in
pla
ce a
nd v
erifi
ed b
efor
e ac
cept
ing
inpu
t.X
XX
V13
AP
I13
.2.3
Ver
ify th
at R
ES
Tful
web
ser
vice
s th
at u
tiliz
e co
okie
s ar
e pr
otec
ted
from
C
ross
-Site
Req
uest
For
gery
via
the
use
of a
t lea
st o
ne o
r mor
e of
the
follo
win
g: tr
iple
or d
oubl
e su
bmit
cook
ie p
atte
rn (s
ee h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
Cro
ss-S
ite_R
eque
st_F
orge
ry_(
CS
RF)
_Pre
vent
ion_
Che
at_S
heet
), C
SR
F no
nces
, or O
RIG
IN re
ques
t hea
der
chec
ks.
XX
X
Ver
y ap
plic
able
, ho
t top
ic, r
aise
d by
se
vera
l sec
urity
gr
oups
.
V13
AP
I13
.2.4
Ver
ify th
at R
ES
T se
rvic
es h
ave
anti-
auto
mat
ion
cont
rols
to p
rote
ct a
gain
st
exce
ssiv
e ca
lls, e
spec
ially
if th
e A
PI i
s un
auth
entic
ated
.X
X
Esp
ecia
lly im
porta
nt
for t
he A
pp S
tore
ba
cken
d A
PI a
s it
is
publ
icly
ava
ilabl
e w
ithou
t aut
h.
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79
V13
AP
I13
.2.5
Ver
ify th
at R
ES
T se
rvic
es e
xplic
itly
chec
k th
e in
com
ing
Con
tent
-Typ
e to
be
the
expe
cted
one
, suc
h as
app
licat
ion/
xml o
r app
licat
ion/
JSO
N.
XX
V13
AP
I13
.2.6
Ver
ify th
at th
e m
essa
ge h
eade
rs a
nd p
aylo
ad a
re tr
ustw
orth
y an
d no
t m
odifi
ed in
tran
sit.
Req
uirin
g st
rong
enc
rypt
ion
for t
rans
port
(TLS
onl
y) m
ay
be s
uffic
ient
in m
any
case
s as
it p
rovi
des
both
con
fiden
tialit
y an
d in
tegr
ity
prot
ectio
n. P
er-m
essa
ge d
igita
l sig
natu
res
can
prov
ide
addi
tiona
l ass
uran
ce
on to
p of
the
trans
port
prot
ectio
ns fo
r hig
h-se
curit
y ap
plic
atio
ns b
ut b
ring
with
th
em a
dditi
onal
com
plex
ity a
nd ri
sks
to w
eigh
aga
inst
the
bene
fits.
XX
V13
AP
I13
.3.1
Ver
ify th
at X
SD
sch
ema
valid
atio
n ta
kes
plac
e to
ens
ure
a pr
oper
ly fo
rmed
X
ML
docu
men
t, fo
llow
ed b
y va
lidat
ion
of e
ach
inpu
t fie
ld b
efor
e an
y pr
oces
sing
of t
hat d
ata
take
s pl
ace.
XX
X
V13
AP
I13
.3.2
Ver
ify th
at th
e m
essa
ge p
aylo
ad is
sig
ned
usin
g W
S-S
ecur
ity to
ens
ure
relia
ble
trans
port
betw
een
clie
nt a
nd s
ervi
ce.
XX
Not
app
licab
le if
S
OA
P is
n't u
sed.
V13
AP
I13
.4.1
Ver
ify th
at q
uery
whi
telis
ting
or a
com
bina
tion
of d
epth
lim
iting
and
am
ount
lim
iting
sho
uld
be u
sed
to p
reve
nt G
raph
QL
or d
ata
laye
r exp
ress
ion
deni
al o
f se
rvic
e (D
oS) a
s a
resu
lt of
exp
ensi
ve, n
este
d qu
erie
s. F
or m
ore
adva
nced
sc
enar
ios,
que
ry c
ost a
naly
sis
shou
ld b
e us
ed.
XX
We
don'
t use
G
raph
QL
but D
HIS
2 ha
s a
cust
om
dyna
mic
filte
r la
ngua
ge s
imila
r to
it w
hich
can
lead
to
heav
y qu
erie
s so
th
is a
pplie
s.
V13
AP
I13
.4.2
Ver
ify th
at G
raph
QL
or o
ther
dat
a la
yer a
utho
rizat
ion
logi
c sh
ould
be
impl
emen
ted
at th
e bu
sine
ss lo
gic
laye
r ins
tead
of t
he G
raph
QL
laye
r.X
X
V14
Con
fig14
.1.1
Ver
ify th
at th
e ap
plic
atio
n bu
ild a
nd d
eplo
ymen
t pro
cess
es a
re p
erfo
rmed
in a
se
cure
and
repe
atab
le w
ay, s
uch
as C
I / C
D a
utom
atio
n, a
utom
ated
co
nfig
urat
ion
man
agem
ent,
and
auto
mat
ed d
eplo
ymen
t scr
ipts
.X
X
DH
IS is
not
re
spon
sibl
e ho
w it
is
dep
loye
d w
ithin
th
e en
viro
nmen
t, on
ly re
spon
sibl
e fo
r ho
w th
e pr
oces
s sh
ould
be
done
. N
eed
to b
e de
ploy
ed s
ecur
ely
by th
e im
plem
ento
rs.
V14
Con
fig14
.1.2
Ver
ify th
at c
ompi
ler f
lags
are
con
figur
ed to
ena
ble
all a
vaila
ble
buffe
r ove
rflow
pr
otec
tions
and
war
ning
s, in
clud
ing
stac
k ra
ndom
izat
ion,
dat
a ex
ecut
ion
prev
entio
n, a
nd to
bre
ak th
e bu
ild if
an
unsa
fe p
oint
er, m
emor
y, fo
rmat
stri
ng,
inte
ger,
or s
tring
ope
ratio
ns a
re fo
und.
XX
V14
Con
fig14
.1.3
Ver
ify th
at s
erve
r con
figur
atio
n is
har
dene
d as
per
the
reco
mm
enda
tions
of
the
appl
icat
ion
serv
er a
nd fr
amew
orks
in u
se.
XX
V14
Con
fig14
.1.4
Ver
ify th
at th
e ap
plic
atio
n, c
onfig
urat
ion,
and
all
depe
nden
cies
can
be
re-
depl
oyed
usi
ng a
utom
ated
dep
loym
ent s
crip
ts, b
uilt
from
a d
ocum
ente
d an
d te
sted
runb
ook
in a
reas
onab
le ti
me,
or r
esto
red
from
bac
kups
in a
tim
ely
fash
ion.
XX
Onl
y do
de
yplo
ymen
t sc
ripts
for t
esitn
g.
Just
pro
vide
the
.w
ar fi
le a
nd th
ey
can
depl
oy it
th
emse
lves
and
do
wha
t the
y w
ant.
V14
Con
fig14
.1.5
Ver
ify th
at a
utho
rized
adm
inis
trato
rs c
an v
erify
the
inte
grity
of a
ll se
curit
y-re
leva
nt c
onfig
urat
ions
to d
etec
t tam
perin
g.X
Som
e is
not
in
tern
ally
, som
e if
som
e ex
tern
ally
. S
ome
audi
ting
is
done
by
the
syst
em.
V14
Con
fig14
.2.1
Ver
ify th
at a
ll co
mpo
nent
s ar
e up
to d
ate,
pre
fera
bly
usin
g a
depe
nden
cy
chec
ker d
urin
g bu
ild o
r com
pile
tim
e. [C
2]X
XX
V14
Con
fig14
.2.2
Ver
ify th
at a
ll un
need
ed fe
atur
es, d
ocum
enta
tion,
sam
ples
, con
figur
atio
ns a
re
rem
oved
, suc
h as
sam
ple
appl
icat
ions
, pla
tform
doc
umen
tatio
n, a
nd d
efau
lt or
exa
mpl
e us
ers.
XX
X
V14
Con
fig14
.2.3
Ver
ify th
at if
app
licat
ion
asse
ts, s
uch
as J
avaS
crip
t lib
rarie
s, C
SS
sty
lesh
eets
or
web
font
s, a
re h
oste
d ex
tern
ally
on
a co
nten
t del
iver
y ne
twor
k (C
DN
) or
exte
rnal
pro
vide
r, S
ubre
sour
ce In
tegr
ity (S
RI)
is u
sed
to v
alid
ate
the
inte
grity
of
the
asse
t.X
XX
Cur
rent
ly h
oste
d by
th
e ap
plic
atio
n its
elf,
but w
ill b
e re
leva
nt
in th
e fu
ture
.
V14
Con
fig14
.2.4
Ver
ify th
at th
ird p
arty
com
pone
nts
com
e fro
m p
re-d
efin
ed, t
rust
ed a
nd
cont
inua
lly m
aint
aine
d re
posi
torie
s. [C
2]X
X
V14
Con
fig14
.2.5
Ver
ify th
at a
n in
vent
ory
cata
log
is m
aint
aine
d of
all
third
par
ty li
brar
ies
in u
se.
[C2]
XX
V14
Con
fig14
.2.6
Ver
ify th
at th
e at
tack
sur
face
is re
duce
d by
san
dbox
ing
or e
ncap
sula
ting
third
pa
rty li
brar
ies
to e
xpos
e on
ly th
e re
quire
d be
havi
our i
nto
the
appl
icat
ion.
([C
2](h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g))
XX
V14
Con
fig14
.3.1
Ver
ify th
at w
eb o
r app
licat
ion
serv
er a
nd fr
amew
ork
erro
r mes
sage
s ar
e co
nfig
ured
to d
eliv
er u
ser a
ctio
nabl
e, c
usto
miz
ed re
spon
ses
to e
limin
ate
any
unin
tend
ed s
ecur
ity d
iscl
osur
es.
XX
X
V14
Con
fig14
.3.2
Ver
ify th
at w
eb o
r app
licat
ion
serv
er a
nd a
pplic
atio
n fra
mew
ork
debu
g m
odes
ar
e di
sabl
ed in
pro
duct
ion
to e
limin
ate
debu
g fe
atur
es, d
evel
oper
con
sole
s,
and
unin
tend
ed s
ecur
ity d
iscl
osur
es.
XX
X
Impl
emen
tatio
n re
spon
sbili
ty. T
hey
have
the
posi
blity
to
run
debu
g op
eatio
ns,
but i
ts n
ot a
ctiv
ated
by
def
ault.
V14
Con
fig14
.3.3
Ver
ify th
at th
e H
TTP
hea
ders
or a
ny p
art o
f the
HTT
P re
spon
se d
o no
t ex
pose
det
aile
d ve
rsio
n in
form
atio
n of
sys
tem
com
pone
nts.
XX
X
C1-
C10
Top
10
Pro
activ
e C
ontro
ls: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g)24
2/28
613
2/28
619
6/28
625
6/28
625
8/28
6To
tal:
46To
tal:
21To
tal:
45To
tal:
80To
tal:
79
V14
Con
fig14
.4.1
Ver
ify th
at e
very
HTT
P re
spon
se c
onta
ins
a co
nten
t typ
e he
ader
spe
cify
ing
a sa
fe c
hara
cter
set
(e.g
., U
TF-8
, IS
O 8
859-
1).
XX
X
V14
Con
fig14
.4.2
Ver
ify th
at a
ll A
PI r
espo
nses
con
tain
Con
tent
-Dis
posi
tion:
atta
chm
ent;
filen
ame=
"api
.json
" (or
oth
er a
ppro
pria
te fi
lena
me
for t
he c
onte
nt ty
pe).
XX
X
V14
Con
fig14
.4.3
Ver
ify th
at a
con
tent
sec
urity
pol
icy
(CS
Pv2
) is
in p
lace
that
hel
ps m
itiga
te
impa
ct fo
r XS
S a
ttack
s lik
e H
TML,
DO
M, J
SO
N, a
nd J
avaS
crip
t inj
ectio
n vu
lner
abili
ties.
XX
XV
14C
onfig
14.4
.4V
erify
that
all
resp
onse
s co
ntai
n X
-Con
tent
-Typ
e-O
ptio
ns: n
osni
ff.X
XX
V14
Con
fig14
.4.5
Ver
ify th
at H
TTP
Stri
ct T
rans
port
Sec
urity
hea
ders
are
incl
uded
on
all
resp
onse
s an
d fo
r all
subd
omai
ns, s
uch
as S
trict
-Tra
nspo
rt-S
ecur
ity: m
ax-
age=
1572
4800
; inc
lude
Sub
dom
ains
.X
XX
V14
Con
fig14
.4.6
Ver
ify th
at a
sui
tabl
e "R
efer
rer-
Pol
icy"
hea
der i
s in
clud
ed, s
uch
as "n
o-re
ferr
er" o
r "sa
me-
orig
in".
XX
X
V14
Con
fig14
.4.7
Ver
ify th
at a
sui
tabl
e X
-Fra
me-
Opt
ions
or C
onte
nt-S
ecur
ity-P
olic
y: fr
ame-
ance
stor
s he
ader
is in
use
for s
ites
whe
re c
onte
nt s
houl
d no
t be
embe
dded
in
a th
ird-p
arty
site
.X
XX
V14
Con
fig14
.5.1
Ver
ify th
at th
e ap
plic
atio
n se
rver
onl
y ac
cept
s th
e H
TTP
met
hods
in u
se b
y th
e ap
plic
atio
n or
AP
I, in
clud
ing
pre-
fligh
t OP
TIO
NS
.X
XX
V14
Con
fig14
.5.2
Ver
ify th
at th
e su
pplie
d O
rigin
hea
der i
s no
t use
d fo
r aut
hent
icat
ion
or a
cces
s co
ntro
l dec
isio
ns, a
s th
e O
rigin
hea
der c
an e
asily
be
chan
ged
by a
n at
tack
er.
XX
X
V14
Con
fig14
.5.3
Ver
ify th
at th
e cr
oss-
dom
ain
reso
urce
sha
ring
(CO
RS
) Acc
ess-
Con
trol-A
llow
-O
rigin
hea
der u
ses
a st
rict w
hite
-list
of t
rust
ed d
omai
ns to
mat
ch a
gain
st a
nd
does
not
sup
port
the
"nul
l" or
igin
.X
XX
The
CO
RS
whi
telis
t is
con
trolle
d by
the
impl
emen
tor o
r ad
min
of t
he
inst
ance
.
V14
Con
fig14
.5.4
Ver
ify th
at H
TTP
hea
ders
add
ed b
y a
trust
ed p
roxy
or S
SO
dev
ices
, suc
h as
a
bear
er to
ken,
are
aut
hent
icat
ed b
y th
e ap
plic
atio
n.X
X
118
Phase 2: Scoring spreadsheet
This spreadsheet shows the results from the scoring phase. To explain the
spreadsheet:
• A failed control is marked red.
• A passed control is marked green.
• A control with conflicting results (a pass and fail) from the parti-
cipants is marked yellow.
• A control that was skipped by the participants is marked pink.
Three people participated in this phase. All three responses are shown side-
by-side for comparisson. To reiterate from the Methods chapter: a control
is a pass or a fail if selected as such by the majority, or if passed by the other
participants.
For each participant, a counter shows the number of passed controls
and the total number of applicable controls. The frontend developer, for
example, gave 122 out of 258 controls a pass.
119
C1-
C10
Top
10
Proa
ctiv
e C
ontr
ols:
http
s://w
ww
.ow
asp.
org/
inde
x.ph
p/O
WA
SP_P
roac
tive_
Con
trol
s#ta
b=Fo
rmal
_Num
berin
g)25
8/28
612
2/25
814
6/25
84/
258
174/
258
79A
SV
S 4
.0Fr
onte
ndB
acke
ndS
ecur
ity E
.C
ombi
ned
Fron
tend
Bac
kend
Sec
urity
E.
Sect
ion
Nam
eIte
mD
escr
iptio
nL1
L2L3
CW
EN
IST
App
licab
lePa
ssPa
ssPa
ssPa
ssC
omm
ents
Com
men
tsC
omm
ents
Impl
.
V1
Arc
hite
ctur
e1.
1.1
Ver
ify th
e us
e of
a s
ecur
e so
ftwar
e de
velo
pmen
t life
cycl
e th
at a
ddre
sses
sec
urity
in
all
stag
es o
f dev
elop
men
t. [C
1]X
X
The
cont
rol i
s fa
iled
from
the
poin
t of v
iew
of a
st
anda
rized
pro
cess
. The
re is
a p
eer-
revi
ew p
roce
ss
how
ever
, and
cer
tain
sec
urity
con
side
ratio
ns ta
ken
into
in b
efor
e de
velo
pmen
t.
V1
Arc
hite
ctur
e1.
1.2
Ver
ify th
e us
e of
thre
at m
odel
ing
for e
very
des
ign
chan
ge o
r spr
int p
lann
ing
to
iden
tify
thre
ats,
pla
n fo
r cou
nter
mea
sure
s, fa
cilit
ate
appr
opria
te ri
sk re
spon
ses,
an
d gu
ide
secu
rity
test
ing.
XX
1053
No
form
al p
roce
ss fo
r thi
s.
V1
Arc
hite
ctur
e1.
1.3
Ver
ify th
at a
ll us
er s
torie
s an
d fe
atur
es c
onta
in fu
nctio
nal s
ecur
ity c
onst
rain
ts,
such
as
"As
a us
er, I
sho
uld
be a
ble
to v
iew
and
edi
t my
prof
ile. I
sho
uld
not b
e ab
le to
vie
w o
r edi
t any
one
else
's p
rofil
e"X
X11
10
V1
Arc
hite
ctur
e1.
1.4
Ver
ify d
ocum
enta
tion
and
just
ifica
tion
of a
ll th
e ap
plic
atio
n's
trust
bou
ndar
ies,
co
mpo
nent
s, a
nd s
igni
fican
t dat
a flo
ws.
XX
1059
Con
tinue
sly
upda
ted
as th
ings
are
alte
red
in th
e sy
stem
.
V1
Arc
hite
ctur
e1.
1.5
Ver
ify d
efin
ition
and
sec
urity
ana
lysi
s of
the
appl
icat
ion'
s hi
gh-le
vel a
rchi
tect
ure
and
all c
onne
cted
rem
ote
serv
ices
. [C
1]X
X10
59
The
user
can
opt
to u
se e
xter
nal s
ervi
ces
such
as
Am
azon
clo
ud. I
t is
part
impl
emen
tatio
n, in
that
they
ar
e th
emse
lves
in c
harg
e of
sec
urin
g it,
but
from
D
HIS
2s s
tand
poin
t, if
they
are
apl
e to
sec
ure
it, th
en
they
do
V1
Arc
hite
ctur
e1.
1.6
Ver
ify im
plem
enta
tion
of c
entra
lized
, sim
ple
(eco
nom
y of
des
ign)
, vet
ted,
sec
ure,
an
d re
usab
le s
ecur
ity c
ontro
ls to
avo
id d
uplic
ate,
mis
sing
, ine
ffect
ive,
or i
nsec
ure
cont
rols
. [C
10]
XX
637
V1
Arc
hite
ctur
e1.
1.7
Ver
ify a
vaila
bilit
y of
a s
ecur
e co
ding
che
cklis
t, se
curit
y re
quire
men
ts, g
uide
line,
or
polic
y to
all
deve
lope
rs a
nd te
ster
s.X
X63
7N
o fo
rmal
ized
gui
delin
es o
r che
cklis
t
V1
Arc
hite
ctur
e1.
2.2
Ver
ify th
at c
omm
unic
atio
ns b
etw
een
appl
icat
ion
com
pone
nts,
incl
udin
g A
PIs
, m
iddl
ewar
e an
d da
ta la
yers
, are
aut
hent
icat
ed. C
ompo
nent
s sh
ould
hav
e th
e le
ast n
eces
sary
priv
ilege
s ne
eded
. [C
3]X
X30
6
Hav
e m
ore
AP
I tes
ts th
at te
st a
uthe
ntic
atio
n an
d ac
cess
con
trol f
or th
e us
ers,
bas
ed o
n ho
w th
e sy
stem
is c
onfig
ured
.
V1
Arc
hite
ctur
e1.
2.3
Ver
ify th
at th
e ap
plic
atio
n us
es a
sin
gle
vette
d au
then
ticat
ion
mec
hani
sm th
at is
kn
own
to b
e se
cure
, can
be
exte
nded
to in
clud
e st
rong
aut
hent
icat
ion,
and
has
su
ffici
ent l
oggi
ng a
nd m
onito
ring
to d
etec
t acc
ount
abu
se o
r bre
ache
s.X
X30
6
Als
o ha
ve a
n oa
uth
setu
p in
add
ition
to
user
nam
e/pa
ssw
ord.
Hav
e pr
otec
tion
agai
nst f
lood
ing
of a
uthe
ntia
tion,
i.e.
bru
te fo
rce
atta
ck.
V1
Arc
hite
ctur
e1.
2.4
Ver
ify th
at a
ll au
then
ticat
ion
path
way
s an
d id
entit
y m
anag
emen
t AP
Is im
plem
ent
cons
iste
nt a
uthe
ntic
atio
n se
curit
y co
ntro
l stre
ngth
, suc
h th
at th
ere
are
no w
eake
r al
tern
ativ
es p
er th
e ris
k of
the
appl
icat
ion.
XX
306
V1
Arc
hite
ctur
e1.
4.1
Ver
ify th
at tr
uste
d en
forc
emen
t poi
nts
such
as
at a
cces
s co
ntro
l gat
eway
s,
serv
ers,
and
ser
verle
ss fu
nctio
ns e
nfor
ce a
cces
s co
ntro
ls. N
ever
enf
orce
acc
ess
cont
rols
on
the
clie
nt.
XX
602
This
is c
over
ed
on th
e se
rver
-si
de.
V1
Arc
hite
ctur
e1.
4.2
Ver
ify th
at th
e ch
osen
acc
ess
cont
rol s
olut
ion
is fl
exib
le e
noug
h to
mee
t the
ap
plic
atio
n's
need
s.X
X28
4
V1
Arc
hite
ctur
e1.
4.3
Ver
ify e
nfor
cem
ent o
f the
prin
cipl
e of
leas
t priv
ilege
in fu
nctio
ns, d
ata
files
, UR
Ls,
cont
rolle
rs, s
ervi
ces,
and
oth
er re
sour
ces.
Thi
s im
plie
s pr
otec
tion
agai
nst s
poof
ing
and
elev
atio
n of
priv
ilege
.X
X27
2
The
syst
em is
in p
lace
, but
the
impl
emen
tors
co
nfig
ure
it. H
ave
the
abili
ty to
con
figur
e th
e ac
cess
to
thes
e th
ings
, but
don
't ha
ve a
ny s
etup
to h
inde
r sp
oofin
g, fo
r exa
mpl
e. In
the
case
of e
leva
tion
of
priv
iledg
e, y
ou c
anno
t giv
e m
ore
acce
ss th
an w
hat
the
user
has
.
V1
Arc
hite
ctur
e1.
4.4
Ver
ify th
e ap
plic
atio
n us
es a
sin
gle
and
wel
l-vet
ted
acce
ss c
ontro
l mec
hani
sm fo
r ac
cess
ing
prot
ecte
d da
ta a
nd re
sour
ces.
All
requ
ests
mus
t pas
s th
roug
h th
is
sing
le m
echa
nism
to a
void
cop
y an
d pa
ste
or in
secu
re a
ltern
ativ
e pa
ths.
[C7]
XX
284
V1
Arc
hite
ctur
e1.
4.5
Ver
ify th
at a
ttrib
ute
or fe
atur
e-ba
sed
acce
ss c
ontro
l is
used
whe
reby
the
code
ch
ecks
the
user
's a
utho
rizat
ion
for a
feat
ure/
data
item
rath
er th
an ju
st th
eir r
ole.
P
erm
issi
ons
shou
ld s
till b
e al
loca
ted
usin
g ro
les.
[C7]
XX
275
We
don'
t aut
horiz
e w
hen
we
chec
k th
is ty
pe o
f ac
cess
con
trol;
only
che
ck p
erm
issi
ons.
V1
Arc
hite
ctur
e1.
5.1
Ver
ify th
at in
put a
nd o
utpu
t req
uire
men
ts c
lear
ly d
efin
e ho
w to
han
dle
and
proc
ess
data
bas
ed o
n ty
pe, c
onte
nt, a
nd a
pplic
able
law
s, re
gula
tions
, and
oth
er
polic
y co
mpl
ianc
e.X
X10
29H
ave
supp
ort f
or th
is, b
ut is
an
impl
emen
tatio
n is
sue
V1
Arc
hite
ctur
e1.
5.2
Ver
ify th
at s
eria
lizat
ion
is n
ot u
sed
whe
n co
mm
unic
atin
g w
ith u
ntru
sted
clie
nts.
If
this
is n
ot p
ossi
ble,
ens
ure
that
ade
quat
e in
tegr
ity c
ontro
ls (a
nd p
ossi
bly
encr
yptio
n if
sens
itive
dat
a is
sen
t) ar
e en
forc
ed to
pre
vent
des
eria
lizat
ion
atta
cks
incl
udin
g ob
ject
inje
ctio
n.X
X50
2V
1A
rchi
tect
ure
1.5.
3V
erify
that
inpu
t val
idat
ion
is e
nfor
ced
on a
trus
ted
serv
ice
laye
r. [C
5]X
X60
2
V1
Arc
hite
ctur
e1.
5.4
Ver
ify th
at o
utpu
t enc
odin
g oc
curs
clo
se to
or b
y th
e in
terp
rete
r for
whi
ch it
is
inte
nded
. [C
4]X
X11
6
V1
Arc
hite
ctur
e1.
6.2
Ver
ify th
at c
onsu
mer
s of
cry
ptog
raph
ic s
ervi
ces
prot
ect k
ey m
ater
ial a
nd o
ther
se
cret
s by
usi
ng k
ey v
aults
or A
PI b
ased
alte
rnat
ives
.X
X32
0P
ass
on th
eir e
nd, b
ut u
p to
the
impl
emen
tors
to
hand
le it
. Doe
snt i
nvol
ve th
e ba
cken
d.
V1
Arc
hite
ctur
e1.
6.3
Ver
ify th
at a
ll ke
ys a
nd p
assw
ords
are
repl
acea
ble
and
are
part
of a
wel
l-def
ined
pr
oces
s to
re-e
ncry
pt s
ensi
tive
data
.X
X32
0
Task
to fi
x th
is
is o
n m
y to
do
list.
Issu
e is
cr
eate
d an
d tra
cked
.
C1-
C10
Top
10
Proa
ctiv
e C
ontr
ols:
http
s://w
ww
.ow
asp.
org/
inde
x.ph
p/O
WA
SP_P
roac
tive_
Con
trol
s#ta
b=Fo
rmal
_Num
berin
g)25
8/28
612
2/25
814
6/25
84/
258
174/
258
79
V1
Arc
hite
ctur
e1.
6.4
Ver
ify th
at s
ymm
etric
key
s, p
assw
ords
, or A
PI s
ecre
ts g
ener
ated
by
or s
hare
d w
ith c
lient
s ar
e us
ed o
nly
in p
rote
ctin
g lo
w ri
sk s
ecre
ts, s
uch
as e
ncry
ptin
g lo
cal
stor
age,
or t
empo
rary
eph
emer
al u
ses
such
as
para
met
er o
bfus
catio
n. S
harin
g se
cret
s w
ith c
lient
s is
cle
ar-te
xt e
quiv
alen
t and
arc
hite
ctur
ally
sho
uld
be tr
eate
d as
su
ch.
XX
320
V1
Arc
hite
ctur
e1.
7.1
Ver
ify th
at a
com
mon
logg
ing
form
at a
nd a
ppro
ach
is u
sed
acro
ss th
e sy
stem
. [C
9]X
X10
09
V1
Arc
hite
ctur
e1.
7.2
Ver
ify th
at lo
gs a
re s
ecur
ely
trans
mitt
ed to
a p
refe
rabl
y re
mot
e sy
stem
for
anal
ysis
, det
ectio
n, a
lerti
ng, a
nd e
scal
atio
n. [C
9]X
X
Lack
ing
tool
s/co
nfig
to
send
logs
to
rem
ote
stor
age
V1
Arc
hite
ctur
e1.
8.1
Ver
ify th
at a
ll se
nsiti
ve d
ata
is id
entif
ied
and
clas
sifie
d in
to p
rote
ctio
n le
vels
.X
X
V1
Arc
hite
ctur
e1.
8.2
Ver
ify th
at a
ll pr
otec
tion
leve
ls h
ave
an a
ssoc
iate
d se
t of p
rote
ctio
n re
quire
men
ts,
such
as
encr
yptio
n re
quire
men
ts, i
nteg
rity
requ
irem
ents
, ret
entio
n, p
rivac
y an
d ot
her c
onfid
entia
lity
requ
irem
ents
, and
that
thes
e ar
e ap
plie
d in
the
arch
itect
ure.
XX
V1
Arc
hite
ctur
e1.
9.1
Ver
ify th
e ap
plic
atio
n en
cryp
ts c
omm
unic
atio
ns b
etw
een
com
pone
nts,
par
ticul
arly
w
hen
thes
e co
mpo
nent
s ar
e in
diff
eren
t con
tain
ers,
sys
tem
s, s
ites,
or c
loud
pr
ovid
ers.
[C3]
XX
319
Sup
port
for u
sing
http
s an
d ss
l, bu
t als
o im
plem
enta
tion
V1
Arc
hite
ctur
e1.
9.2
Ver
ify th
at a
pplic
atio
n co
mpo
nent
s ve
rify
the
auth
entic
ity o
f eac
h si
de in
a
com
mun
icat
ion
link
to p
reve
nt p
erso
n-in
-the-
mid
dle
atta
cks.
For
exa
mpl
e,
appl
icat
ion
com
pone
nts
shou
ld v
alid
ate
TLS
cer
tific
ates
and
cha
ins.
XX
295
Hav
e su
ppor
t for
TLS
, but
uns
ure
if th
ey v
alid
ate
certi
ficat
es
V1
Arc
hite
ctur
e1.
10.1
Ver
ify th
at a
sou
rce
code
con
trol s
yste
m is
in u
se, w
ith p
roce
dure
s to
ens
ure
that
ch
eck-
ins
are
acco
mpa
nied
by
issu
es o
r cha
nge
ticke
ts. T
he s
ourc
e co
de c
ontro
l sy
stem
sho
uld
have
acc
ess
cont
rol a
nd id
entif
iabl
e us
ers
to a
llow
trac
eabi
lity
of
any
chan
ges.
XX
284
V1
Arc
hite
ctur
e1.
11.1
Ver
ify th
e de
finiti
on a
nd d
ocum
enta
tion
of a
ll ap
plic
atio
n co
mpo
nent
s in
term
s of
th
e bu
sine
ss o
r sec
urity
func
tions
they
pro
vide
.X
X10
59
V1
Arc
hite
ctur
e1.
11.2
Ver
ify th
at a
ll hi
gh-v
alue
bus
ines
s lo
gic
flow
s, in
clud
ing
auth
entic
atio
n, s
essi
on
man
agem
ent a
nd a
cces
s co
ntro
l, do
not
sha
re u
nsyn
chro
nize
d st
ate.
XX
362
V1
Arc
hite
ctur
e1.
11.3
Ver
ify th
at a
ll hi
gh-v
alue
bus
ines
s lo
gic
flow
s, in
clud
ing
auth
entic
atio
n, s
essi
on
man
agem
ent a
nd a
cces
s co
ntro
l are
thre
ad s
afe
and
resi
stan
t to
time-
of-c
heck
an
d tim
e-of
-use
race
con
ditio
ns.
X36
7D
ont h
ave
race
con
ditio
ns p
osib
litie
s in
acc
ess
cont
rols
. Eve
ryth
ing
is d
one
in o
ne th
read
.V
1A
rchi
tect
ure
1.12
.1V
erify
that
use
r-up
load
ed fi
les
are
stor
ed o
utsi
de o
f the
web
root
.X
X55
2
V1
Arc
hite
ctur
e1.
12.2
Ver
ify th
at u
ser-
uplo
aded
file
s - i
f req
uire
d to
be
disp
laye
d or
dow
nloa
ded
from
the
appl
icat
ion
- are
ser
ved
by e
ither
oct
et s
tream
dow
nloa
ds, o
r fro
m a
n un
rela
ted
dom
ain,
suc
h as
a c
loud
file
sto
rage
buc
ket.
Impl
emen
t a s
uita
ble
cont
ent s
ecur
ity
polic
y to
redu
ce th
e ris
k fro
m X
SS
vec
tors
or o
ther
atta
cks
from
the
uplo
aded
file
.X
X64
6P
art p
ass,
par
t fai
l
V1
Arc
hite
ctur
e1.
14.3
Ver
ify th
at th
e bu
ild p
ipel
ine
war
ns o
f out
-of-d
ate
or in
secu
re c
ompo
nent
s an
d ta
kes
appr
opria
te a
ctio
ns.
XX
1104
V1
Arc
hite
ctur
e1.
14.4
Ver
ify th
at th
e bu
ild p
ipel
ine
cont
ains
a b
uild
ste
p to
aut
omat
ical
ly b
uild
and
ver
ify
the
secu
re d
eplo
ymen
t of t
he a
pplic
atio
n, p
artic
ular
ly if
the
appl
icat
ion
infra
stru
ctur
e is
sof
twar
e de
fined
, suc
h as
clo
ud e
nviro
nmen
t bui
ld s
crip
ts.
XX
V1
Arc
hite
ctur
e1.
14.6
Ver
ify th
e ap
plic
atio
n do
es n
ot u
se u
nsup
porte
d, in
secu
re, o
r dep
reca
ted
clie
nt-
side
tech
nolo
gies
suc
h as
NS
AP
I plu
gins
, Fla
sh, S
hock
wav
e, A
ctiv
eX, S
ilver
light
, N
AC
L, o
r clie
nt-s
ide
Java
app
lets
.X
X47
7
Do
not u
se a
ny o
f the
se th
ings
, but
hav
e cl
ient
te
chno
logi
es th
at th
ey k
now
are
inse
quec
e, b
ut th
at
they
are
wor
king
on
secu
ring
Not
sur
e, fr
ont-
end
only
issu
e
V2
Aut
hent
icat
ion
2.1.
1V
erify
that
use
r set
pas
swor
ds a
re a
t lea
st 1
2 ch
arac
ters
in le
ngth
. [C
6]X
XX
521
5.1.
1.2
You
can
con
figur
e it
to b
e 12
cha
ract
ers.
V2
Aut
hent
icat
ion
2.1.
2V
erify
that
pas
swor
ds 6
4 ch
arac
ters
or l
onge
r are
per
mitt
ed. [
C6]
XX
X52
15.
1.1.
2
V2
Aut
hent
icat
ion
2.1.
3V
erify
that
pas
swor
ds c
an c
onta
in s
pace
s an
d tru
ncat
ion
is n
ot p
erfo
rmed
. C
onse
cutiv
e m
ultip
le s
pace
s M
AY
opt
iona
lly b
e co
ales
ced.
[C6]
XX
X52
15.
1.1.
2
V2
Aut
hent
icat
ion
2.1.
4
Ver
ify th
at U
nico
de c
hara
cter
s ar
e pe
rmitt
ed in
pas
swor
ds. A
sin
gle
Uni
code
cod
e po
int i
s co
nsid
ered
a c
hara
cter
, so
12 e
moj
i or 6
4 ka
nji c
hara
cter
s sh
ould
be
valid
an
d pe
rmitt
ed.
XX
X52
15.
1.1.
2
V2
Aut
hent
icat
ion
2.1.
5V
erify
use
rs c
an c
hang
e th
eir p
assw
ord.
XX
X62
05.
1.1.
2
V2
Aut
hent
icat
ion
2.1.
6V
erify
that
pas
swor
d ch
ange
func
tiona
lity
requ
ires
the
user
's c
urre
nt a
nd n
ew
pass
wor
d.X
XX
620
5.1.
1.2
V2
Aut
hent
icat
ion
2.1.
7
Ver
ify th
at p
assw
ords
sub
mitt
ed d
urin
g ac
coun
t reg
istra
tion,
logi
n, a
nd p
assw
ord
chan
ge a
re c
heck
ed a
gain
st a
set
of b
reac
hed
pass
wor
ds e
ither
loca
lly (s
uch
as
the
top
1,00
0 or
10,
000
mos
t com
mon
pas
swor
ds w
hich
mat
ch th
e sy
stem
's
pass
wor
d po
licy)
or u
sing
an
exte
rnal
AP
I. If
usin
g an
AP
I a z
ero
know
ledg
e pr
oof
or o
ther
mec
hani
sm s
houl
d be
use
d to
ens
ure
that
the
plai
n te
xt p
assw
ord
is n
ot
sent
or u
sed
in v
erify
ing
the
brea
ch s
tatu
s of
the
pass
wor
d. If
the
pass
wor
d is
br
each
ed, t
he a
pplic
atio
n m
ust r
equi
re th
e us
er to
set
a n
ew n
on-b
reac
hed
pass
wor
d. [C
6]X
XX
521
5.1.
1.2
V2
Aut
hent
icat
ion
2.1.
8V
erify
that
a p
assw
ord
stre
ngth
met
er is
pro
vide
d to
hel
p us
ers
set a
stro
nger
pa
ssw
ord.
XX
X52
15.
1.1.
2
C1-
C10
Top
10
Proa
ctiv
e C
ontr
ols:
http
s://w
ww
.ow
asp.
org/
inde
x.ph
p/O
WA
SP_P
roac
tive_
Con
trol
s#ta
b=Fo
rmal
_Num
berin
g)25
8/28
612
2/25
814
6/25
84/
258
174/
258
79
V2
Aut
hent
icat
ion
2.1.
9
Ver
ify th
at th
ere
are
no p
assw
ord
com
posi
tion
rule
s lim
iting
the
type
of c
hara
cter
s pe
rmitt
ed. T
here
sho
uld
be n
o re
quire
men
t for
upp
er o
r low
er c
ase
or n
umbe
rs o
r sp
ecia
l cha
ract
ers.
[C6]
XX
X52
15.
1.1.
2S
houl
d ha
ve th
e po
ssib
lity
to re
mov
e th
e co
nfig
urat
ion
in th
e fu
ture
V2
Aut
hent
icat
ion
2.1.
10V
erify
that
ther
e ar
e no
per
iodi
c cr
eden
tial r
otat
ion
or p
assw
ord
hist
ory
requ
irem
ents
.X
XX
263
5.1.
1.2
Sho
uld
be
fail
acco
rdin
g to
: http
s://d
ocs.
dhis
2.or
g/m
aste
r/en
/use
r/htm
l/dhi
s2_u
ser_
man
ual_
en_
full.
htm
l#pa
ssw
ord-
requ
irem
ents
Can
opt
out
V2
Aut
hent
icat
ion
2.1.
11V
erify
that
"pas
te" f
unct
iona
lity,
bro
wse
r pas
swor
d he
lper
s, a
nd e
xter
nal p
assw
ord
man
ager
s ar
e pe
rmitt
ed.
XX
X52
15.
1.1.
2
V2
Aut
hent
icat
ion
2.1.
12
Ver
ify th
at th
e us
er c
an c
hoos
e to
eith
er te
mpo
raril
y vi
ew th
e en
tire
mas
ked
pass
wor
d, o
r tem
pora
rily
view
the
last
type
d ch
arac
ter o
f the
pas
swor
d on
pl
atfo
rms
that
do
not h
ave
this
as
nativ
e fu
nctio
nalit
y.X
XX
521
5.1.
1.2
V2
Aut
hent
icat
ion
2.2.
1
Ver
ify th
at a
nti-a
utom
atio
n co
ntro
ls a
re e
ffect
ive
at m
itiga
ting
brea
ched
cre
dent
ial
test
ing,
bru
te fo
rce,
and
acc
ount
lock
out a
ttack
s. S
uch
cont
rols
incl
ude
bloc
king
th
e m
ost c
omm
on b
reac
hed
pass
wor
ds, s
oft l
ocko
uts,
rate
lim
iting
, CA
PTC
HA
, ev
er in
crea
sing
del
ays
betw
een
atte
mpt
s, IP
add
ress
rest
rictio
ns, o
r ris
k-ba
sed
rest
rictio
ns s
uch
as lo
catio
n, fi
rst l
ogin
on
a de
vice
, rec
ent a
ttem
pts
to u
nloc
k th
e ac
coun
t, or
sim
ilar.
Ver
ify th
at n
o m
ore
than
100
faile
d at
tem
pts
per h
our i
s po
ssib
le o
n a
sing
le a
ccou
nt.
XX
X30
7
5.2.
2 /
5.1.
1.2
/ 5.
1.4.
2 /
5.1.
5.2
Hav
e po
ssib
lity
to o
pt-in
and
use
CA
PTC
HA
V2
Aut
hent
icat
ion
2.2.
2
Ver
ify th
at th
e us
e of
wea
k au
then
ticat
ors
(suc
h as
SM
S a
nd e
mai
l) is
lim
ited
to
seco
ndar
y ve
rific
atio
n an
d tra
nsac
tion
appr
oval
and
not
as
a re
plac
emen
t for
m
ore
secu
re a
uthe
ntic
atio
n m
etho
ds. V
erify
that
stro
nger
met
hods
are
offe
red
befo
re w
eak
met
hods
, use
rs a
re a
war
e of
the
risks
, or t
hat p
rope
r mea
sure
s ar
e in
pla
ce to
lim
it th
e ris
ks o
f acc
ount
com
prom
ise.
XX
X30
45.
2.10
V2
Aut
hent
icat
ion
2.2.
3
Ver
ify th
at s
ecur
e no
tific
atio
ns a
re s
ent t
o us
ers
afte
r upd
ates
to a
uthe
ntic
atio
n de
tails
, suc
h as
cre
dent
ial r
eset
s, e
mai
l or a
ddre
ss c
hang
es, l
oggi
ng in
from
un
know
n or
risk
y lo
catio
ns. T
he u
se o
f pus
h no
tific
atio
ns -
rath
er th
an S
MS
or
emai
l - is
pre
ferr
ed, b
ut in
the
abse
nce
of p
ush
notif
icat
ions
, SM
S o
r em
ail i
s ac
cept
able
as
long
as
no s
ensi
tive
info
rmat
ion
is d
iscl
osed
in th
e no
tific
atio
n.X
XX
620
V2
Aut
hent
icat
ion
2.2.
4
Ver
ify im
pers
onat
ion
resi
stan
ce a
gain
st p
hish
ing,
suc
h as
the
use
of m
ulti-
fact
or
auth
entic
atio
n, c
rypt
ogra
phic
dev
ices
with
inte
nt (s
uch
as c
onne
cted
key
s w
ith a
pu
sh to
aut
hent
icat
e), o
r at h
ighe
r AA
L le
vels
, clie
nt-s
ide
certi
ficat
es.
X30
85.
2.5
Hav
e th
e po
ssib
lity
to e
nale
mul
ti-fa
ctor
.
V2
Aut
hent
icat
ion
2.2.
5
Ver
ify th
at w
here
a c
rede
ntia
l ser
vice
pro
vide
r (C
SP
) and
the
appl
icat
ion
verif
ying
au
then
ticat
ion
are
sepa
rate
d, m
utua
lly a
uthe
ntic
ated
TLS
is in
pla
ce b
etw
een
the
two
endp
oint
s.X
319
5.2.
6
V2
Aut
hent
icat
ion
2.2.
7V
erify
inte
nt to
aut
hent
icat
e by
requ
iring
the
entry
of a
n O
TP to
ken
or u
ser-
initi
ated
act
ion
such
as
a bu
tton
pres
s on
a F
IDO
har
dwar
e ke
y.X
308
5.2.
9
V2
Aut
hent
icat
ion
2.3.
1
Ver
ify s
yste
m g
ener
ated
initi
al p
assw
ords
or a
ctiv
atio
n co
des
SH
OU
LD b
e se
cure
ly ra
ndom
ly g
ener
ated
, SH
OU
LD b
e at
leas
t 6 c
hara
cter
s lo
ng, a
nd M
AY
co
ntai
n le
tters
and
num
bers
, and
exp
ire a
fter a
sho
rt pe
riod
of ti
me.
The
se in
itial
se
cret
s m
ust n
ot b
e pe
rmitt
ed to
bec
ome
the
long
term
pas
swor
d.X
XX
330
5.1.
1.2
/ A.3
Don
't ha
ve s
yste
m g
ener
ated
pas
swor
ds, b
ut u
nsur
e
V2
Aut
hent
icat
ion
2.3.
2V
erify
that
enr
ollm
ent a
nd u
se o
f sub
scrib
er-p
rovi
ded
auth
entic
atio
n de
vice
s ar
e su
ppor
ted,
suc
h as
a U
2F o
r FID
O to
kens
.X
X30
86.
1.3
V2
Aut
hent
icat
ion
2.3.
3V
erify
that
rene
wal
inst
ruct
ions
are
sen
t with
suf
ficie
nt ti
me
to re
new
tim
e bo
und
auth
entic
ator
s.X
X28
76.
1.4
V2
Aut
hent
icat
ion
2.4.
1
Ver
ify th
at p
assw
ords
are
sto
red
in a
form
that
is re
sist
ant t
o of
fline
atta
cks.
P
assw
ords
SH
ALL
be
salte
d an
d ha
shed
usi
ng a
n ap
prov
ed o
ne-w
ay k
ey
deriv
atio
n or
pas
swor
d ha
shin
g fu
nctio
n. K
ey d
eriv
atio
n an
d pa
ssw
ord
hash
ing
func
tions
take
a p
assw
ord,
a s
alt,
and
a co
st fa
ctor
as
inpu
ts w
hen
gene
ratin
g a
pass
wor
d ha
sh. [
C6]
XX
916
5.1.
1.2
V2
Aut
hent
icat
ion
2.4.
2
Ver
ify th
at th
e sa
lt is
at l
east
32
bits
in le
ngth
and
be
chos
en a
rbitr
arily
to m
inim
ize
salt
valu
e co
llisi
ons
amon
g st
ored
has
hes.
For
eac
h cr
eden
tial,
a un
ique
sal
t va
lue
and
the
resu
lting
has
h S
HA
LL b
e st
ored
. [C
6]X
X91
65.
1.1.
2W
e us
e a
diffe
rent
fram
ewor
k, S
prin
t Sec
urity
. Don
't do
the
last
bit.
V2
Aut
hent
icat
ion
2.4.
3V
erify
that
if P
BK
DF2
is u
sed,
the
itera
tion
coun
t SH
OU
LD b
e as
larg
e as
ve
rific
atio
n se
rver
per
form
ance
will
allo
w, t
ypic
ally
at l
east
100
,000
iter
atio
ns. [
C6]
XX
916
5.1.
1.2
V2
Aut
hent
icat
ion
2.4.
4V
erify
that
if b
cryp
t is
used
, the
wor
k fa
ctor
SH
OU
LD b
e as
larg
e as
ver
ifica
tion
serv
er p
erfo
rman
ce w
ill a
llow
, typ
ical
ly a
t lea
st 1
3. [C
6]X
X91
65.
1.1.
2
Fail,
use
s de
faul
t tha
t is
10. C
an't
curr
ently
be
conf
igur
ed
eith
er.
C1-
C10
Top
10
Proa
ctiv
e C
ontr
ols:
http
s://w
ww
.ow
asp.
org/
inde
x.ph
p/O
WA
SP_P
roac
tive_
Con
trol
s#ta
b=Fo
rmal
_Num
berin
g)25
8/28
612
2/25
814
6/25
84/
258
174/
258
79
V2
Aut
hent
icat
ion
2.5.
1V
erify
that
a s
yste
m g
ener
ated
initi
al a
ctiv
atio
n or
reco
very
sec
ret i
s no
t sen
t in
clea
r tex
t to
the
user
. [C
6]X
XX
640
5.1.
1.2
Sen
t in
clea
r tex
tS
ent i
t in
clea
r tex
t by
mai
l.
V2
Aut
hent
icat
ion
2.5.
2V
erify
pas
swor
d hi
nts
or k
now
ledg
e-ba
sed
auth
entic
atio
n (s
o-ca
lled
"sec
ret
ques
tions
") a
re n
ot p
rese
nt.
XX
X64
05.
1.1.
2
V2
Aut
hent
icat
ion
2.5.
3V
erify
pas
swor
d cr
eden
tial r
ecov
ery
does
not
reve
al th
e cu
rren
t pas
swor
d in
any
w
ay. [
C6]
XX
X64
05.
1.1.
2
V2
Aut
hent
icat
ion
2.5.
4V
erify
sha
red
or d
efau
lt ac
coun
ts a
re n
ot p
rese
nt (e
.g. "
root
", "a
dmin
", or
"sa"
).X
XX
165.
1.1.
2 / A
.3
V2
Aut
hent
icat
ion
2.5.
5V
erify
that
if a
n au
then
ticat
ion
fact
or is
cha
nged
or r
epla
ced,
that
the
user
is
notif
ied
of th
is e
vent
.X
XX
304
6.1.
2.3
Don
t not
ify w
hen
thin
gs c
hang
e.
V2
Aut
hent
icat
ion
2.5.
6
Ver
ify fo
rgot
ten
pass
wor
d, a
nd o
ther
reco
very
pat
hs u
se a
sec
ure
reco
very
m
echa
nism
, suc
h as
TO
TP o
r oth
er s
oft t
oken
, mob
ile p
ush,
or a
noth
er o
fflin
e re
cove
ry m
echa
nism
. [C
6]X
XX
640
5.1.
1.2
V2
Aut
hent
icat
ion
2.5.
7V
erify
that
if O
TP o
r mul
ti-fa
ctor
aut
hent
icat
ion
fact
ors
are
lost
, tha
t evi
denc
e of
id
entit
y pr
oofin
g is
per
form
ed a
t the
sam
e le
vel a
s du
ring
enro
llmen
t.X
X30
86.
1.2.
3Im
plem
enta
tion
beca
use
the
way
you
reco
ver i
s th
at
you
get i
n to
uch
with
the
syst
em a
dmin
stra
tor.
V2
Aut
hent
icat
ion
2.7.
1
Ver
ify th
at c
lear
text
out
of b
and
(NIS
T "r
estri
cted
") a
uthe
ntic
ator
s, s
uch
as S
MS
or
PS
TN, a
re n
ot o
ffere
d by
def
ault,
and
stro
nger
alte
rnat
ives
suc
h as
pus
h no
tific
atio
ns a
re o
ffere
d fir
st.
XX
X28
75.
1.3.
2
V2
Aut
hent
icat
ion
2.7.
2V
erify
that
the
out o
f ban
d ve
rifie
r exp
ires
out o
f ban
d au
then
ticat
ion
requ
ests
, co
des,
or t
oken
s af
ter 1
0 m
inut
es.
XX
X28
75.
1.3.
2
V2
Aut
hent
icat
ion
2.7.
3V
erify
that
the
out o
f ban
d ve
rifie
r aut
hent
icat
ion
requ
ests
, cod
es, o
r tok
ens
are
only
usa
ble
once
, and
onl
y fo
r the
orig
inal
aut
hent
icat
ion
requ
est.
XX
X28
75.
1.3.
2
V2
Aut
hent
icat
ion
2.7.
4V
erify
that
the
out o
f ban
d au
then
ticat
or a
nd v
erifi
er c
omm
unic
ates
ove
r a s
ecur
e in
depe
nden
t cha
nnel
.X
XX
523
5.1.
3.2
V2
Aut
hent
icat
ion
2.7.
5V
erify
that
the
out o
f ban
d ve
rifie
r ret
ains
onl
y a
hash
ed v
ersi
on o
f the
au
then
ticat
ion
code
.X
X25
65.
1.3.
2
V2
Aut
hent
icat
ion
2.7.
6
Ver
ify th
at th
e in
itial
aut
hent
icat
ion
code
is g
ener
ated
by
a se
cure
rand
om n
umbe
r ge
nera
tor,
cont
aini
ng a
t lea
st 2
0 bi
ts o
f ent
ropy
(typ
ical
ly a
six
dig
ital r
ando
m
num
ber i
s su
ffici
ent).
XX
310
5.1.
3.2
V2
Aut
hent
icat
ion
2.8.
3V
erify
that
app
rove
d cr
ypto
grap
hic
algo
rithm
s ar
e us
ed in
the
gene
ratio
n, s
eedi
ng,
and
verif
icat
ion.
XX
326
5.1.
4.2
/ 5.
1.5.
2
V2
Aut
hent
icat
ion
2.9.
3V
erify
that
app
rove
d cr
ypto
grap
hic
algo
rithm
s ar
e us
ed in
the
gene
ratio
n, s
eedi
ng,
and
verif
icat
ion.
XX
327
5.1.
7.2
V2
Aut
hent
icat
ion
2.10
.1V
erify
that
inte
grat
ion
secr
ets
do n
ot re
ly o
n un
chan
ging
pas
swor
ds, s
uch
as A
PI
keys
or s
hare
d pr
ivile
ged
acco
unts
.
OS
as
sist
ed
HS
M28
75.
1.1.
1
V2
Aut
hent
icat
ion
2.10
.2V
erify
that
if p
assw
ords
are
requ
ired,
the
cred
entia
ls a
re n
ot a
def
ault
acco
unt.
OS
as
sist
ed
HS
M25
55.
1.1.
1
V2
Aut
hent
icat
ion
2.10
.3V
erify
that
pas
swor
ds a
re s
tore
d w
ith s
uffic
ient
pro
tect
ion
to p
reve
nt o
fflin
e re
cove
ry a
ttack
s, in
clud
ing
loca
l sys
tem
acc
ess.
OS
as
sist
ed
HS
M52
25.
1.1.
1H
ashe
d.
V2
Aut
hent
icat
ion
2.10
.4
Ver
ify p
assw
ords
, int
egra
tions
with
dat
abas
es a
nd th
ird-p
arty
sys
tem
s, s
eeds
and
in
tern
al s
ecre
ts, a
nd A
PI k
eys
are
man
aged
sec
urel
y an
d no
t inc
lude
d in
the
sour
ce c
ode
or s
tore
d w
ithin
sou
rce
code
repo
sito
ries.
Suc
h st
orag
e S
HO
ULD
re
sist
offl
ine
atta
cks.
The
use
of a
sec
ure
softw
are
key
stor
e (L
1), h
ardw
are
trust
ed p
latfo
rm m
odul
e (T
PM
), or
a h
ardw
are
secu
rity
mod
ule
(L3)
is
reco
mm
ende
d fo
r pas
swor
d st
orag
e.
OS
as
sist
ed
HS
M79
8H
ave
an e
xter
nal c
onfig
for t
his,
but
impl
emen
tors
are
in
cha
rge
of u
sing
it c
orre
ctly
.
V3
Ses
sion
3.1.
1V
erify
the
appl
icat
ion
neve
r rev
eals
ses
sion
toke
ns in
UR
L pa
ram
eter
s or
err
or
mes
sage
s.X
XX
598
V3
Ses
sion
3.2.
1V
erify
the
appl
icat
ion
gene
rate
s a
new
ses
sion
toke
n on
use
r aut
hent
icat
ion.
[C6]
XX
X38
47.
1V
3S
essi
on3.
2.2
Ver
ify th
at s
essi
on to
kens
pos
sess
at l
east
64
bits
of e
ntro
py. [
C6]
XX
X33
17.
1
V3
Ses
sion
3.2.
3
Ver
ify th
e ap
plic
atio
n on
ly s
tore
s se
ssio
n to
kens
in th
e br
owse
r usi
ng s
ecur
e m
etho
ds s
uch
as a
ppro
pria
tely
sec
ured
coo
kies
(see
sec
tion
3.4)
or H
TML
5 se
ssio
n st
orag
e.X
XX
539
7.1
Not
don
e in
co
re, b
ut
only
in th
e im
lem
enta
tion
sid
e.
Pro
vide
gu
idel
ines
.
V3
Ses
sion
3.2.
4V
erify
that
ses
sion
toke
n ar
e ge
nera
ted
usin
g ap
prov
ed c
rypt
ogra
phic
alg
orith
ms.
[C
6]X
X33
17.
1
V3
Ses
sion
3.3.
1
Ver
ify th
at lo
gout
and
exp
iratio
n in
valid
ate
the
sess
ion
toke
n, s
uch
that
the
back
bu
tton
or a
dow
nstre
am re
lyin
g pa
rty d
oes
not r
esum
e an
aut
hent
icat
ed s
essi
on,
incl
udin
g ac
ross
rely
ing
parti
es. [
C6]
XX
X61
37.
1
C1-
C10
Top
10
Proa
ctiv
e C
ontr
ols:
http
s://w
ww
.ow
asp.
org/
inde
x.ph
p/O
WA
SP_P
roac
tive_
Con
trol
s#ta
b=Fo
rmal
_Num
berin
g)25
8/28
612
2/25
814
6/25
84/
258
174/
258
79
V3
Ses
sion
3.3.
2If
auth
entic
ator
s pe
rmit
user
s to
rem
ain
logg
ed in
, ver
ify th
at re
-aut
hent
icat
ion
occu
rs p
erio
dica
lly b
oth
whe
n ac
tivel
y us
ed o
r afte
r an
idle
per
iod.
[C6]
30
day
s
12
hou
rs
or
30
min
ute
s of
in
activ
ity,
2F
A
opti
ona
l
12
hour
s or
15
m
inu
tes
of
inac
tivi
ty,
with
2F
A61
37.
2
V3
Ses
sion
3.3.
3
Ver
ify th
at th
e ap
plic
atio
n te
rmin
ates
all
othe
r act
ive
sess
ions
afte
r a s
ucce
ssfu
l pa
ssw
ord
chan
ge, a
nd th
at th
is is
effe
ctiv
e ac
ross
the
appl
icat
ion,
fede
rate
d lo
gin
(if p
rese
nt),
and
any
rely
ing
parti
es.
XX
613
V3
Ses
sion
3.3.
4V
erify
that
use
rs a
re a
ble
to v
iew
and
log
out o
f any
or a
ll cu
rren
tly a
ctiv
e se
ssio
ns
and
devi
ces.
XX
613
7.1
Onl
y w
hen
you
term
inat
e a
sess
ion,
not
sel
ectiv
e.V
3S
essi
on3.
4.1
Ver
ify th
at c
ooki
e-ba
sed
sess
ion
toke
ns h
ave
the
'Sec
ure'
attr
ibut
e se
t. [C
6]X
XX
614
7.1.
1V
3S
essi
on3.
4.2
Ver
ify th
at c
ooki
e-ba
sed
sess
ion
toke
ns h
ave
the
'Http
Onl
y' a
ttrib
ute
set.
[C6]
XX
X10
047.
1.1
V3
Ses
sion
3.4.
3V
erify
that
coo
kie-
base
d se
ssio
n to
kens
util
ize
the
'Sam
eSite
' attr
ibut
e to
lim
it ex
posu
re to
cro
ss-s
ite re
ques
t for
gery
atta
cks.
[C6]
XX
X16
7.1.
1
Not
don
e in
co
re, b
ut
only
in th
e im
lem
enta
tion
sid
e.
Pro
vide
gu
idel
ines
.
V3
Ses
sion
3.4.
4V
erify
that
coo
kie-
base
d se
ssio
n to
kens
use
"__H
ost-"
pre
fix (s
ee re
fere
nces
) to
prov
ide
sess
ion
cook
ie c
onfid
entia
lity.
XX
X16
7.1.
1
V3
Ses
sion
3.4.
5
Ver
ify th
at if
the
appl
icat
ion
is p
ublis
hed
unde
r a d
omai
n na
me
with
oth
er
appl
icat
ions
that
set
or u
se s
essi
on c
ooki
es th
at m
ight
ove
rrid
e or
dis
clos
e th
e se
ssio
n co
okie
s, s
et th
e pa
th a
ttrib
ute
in c
ooki
e-ba
sed
sess
ion
toke
ns u
sing
the
mos
t pre
cise
pat
h po
ssib
le. [
C6]
XX
X16
7.1.
1
V3
Ses
sion
3.5.
1
Ver
ify th
e ap
plic
atio
n do
es n
ot tr
eat O
Aut
h an
d re
fresh
toke
ns &
mda
sh; o
n th
eir
own
&m
dash
; as
the
pres
ence
of t
he s
ubsc
riber
and
allo
ws
user
s to
term
inat
e tru
st re
latio
nshi
ps w
ith li
nked
app
licat
ions
.X
X29
07.
1.2
V3
Ses
sion
3.5.
2V
erify
the
appl
icat
ion
uses
ses
sion
toke
ns ra
ther
than
sta
tic A
PI s
ecre
ts a
nd k
eys,
ex
cept
with
lega
cy im
plem
enta
tions
.X
X79
8
V3
Ses
sion
3.6.
1
Ver
ify th
at re
lyin
g pa
rties
spe
cify
the
max
imum
aut
hent
icat
ion
time
to C
SP
s an
d th
at C
SP
s re
-aut
hent
icat
e th
e su
bscr
iber
if th
ey h
aven
't us
ed a
ses
sion
with
in th
at
perio
d.X
613
7.2.
1
V3
Ses
sion
3.6.
2V
erify
that
CS
Ps
info
rm re
lyin
g pa
rties
of t
he la
st a
uthe
ntic
atio
n ev
ent,
to a
llow
R
Ps
to d
eter
min
e if
they
nee
d to
re-a
uthe
ntic
ate
the
user
.X
613
7.2.
1
V3
Ses
sion
3.7.
1
Ver
ify th
e ap
plic
atio
n en
sure
s a
valid
logi
n se
ssio
n or
requ
ires
re-a
uthe
ntic
atio
n or
se
cond
ary
verif
icat
ion
befo
re a
llow
ing
any
sens
itive
tran
sact
ions
or a
ccou
nt
mod
ifica
tions
.X
XX
778
Fail
(bei
ng d
iscu
ssed
).
V4
Acc
ess
4.1.
1V
erify
that
the
appl
icat
ion
enfo
rces
acc
ess
cont
rol r
ules
on
a tru
sted
ser
vice
laye
r, es
peci
ally
if c
lient
-sid
e ac
cess
con
trol i
s pr
esen
t and
cou
ld b
e by
pass
ed.
XX
X60
2
V4
Acc
ess
4.1.
2V
erify
that
all
user
and
dat
a at
tribu
tes
and
polic
y in
form
atio
n us
ed b
y ac
cess
co
ntro
ls c
anno
t be
man
ipul
ated
by
end
user
s un
less
spe
cific
ally
aut
horiz
ed.
XX
X63
9
V4
Acc
ess
4.1.
3
Ver
ify th
at th
e pr
inci
ple
of le
ast p
rivile
ge e
xist
s - u
sers
sho
uld
only
be
able
to
acce
ss fu
nctio
ns, d
ata
files
, UR
Ls, c
ontro
llers
, ser
vice
s, a
nd o
ther
reso
urce
s, fo
r w
hich
they
pos
sess
spe
cific
aut
horiz
atio
n. T
his
impl
ies
prot
ectio
n ag
ains
t spo
ofin
g an
d el
evat
ion
of p
rivile
ge. [
C7]
XX
X28
5
V4
Acc
ess
4.1.
4
Ver
ify th
at th
e pr
inci
ple
of d
eny
by d
efau
lt ex
ists
whe
reby
new
use
rs/ro
les
star
t w
ith m
inim
al o
r no
perm
issi
ons
and
user
s/ro
les
do n
ot re
ceiv
e ac
cess
to n
ew
feat
ures
unt
il ac
cess
is e
xplic
itly
assi
gned
. [C
7]X
XX
276
V4
Acc
ess
4.1.
5V
erify
that
acc
ess
cont
rols
fail
secu
rely
incl
udin
g w
hen
an e
xcep
tion
occu
rs. [
C10
]X
XX
285
V4
Acc
ess
4.2.
1
Ver
ify th
at s
ensi
tive
data
and
AP
Is a
re p
rote
cted
aga
inst
dire
ct o
bjec
t atta
cks
targ
etin
g cr
eatio
n, re
adin
g, u
pdat
ing
and
dele
tion
of re
cord
s, s
uch
as c
reat
ing
or
upda
ting
som
eone
els
e's
reco
rd, v
iew
ing
ever
yone
's re
cord
s, o
r del
etin
g al
l re
cord
s.X
XX
639
V4
Acc
ess
4.2.
2
Ver
ify th
at th
e ap
plic
atio
n or
fram
ewor
k en
forc
es a
stro
ng a
nti-C
SR
F m
echa
nism
to
pro
tect
aut
hent
icat
ed fu
nctio
nalit
y, a
nd e
ffect
ive
anti-
auto
mat
ion
or a
nti-C
SR
F pr
otec
ts u
naut
hent
icat
ed fu
nctio
nalit
y.X
XX
352
V4
Acc
ess
4.3.
1V
erify
adm
inis
trativ
e in
terfa
ces
use
appr
opria
te m
ulti-
fact
or a
uthe
ntic
atio
n to
pr
even
t una
utho
rized
use
.X
XX
419
C1-
C10
Top
10
Proa
ctiv
e C
ontr
ols:
http
s://w
ww
.ow
asp.
org/
inde
x.ph
p/O
WA
SP_P
roac
tive_
Con
trol
s#ta
b=Fo
rmal
_Num
berin
g)25
8/28
612
2/25
814
6/25
84/
258
174/
258
79
V4
Acc
ess
4.3.
2
Ver
ify th
at d
irect
ory
brow
sing
is d
isab
led
unle
ss d
elib
erat
ely
desi
red.
Add
ition
ally
, ap
plic
atio
ns s
houl
d no
t allo
w d
isco
very
or d
iscl
osur
e of
file
or d
irect
ory
met
adat
a,
such
as
Thum
bs.d
b, .D
S_S
tore
, .gi
t or .
svn
fold
ers.
XX
X54
8
V4
Acc
ess
4.3.
3
Ver
ify th
e ap
plic
atio
n ha
s ad
ditio
nal a
utho
rizat
ion
(suc
h as
ste
p up
or a
dapt
ive
auth
entic
atio
n) fo
r low
er v
alue
sys
tem
s, a
nd /
or s
egre
gatio
n of
dut
ies
for h
igh
valu
e ap
plic
atio
ns to
enf
orce
ant
i-fra
ud c
ontro
ls a
s pe
r the
risk
of a
pplic
atio
n an
d pa
st fr
aud.
XX
732
V5
Val
idat
ion
5.1.
1
Ver
ify th
at th
e ap
plic
atio
n ha
s de
fens
es a
gain
st H
TTP
par
amet
er p
ollu
tion
atta
cks,
par
ticul
arly
if th
e ap
plic
atio
n fra
mew
ork
mak
es n
o di
stin
ctio
n ab
out t
he
sour
ce o
f req
uest
par
amet
ers
(GE
T, P
OS
T, c
ooki
es, h
eade
rs, o
r env
ironm
ent
varia
bles
).X
XX
235
V5
Val
idat
ion
5.1.
2
Ver
ify th
at fr
amew
orks
pro
tect
aga
inst
mas
s pa
ram
eter
ass
ignm
ent a
ttack
s, o
r th
at th
e ap
plic
atio
n ha
s co
unte
rmea
sure
s to
pro
tect
aga
inst
uns
afe
para
met
er
assi
gnm
ent,
such
as
mar
king
fiel
ds p
rivat
e or
sim
ilar.
[C5]
XX
X91
5
V5
Val
idat
ion
5.1.
3
Ver
ify th
at a
ll in
put (
HTM
L fo
rm fi
elds
, RE
ST
requ
ests
, UR
L pa
ram
eter
s, H
TTP
he
ader
s, c
ooki
es, b
atch
file
s, R
SS
feed
s, e
tc) i
s va
lidat
ed u
sing
pos
itive
val
idat
ion
(whi
telis
ting)
. [C
5]X
XX
20
V5
Val
idat
ion
5.1.
4
Ver
ify th
at s
truct
ured
dat
a is
stro
ngly
type
d an
d va
lidat
ed a
gain
st a
def
ined
sc
hem
a in
clud
ing
allo
wed
cha
ract
ers,
leng
th a
nd p
atte
rn (e
.g. c
redi
t car
d nu
mbe
rs
or te
leph
one,
or v
alid
atin
g th
at tw
o re
late
d fie
lds
are
reas
onab
le, s
uch
as
chec
king
that
sub
urb
and
zip/
post
code
mat
ch).
[C5]
XX
X20
V5
Val
idat
ion
5.1.
5V
erify
that
UR
L re
dire
cts
and
forw
ards
onl
y al
low
whi
telis
ted
dest
inat
ions
, or s
how
a
war
ning
whe
n re
dire
ctin
g to
pot
entia
lly u
ntru
sted
con
tent
.X
XX
601
V5
Val
idat
ion
5.2.
1V
erify
that
all
untru
sted
HTM
L in
put f
rom
WY
SIW
YG
edi
tors
or s
imila
r is
prop
erly
sa
nitiz
ed w
ith a
n H
TML
sani
tizer
libr
ary
or fr
amew
ork
feat
ure.
[C5]
XX
X11
6
V5
Val
idat
ion
5.2.
2V
erify
that
uns
truct
ured
dat
a is
san
itize
d to
enf
orce
saf
ety
mea
sure
s su
ch a
s al
low
ed c
hara
cter
s an
d le
ngth
.X
XX
138
V5
Val
idat
ion
5.2.
3V
erify
that
the
appl
icat
ion
sani
tizes
use
r inp
ut b
efor
e pa
ssin
g to
mai
l sys
tem
s to
pr
otec
t aga
inst
SM
TP o
r IM
AP
inje
ctio
n.X
XX
147
Pro
babl
y do
n't h
ave
sani
tizat
ion.
V5
Val
idat
ion
5.2.
4
Ver
ify th
at th
e ap
plic
atio
n av
oids
the
use
of e
val()
or o
ther
dyn
amic
cod
e ex
ecut
ion
feat
ures
. Whe
re th
ere
is n
o al
tern
ativ
e, a
ny u
ser i
nput
bei
ng in
clud
ed
mus
t be
sani
tized
or s
andb
oxed
bef
ore
bein
g ex
ecut
ed.
XX
X95
Lim
ited
in w
hat y
ou c
an d
o w
ith th
e dy
nam
ics
code
ex
ecut
ion.
V5
Val
idat
ion
5.2.
5V
erify
that
the
appl
icat
ion
prot
ects
aga
inst
tem
plat
e in
ject
ion
atta
cks
by e
nsur
ing
that
any
use
r inp
ut b
eing
incl
uded
is s
aniti
zed
or s
andb
oxed
.X
XX
94
V5
Val
idat
ion
5.2.
6
Ver
ify th
at th
e ap
plic
atio
n pr
otec
ts a
gain
st S
SR
F at
tack
s, b
y va
lidat
ing
or
sani
tizin
g un
trust
ed d
ata
or H
TTP
file
met
adat
a, s
uch
as fi
lena
mes
and
UR
L in
put
field
s, u
se w
hite
listin
g of
pro
toco
ls, d
omai
ns, p
aths
and
por
ts.
XX
X91
8
V5
Val
idat
ion
5.2.
7
Ver
ify th
at th
e ap
plic
atio
n sa
nitiz
es, d
isab
les,
or s
andb
oxes
use
r-su
pplie
d S
VG
sc
ripta
ble
cont
ent,
espe
cial
ly a
s th
ey re
late
to X
SS
resu
lting
from
inlin
e sc
ripts
, an
d fo
reig
nObj
ect.
XX
X15
9
V5
Val
idat
ion
5.2.
8
Ver
ify th
at th
e ap
plic
atio
n sa
nitiz
es, d
isab
les,
or s
andb
oxes
use
r-su
pplie
d sc
ripta
ble
or e
xpre
ssio
n te
mpl
ate
lang
uage
con
tent
, suc
h as
Mar
kdow
n, C
SS
or
XS
L st
yles
heet
s, B
BC
ode,
or s
imila
r.X
XX
94D
on't
do s
atin
izat
ion
/ fro
nten
d
V5
Val
idat
ion
5.3.
1
Ver
ify th
at o
utpu
t enc
odin
g is
rele
vant
for t
he in
terp
rete
r and
con
text
requ
ired.
For
ex
ampl
e, u
se e
ncod
ers
spec
ifica
lly fo
r HTM
L va
lues
, HTM
L at
tribu
tes,
Jav
aScr
ipt,
UR
L P
aram
eter
s, H
TTP
hea
ders
, SM
TP, a
nd o
ther
s as
the
cont
ext r
equi
res,
es
peci
ally
from
unt
rust
ed in
puts
(e.g
. nam
es w
ith U
nico
de o
r apo
stro
phes
, suc
h as
ねこ
or O
'Har
a). [
C4]
XX
X11
6
V5
Val
idat
ion
5.3.
2V
erify
that
out
put e
ncod
ing
pres
erve
s th
e us
er's
cho
sen
char
acte
r set
and
loca
le,
such
that
any
Uni
code
cha
ract
er p
oint
is v
alid
and
saf
ely
hand
led.
[C4]
XX
X17
6
V5
Val
idat
ion
5.3.
3V
erify
that
con
text
-aw
are,
pre
fera
bly
auto
mat
ed -
or a
t wor
st, m
anua
l - o
utpu
t es
capi
ng p
rote
cts
agai
nst r
efle
cted
, sto
red,
and
DO
M b
ased
XS
S. [
C4]
XX
X79
V5
Val
idat
ion
5.3.
4
Ver
ify th
at d
ata
sele
ctio
n or
dat
abas
e qu
erie
s (e
.g. S
QL,
HQ
L, O
RM
, NoS
QL)
use
pa
ram
eter
ized
que
ries,
OR
Ms,
ent
ity fr
amew
orks
, or a
re o
ther
wis
e pr
otec
ted
from
da
taba
se in
ject
ion
atta
cks.
[C3]
XX
X89
V5
Val
idat
ion
5.3.
5
Ver
ify th
at w
here
par
amet
eriz
ed o
r saf
er m
echa
nism
s ar
e no
t pre
sent
, con
text
-sp
ecifi
c ou
tput
enc
odin
g is
use
d to
pro
tect
aga
inst
inje
ctio
n at
tack
s, s
uch
as th
e us
e of
SQ
L es
capi
ng to
pro
tect
aga
inst
SQ
L in
ject
ion.
[C3,
C4]
XX
X89
V5
Val
idat
ion
5.3.
6
Ver
ify th
at th
e ap
plic
atio
n pr
ojec
ts a
gain
st J
avaS
crip
t or J
SO
N in
ject
ion
atta
cks,
in
clud
ing
for e
val a
ttack
s, re
mot
e Ja
vaS
crip
t inc
lude
s, C
SP
byp
asse
s, D
OM
XS
S,
and
Java
Scr
ipt e
xpre
ssio
n ev
alua
tion.
[C4]
XX
X83
0
V5
Val
idat
ion
5.3.
7V
erify
that
the
appl
icat
ion
prot
ects
aga
inst
LD
AP
Inje
ctio
n vu
lner
abili
ties,
or t
hat
spec
ific
secu
rity
cont
rols
to p
reve
nt L
DA
P In
ject
ion
have
bee
n im
plem
ente
d. [C
4]X
XX
943
V5
Val
idat
ion
5.3.
8
Ver
ify th
at th
e ap
plic
atio
n pr
otec
ts a
gain
st O
S c
omm
and
inje
ctio
n an
d th
at
oper
atin
g sy
stem
cal
ls u
se p
aram
eter
ized
OS
que
ries
or u
se c
onte
xtua
l com
man
d lin
e ou
tput
enc
odin
g. [C
4]X
XX
78
V5
Val
idat
ion
5.3.
9V
erify
that
the
appl
icat
ion
prot
ects
aga
inst
Loc
al F
ile In
clus
ion
(LFI
) or R
emot
e Fi
le In
clus
ion
(RFI
) atta
cks.
XX
X82
9
C1-
C10
Top
10
Proa
ctiv
e C
ontr
ols:
http
s://w
ww
.ow
asp.
org/
inde
x.ph
p/O
WA
SP_P
roac
tive_
Con
trol
s#ta
b=Fo
rmal
_Num
berin
g)25
8/28
612
2/25
814
6/25
84/
258
174/
258
79
V5
Val
idat
ion
5.3.
10V
erify
that
the
appl
icat
ion
prot
ects
aga
inst
XP
ath
inje
ctio
n or
XM
L in
ject
ion
atta
cks.
[C4]
XX
X64
3
V5
Val
idat
ion
5.4.
1V
erify
that
the
appl
icat
ion
uses
mem
ory-
safe
stri
ng, s
afer
mem
ory
copy
and
po
inte
r arit
hmet
ic to
det
ect o
r pre
vent
sta
ck, b
uffe
r, or
hea
p ov
erflo
ws.
XX
120
V5
Val
idat
ion
5.4.
2V
erify
that
form
at s
tring
s do
not
take
pot
entia
lly h
ostil
e in
put,
and
are
cons
tant
.X
X13
4
V5
Val
idat
ion
5.4.
3V
erify
that
sig
n, ra
nge,
and
inpu
t val
idat
ion
tech
niqu
es a
re u
sed
to p
reve
nt in
tege
r ov
erflo
ws.
XX
190
Pos
sibl
y no
t rel
evan
t for
Jav
a.
V5
Val
idat
ion
5.5.
1V
erify
that
ser
ializ
ed o
bjec
ts u
se in
tegr
ity c
heck
s or
are
enc
rypt
ed to
pre
vent
ho
stile
obj
ect c
reat
ion
or d
ata
tam
perin
g. [C
5]X
XX
502
V5
Val
idat
ion
5.5.
2
Ver
ify th
at th
e ap
plic
atio
n co
rrec
tly re
stric
ts X
ML
pars
ers
to o
nly
use
the
mos
t re
stric
tive
conf
igur
atio
n po
ssib
le a
nd to
ens
ure
that
uns
afe
feat
ures
suc
h as
re
solv
ing
exte
rnal
ent
ities
are
dis
able
d to
pre
vent
XX
E.
XX
X61
1
V5
Val
idat
ion
5.5.
3V
erify
that
des
eria
lizat
ion
of u
ntru
sted
dat
a is
avo
ided
or i
s pr
otec
ted
in b
oth
cust
om c
ode
and
third
-par
ty li
brar
ies
(suc
h as
JS
ON
, XM
L an
d Y
AM
L pa
rser
s).
XX
X50
2A
ll th
at is
use
r sup
plie
d, s
o in
that
sen
se it
is tr
uste
d si
nce
user
s ne
ed to
log
in
V5
Val
idat
ion
5.5.
4V
erify
that
whe
n pa
rsin
g JS
ON
in b
row
sers
or J
avaS
crip
t-bas
ed b
acke
nds,
JS
ON
.pa
rse
is u
sed
to p
arse
the
JSO
N d
ocum
ent.
Do
not u
se e
val()
to p
arse
JS
ON
.X
XX
95
V6
Cry
ptog
raph
y6.
1.1
Ver
ify th
at re
gula
ted
priv
ate
data
is s
tore
d en
cryp
ted
whi
le a
t res
t, su
ch a
s pe
rson
ally
iden
tifia
ble
info
rmat
ion
(PII)
, sen
sitiv
e pe
rson
al in
form
atio
n, o
r dat
a as
sess
ed li
kely
to b
e su
bjec
t to
EU
's G
DP
R.
XX
311
V6
Cry
ptog
raph
y6.
1.2
Ver
ify th
at re
gula
ted
heal
th d
ata
is s
tore
d en
cryp
ted
whi
le a
t res
t, su
ch a
s m
edic
al
reco
rds,
med
ical
dev
ice
deta
ils, o
r de-
anon
ymiz
ed re
sear
ch re
cord
s.X
X31
1H
ave
the
abili
ty to
enc
rypt
the
data
by
an a
ttrib
utes
ba
sis
V6
Cry
ptog
raph
y6.
1.3
Ver
ify th
at re
gula
ted
finan
cial
dat
a is
sto
red
encr
ypte
d w
hile
at r
est,
such
as
finan
cial
acc
ount
s, d
efau
lts o
r cre
dit h
isto
ry, t
ax re
cord
s, p
ay h
isto
ry,
bene
ficia
ries,
or d
e-an
onym
ized
mar
ket o
r res
earc
h re
cord
s.X
X31
1D
on't
wor
k w
ith ju
st h
ealth
dat
a, c
an b
e ot
her f
orm
s of
da
ta. I
mpl
emen
tatio
n is
sue
V6
Cry
ptog
raph
y6.
2.1
Ver
ify th
at a
ll cr
ypto
grap
hic
mod
ules
fail
secu
rely
, and
err
ors
are
hand
led
in a
way
th
at d
oes
not e
nabl
e P
addi
ng O
racl
e at
tack
s.X
XX
310
V6
Cry
ptog
raph
y6.
2.2
Ver
ify th
at in
dust
ry p
rove
n or
gov
ernm
ent a
ppro
ved
cryp
togr
aphi
c al
gorit
hms,
m
odes
, and
libr
arie
s ar
e us
ed, i
nste
ad o
f cus
tom
cod
ed c
rypt
ogra
phy.
[C8]
XX
327
V6
Cry
ptog
raph
y6.
2.3
Ver
ify th
at e
ncry
ptio
n in
itial
izat
ion
vect
or, c
iphe
r con
figur
atio
n, a
nd b
lock
mod
es
are
conf
igur
ed s
ecur
ely
usin
g th
e la
test
adv
ice.
XX
326
V6
Cry
ptog
raph
y6.
2.4
Ver
ify th
at ra
ndom
num
ber,
encr
yptio
n or
has
hing
alg
orith
ms,
key
leng
ths,
roun
ds,
ciph
ers
or m
odes
, can
be
reco
nfig
ured
, upg
rade
d, o
r sw
appe
d at
any
tim
e, to
pr
otec
t aga
inst
cry
ptog
raph
ic b
reak
s. [C
8]X
X32
6H
ave
the
abili
ty to
reco
nfig
ure
and
swap
V6
Cry
ptog
raph
y6.
2.5
Ver
ify th
at k
now
n in
secu
re b
lock
mod
es (i
.e. E
CB
, etc
.), p
addi
ng m
odes
(i.e
. P
KC
S#1
v1.
5, e
tc.),
cip
hers
with
sm
all b
lock
siz
es (i
.e. T
riple
-DE
S, B
low
fish,
etc
.),
and
wea
k ha
shin
g al
gorit
hms
(i.e.
MD
5, S
HA
1, e
tc.)
are
not u
sed
unle
ss re
quire
d fo
r bac
kwar
ds c
ompa
tibili
ty.
XX
326
Use
AE
S
V6
Cry
ptog
raph
y6.
2.6
Ver
ify th
at n
once
s, in
itial
izat
ion
vect
ors,
and
oth
er s
ingl
e us
e nu
mbe
rs m
ust n
ot
be u
sed
mor
e th
an o
nce
with
a g
iven
enc
rypt
ion
key.
The
met
hod
of g
ener
atio
n m
ust b
e ap
prop
riate
for t
he a
lgor
ithm
bei
ng u
sed.
XX
326
V6
Cry
ptog
raph
y6.
2.8
Ver
ify th
at a
ll cr
ypto
grap
hic
oper
atio
ns a
re c
onst
ant-t
ime,
with
no
'sho
rt-ci
rcui
t' op
erat
ions
in c
ompa
rison
s, c
alcu
latio
ns, o
r ret
urns
, to
avoi
d le
akin
g in
form
atio
n.X
385
V6
Cry
ptog
raph
y6.
3.1
Ver
ify th
at a
ll ra
ndom
num
bers
, ran
dom
file
nam
es, r
ando
m G
UID
s, a
nd ra
ndom
st
rings
are
gen
erat
ed u
sing
the
cryp
togr
aphi
c m
odul
e's
appr
oved
cr
ypto
grap
hica
lly s
ecur
e ra
ndom
num
ber g
ener
ator
whe
n th
ese
rand
om v
alue
s ar
e in
tend
ed to
be
not g
uess
able
by
an a
ttack
er.
XX
338
Fail
for n
o sp
ecifi
c cr
ypto
mod
ule
is u
sed
to g
ener
ate
thes
e th
ings
V6
Cry
ptog
raph
y6.
3.2
Ver
ify th
at ra
ndom
GU
IDs
are
crea
ted
usin
g th
e G
UID
v4
algo
rithm
, and
a
cryp
togr
aphi
cally
-sec
ure
pseu
do-r
ando
m n
umbe
r gen
erat
or (C
SP
RN
G).
GU
IDs
crea
ted
usin
g ot
her p
seud
o-ra
ndom
num
ber g
ener
ator
s m
ay b
e pr
edic
tabl
e.X
X33
8
V6
Cry
ptog
raph
y6.
3.3
Ver
ify th
at ra
ndom
num
bers
are
cre
ated
with
pro
per e
ntro
py e
ven
whe
n th
e ap
plic
atio
n is
und
er h
eavy
load
, or t
hat t
he a
pplic
atio
n de
grad
es g
race
fully
in s
uch
circ
umst
ance
s.X
338
V6
Cry
ptog
raph
y6.
4.1
Ver
ify th
at a
sec
rets
man
agem
ent s
olut
ion
such
as
a ke
y va
ult i
s us
ed to
sec
urel
y cr
eate
, sto
re, c
ontro
l acc
ess
to a
nd d
estro
y se
cret
s. [C
8]X
X79
8
V6
Cry
ptog
raph
y6.
4.2
Ver
ify th
at k
ey m
ater
ial i
s no
t exp
osed
to th
e ap
plic
atio
n bu
t ins
tead
use
s an
is
olat
ed s
ecur
ity m
odul
e lik
e a
vaul
t for
cry
ptog
raph
ic o
pera
tions
. [C
8]X
X32
0
V7
Err
or7.
1.1
Ver
ify th
at th
e ap
plic
atio
n do
es n
ot lo
g cr
eden
tials
or p
aym
ent d
etai
ls. S
essi
on
toke
ns s
houl
d on
ly b
e st
ored
in lo
gs in
an
irrev
ersi
ble,
has
hed
form
. [C
9, C
10]
XX
X53
2
V7
Err
or7.
1.2
Ver
ify th
at th
e ap
plic
atio
n do
es n
ot lo
g ot
her s
ensi
tive
data
as
defin
ed u
nder
loca
l pr
ivac
y la
ws
or re
leva
nt s
ecur
ity p
olic
y. [C
9]X
XX
532
V7
Err
or7.
1.3
Ver
ify th
at th
e ap
plic
atio
n lo
gs s
ecur
ity re
leva
nt e
vent
s in
clud
ing
succ
essf
ul a
nd
faile
d au
then
ticat
ion
even
ts, a
cces
s co
ntro
l fai
lure
s, d
eser
ializ
atio
n fa
ilure
s an
d in
put v
alid
atio
n fa
ilure
s. [C
5, C
7]X
X77
8
V7
Err
or7.
1.4
Ver
ify th
at e
ach
log
even
t inc
lude
s ne
cess
ary
info
rmat
ion
that
wou
ld a
llow
for a
de
taile
d in
vest
igat
ion
of th
e tim
elin
e w
hen
an e
vent
hap
pens
. [C
9]X
X77
8U
nsur
e on
how
com
plet
e th
e in
form
atio
n is
V7
Err
or7.
2.1
Ver
ify th
at a
ll au
then
ticat
ion
deci
sion
s ar
e lo
gged
, with
out s
torin
g se
nsiti
ve
sess
ion
iden
tifie
rs o
r pas
swor
ds. T
his
shou
ld in
clud
e re
ques
ts w
ith re
leva
nt
met
adat
a ne
eded
for s
ecur
ity in
vest
igat
ions
.X
X77
8
C1-
C10
Top
10
Proa
ctiv
e C
ontr
ols:
http
s://w
ww
.ow
asp.
org/
inde
x.ph
p/O
WA
SP_P
roac
tive_
Con
trol
s#ta
b=Fo
rmal
_Num
berin
g)25
8/28
612
2/25
814
6/25
84/
258
174/
258
79
V7
Err
or7.
2.2
Ver
ify th
at a
ll ac
cess
con
trol d
ecis
ions
can
be
logg
ed a
nd a
ll fa
iled
deci
sion
s ar
e lo
gged
. Thi
s sh
ould
incl
ude
requ
ests
with
rele
vant
met
adat
a ne
eded
for s
ecur
ity
inve
stig
atio
ns.
XX
285
V7
Err
or7.
3.1
Ver
ify th
at th
e ap
plic
atio
n ap
prop
riate
ly e
ncod
es u
ser-
supp
lied
data
to p
reve
nt lo
g in
ject
ion.
[C9]
XX
117
V7
Err
or7.
3.2
Ver
ify th
at a
ll ev
ents
are
pro
tect
ed fr
om in
ject
ion
whe
n vi
ewed
in lo
g vi
ewin
g so
ftwar
e. [C
9]X
X11
7
V7
Err
or7.
3.3
Ver
ify th
at s
ecur
ity lo
gs a
re p
rote
cted
from
una
utho
rized
acc
ess
and
mod
ifica
tion.
[C
9]X
X20
0
V7
Err
or7.
3.4
Ver
ify th
at ti
me
sour
ces
are
sync
hron
ized
to th
e co
rrec
t tim
e an
d tim
e zo
ne.
Stro
ngly
con
side
r log
ging
onl
y in
UTC
if s
yste
ms
are
glob
al to
ass
ist w
ith p
ost-
inci
dent
fore
nsic
ana
lysi
s. [C
9]X
X
V7
Err
or7.
4.1
Ver
ify th
at a
gen
eric
mes
sage
is s
how
n w
hen
an u
nexp
ecte
d or
sec
urity
sen
sitiv
e er
ror o
ccur
s, p
oten
tially
with
a u
niqu
e ID
whi
ch s
uppo
rt pe
rson
nel c
an u
se to
in
vest
igat
e. [
C10
]X
XX
210
V7
Err
or7.
4.2
Ver
ify th
at e
xcep
tion
hand
ling
(or a
func
tiona
l equ
ival
ent)
is u
sed
acro
ss th
e co
deba
se to
acc
ount
for e
xpec
ted
and
unex
pect
ed e
rror
con
ditio
ns. [
C10
]X
X54
4
V7
Err
or7.
4.3
Ver
ify th
at a
"las
t res
ort"
erro
r han
dler
is d
efin
ed w
hich
will
cat
ch a
ll un
hand
led
exce
ptio
ns. [
C10
]X
X46
0
V8
Dat
a8.
1.1
Ver
ify th
e ap
plic
atio
n pr
otec
ts s
ensi
tive
data
from
bei
ng c
ache
d in
ser
ver
com
pone
nts
such
as
load
bal
ance
rs a
nd a
pplic
atio
n ca
ches
.X
X52
4Fa
il, b
ut is
als
o an
impl
emen
tatio
n re
spon
sbili
ty. D
on't
have
a w
ay s
peci
fy th
ings
are
sen
sitiv
e.
V8
Dat
a8.
1.3
Ver
ify th
e ap
plic
atio
n m
inim
izes
the
num
ber o
f par
amet
ers
in a
requ
est,
such
as
hidd
en fi
elds
, Aja
x va
riabl
es, c
ooki
es a
nd h
eade
r val
ues.
XX
233
V8
Dat
a8.
1.4
Ver
ify th
e ap
plic
atio
n ca
n de
tect
and
ale
rt on
abn
orm
al n
umbe
rs o
f req
uest
s, s
uch
as b
y IP
, use
r, to
tal p
er h
our o
r day
, or w
hate
ver m
akes
sen
se fo
r the
app
licat
ion.
XX
770
Don
't ha
ve th
is fo
r the
AP
I, on
ly fo
r log
in a
nd
pass
wor
d re
cove
ry.
V8
Dat
a8.
2.1
Ver
ify th
e ap
plic
atio
n se
ts s
uffic
ient
ant
i-cac
hing
hea
ders
so
that
sen
sitiv
e da
ta is
no
t cac
hed
in m
oder
n br
owse
rs.
XX
X52
5
V8
Dat
a8.
2.2
Ver
ify th
at d
ata
stor
ed in
clie
nt s
ide
stor
age
(suc
h as
HTM
L5 lo
cal s
tora
ge,
sess
ion
stor
age,
Inde
xedD
B, r
egul
ar c
ooki
es o
r Fla
sh c
ooki
es) d
oes
not c
onta
in
sens
itive
dat
a or
PII.
XX
X92
2
V8
Dat
a8.
2.3
Ver
ify th
at a
uthe
ntic
ated
dat
a is
cle
ared
from
clie
nt s
tora
ge, s
uch
as th
e br
owse
r D
OM
, afte
r the
clie
nt o
r ses
sion
is te
rmin
ated
.X
XX
922
V8
Dat
a8.
3.1
Ver
ify th
at s
ensi
tive
data
is s
ent t
o th
e se
rver
in th
e H
TTP
mes
sage
bod
y or
he
ader
s, a
nd th
at q
uery
stri
ng p
aram
eter
s fro
m a
ny H
TTP
ver
b do
not
con
tain
se
nsiti
ve d
ata.
XX
X31
9V
8D
ata
8.3.
2V
erify
that
use
rs h
ave
a m
etho
d to
rem
ove
or e
xpor
t the
ir da
ta o
n de
man
d.X
XX
212
Can
exp
ort a
ll da
ta o
n de
man
d.
V8
Dat
a8.
3.3
Ver
ify th
at u
sers
are
pro
vide
d cl
ear l
angu
age
rega
rdin
g co
llect
ion
and
use
of
supp
lied
pers
onal
info
rmat
ion
and
that
use
rs h
ave
prov
ided
opt
-in c
onse
nt fo
r the
us
e of
that
dat
a be
fore
it is
use
d in
any
way
.X
XX
285
V8
Dat
a8.
3.5
Ver
ify a
cces
sing
sen
sitiv
e da
ta is
aud
ited
(with
out l
oggi
ng th
e se
nsiti
ve d
ata
itsel
f), if
the
data
is c
olle
cted
und
er re
leva
nt d
ata
prot
ectio
n di
rect
ives
or w
here
lo
ggin
g of
acc
ess
is re
quire
d.X
X53
2
V8
Dat
a8.
3.6
Ver
ify th
at s
ensi
tive
info
rmat
ion
cont
aine
d in
mem
ory
is o
verw
ritte
n as
soo
n as
it
is n
o lo
nger
requ
ired
to m
itiga
te m
emor
y du
mpi
ng a
ttack
s, u
sing
zer
oes
or
rand
om d
ata.
XX
226
Diff
icul
t for
you
can
't kn
ow h
ow to
cla
ssify
sen
sitiv
e da
ta.
V8
Dat
a8.
3.7
Ver
ify th
at s
ensi
tive
or p
rivat
e in
form
atio
n th
at is
requ
ired
to b
e en
cryp
ted,
is
encr
ypte
d us
ing
appr
oved
alg
orith
ms
that
pro
vide
bot
h co
nfid
entia
lity
and
inte
grity
. [C
8]X
X32
7
V8
Dat
a8.
3.8
Ver
ify th
at s
ensi
tive
pers
onal
info
rmat
ion
is s
ubje
ct to
dat
a re
tent
ion
clas
sific
atio
n,
such
that
old
or o
ut o
f dat
e da
ta is
del
eted
aut
omat
ical
ly, o
n a
sche
dule
, or a
s th
e si
tuat
ion
requ
ires.
XX
285
V9
Com
mun
icat
ions
9.1.
1V
erify
that
sec
ured
TLS
is u
sed
for a
ll cl
ient
con
nect
ivity
, and
doe
s no
t fal
l bac
k to
in
secu
re o
r une
ncry
pted
pro
toco
ls. [
C8]
XX
X31
9H
ave
supp
ort t
o us
e TL
S a
nd S
SL
V9
Com
mun
icat
ions
9.1.
2
Ver
ify u
sing
onl
ine
or u
p to
dat
e TL
S te
stin
g to
ols
that
onl
y st
rong
alg
orith
ms,
ci
pher
s, a
nd p
roto
cols
are
ena
bled
, with
the
stro
nges
t alg
orith
ms
and
ciph
ers
set
as p
refe
rred
.X
XX
326
V9
Com
mun
icat
ions
9.1.
3
Ver
ify th
at o
ld v
ersi
ons
of S
SL
and
TLS
pro
toco
ls, a
lgor
ithm
s, c
iphe
rs, a
nd
conf
igur
atio
n ar
e di
sabl
ed, s
uch
as S
SLv
2, S
SLv
3, o
r TLS
1.0
and
TLS
1.1
. The
la
test
ver
sion
of T
LS s
houl
d be
the
pref
erre
d ci
pher
sui
te.
XX
X32
6
V9
Com
mun
icat
ions
9.2.
1
Ver
ify th
at c
onne
ctio
ns to
and
from
the
serv
er u
se tr
uste
d TL
S c
ertif
icat
es. W
here
in
tern
ally
gen
erat
ed o
r sel
f-sig
ned
certi
ficat
es a
re u
sed,
the
serv
er m
ust b
e co
nfig
ured
to o
nly
trust
spe
cific
inte
rnal
CA
s an
d sp
ecifi
c se
lf-si
gned
cer
tific
ates
. A
ll ot
hers
sho
uld
be re
ject
ed.
XX
295
V9
Com
mun
icat
ions
9.2.
2
Ver
ify th
at e
ncry
pted
com
mun
icat
ions
suc
h as
TLS
is u
sed
for a
ll in
boun
d an
d ou
tbou
nd c
onne
ctio
ns, i
nclu
ding
for m
anag
emen
t por
ts, m
onito
ring,
au
then
ticat
ion,
AP
I, or
web
ser
vice
cal
ls, d
atab
ase,
clo
ud, s
erve
rless
, mai
nfra
me,
ex
tern
al, a
nd p
artn
er c
onne
ctio
ns. T
he s
erve
r mus
t not
fall
back
to in
secu
re o
r un
encr
ypte
d pr
otoc
ols.
XX
319
C1-
C10
Top
10
Proa
ctiv
e C
ontr
ols:
http
s://w
ww
.ow
asp.
org/
inde
x.ph
p/O
WA
SP_P
roac
tive_
Con
trol
s#ta
b=Fo
rmal
_Num
berin
g)25
8/28
612
2/25
814
6/25
84/
258
174/
258
79
V9
Com
mun
icat
ions
9.2.
3V
erify
that
all
encr
ypte
d co
nnec
tions
to e
xter
nal s
yste
ms
that
invo
lve
sens
itive
in
form
atio
n or
func
tions
are
aut
hent
icat
ed.
XX
287
V9
Com
mun
icat
ions
9.2.
5V
erify
that
bac
kend
TLS
con
nect
ion
failu
res
are
logg
ed.
X54
4
V10
Mal
icio
us10
.1.1
Ver
ify th
at a
cod
e an
alys
is to
ol is
in u
se th
at c
an d
etec
t pot
entia
lly m
alic
ious
cod
e,
such
as
time
func
tions
, uns
afe
file
oper
atio
ns a
nd n
etw
ork
conn
ectio
ns.
X74
9
V10
Mal
icio
us10
.2.1
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
not
con
tain
un
auth
oriz
ed p
hone
hom
e or
dat
a co
llect
ion
capa
bilit
ies.
Whe
re s
uch
func
tiona
lity
exis
ts, o
btai
n th
e us
er's
per
mis
sion
for i
t to
oper
ate
bef
ore
colle
ctin
g an
y da
ta.
XX
359
Up
to im
plem
enta
tion
for w
e ha
ve th
e po
ssib
lity
to
inte
grat
ed g
oogl
e an
alyt
ics,
but
its
up to
them
who
m
ust g
et th
e us
er p
erm
issi
ons
for t
hat p
art.
V10
Mal
icio
us10
.2.2
Ver
ify th
at th
e ap
plic
atio
n do
es n
ot a
sk fo
r unn
eces
sary
or e
xces
sive
per
mis
sion
s to
priv
acy
rela
ted
feat
ures
or s
enso
rs, s
uch
as c
onta
cts,
cam
eras
, mic
roph
ones
, or
loca
tion.
XX
272
V10
Mal
icio
us10
.2.3
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
not
con
tain
bac
k do
ors,
suc
h as
har
d-co
ded
or a
dditi
onal
und
ocum
ente
d ac
coun
ts o
r key
s, c
ode
obfu
scat
ion,
und
ocum
ente
d bi
nary
blo
bs, r
ootk
its, o
r ant
i-deb
uggi
ng, i
nsec
ure
debu
ggin
g fe
atur
es, o
r oth
erw
ise
out o
f dat
e, in
secu
re, o
r hid
den
func
tiona
lity
that
co
uld
be u
sed
mal
icio
usly
if d
isco
vere
d.X
507
V10
Mal
icio
us10
.2.4
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
es n
ot c
onta
in
time
bom
bs b
y se
arch
ing
for d
ate
and
time
rela
ted
func
tions
.X
511
Don
't ch
eck
if th
e lib
rarie
s w
e ch
eck
outs
ide
of w
hat i
s au
tom
atic
ally
is a
vaila
ble
on th
e in
tern
et. I
f the
re a
re
gene
rate
d re
ports
from
the
libra
ries,
then
then
ther
e is
no
fail.
V10
Mal
icio
us10
.2.5
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
es n
ot c
onta
in
mal
icio
us c
ode,
suc
h as
sal
ami a
ttack
s, lo
gic
bypa
sses
, or l
ogic
bom
bs.
X51
1
Don
't ch
eck
if th
e lib
rarie
s w
e ch
eck
outs
ide
of w
hat i
s au
tom
atic
ally
is a
vaila
ble
on th
e in
tern
et. I
f the
re a
re
gene
rate
d re
ports
from
the
libra
ries,
then
then
ther
e is
no
fail.
V10
Mal
icio
us10
.2.6
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
not
con
tain
E
aste
r egg
s or
any
oth
er p
oten
tially
unw
ante
d fu
nctio
nalit
y.X
507
Don
't ch
eck
if th
e lib
rarie
s w
e ch
eck
outs
ide
of w
hat i
s au
tom
atic
ally
is a
vaila
ble
on th
e in
tern
et. I
f the
re a
re
gene
rate
d re
ports
from
the
libra
ries,
then
then
ther
e is
no
fail.
V10
Mal
icio
us10
.3.1
Ver
ify th
at if
the
appl
icat
ion
has
a cl
ient
or s
erve
r aut
o-up
date
feat
ure,
upd
ates
sh
ould
be
obta
ined
ove
r sec
ure
chan
nels
and
dig
itally
sig
ned.
The
upd
ate
code
m
ust v
alid
ate
the
digi
tal s
igna
ture
of t
he u
pdat
e be
fore
inst
allin
g or
exe
cutin
g th
e up
date
.X
XX
16
V10
Mal
icio
us10
.3.2
Ver
ify th
at th
e ap
plic
atio
n em
ploy
s in
tegr
ity p
rote
ctio
ns, s
uch
as c
ode
sign
ing
or
sub-
reso
urce
inte
grity
. The
app
licat
ion
mus
t not
load
or e
xecu
te c
ode
from
un
trust
ed s
ourc
es, s
uch
as lo
adin
g in
clud
es, m
odul
es, p
lugi
ns, c
ode,
or l
ibra
ries
from
unt
rust
ed s
ourc
es o
r the
Inte
rnet
.X
XX
353
Pas
s fo
r the
bac
k en
d, b
ut fo
r the
cus
tom
app
s th
is
may
be
an is
sue.
V10
Mal
icio
us10
.3.3
Ver
ify th
at th
e ap
plic
atio
n ha
s pr
otec
tion
from
sub
-dom
ain
take
over
s if
the
appl
icat
ion
relie
s up
on D
NS
ent
ries
or D
NS
sub
-dom
ains
, suc
h as
exp
ired
dom
ain
nam
es, o
ut o
f dat
e D
NS
poi
nter
s or
CN
AM
Es,
exp
ired
proj
ects
at p
ublic
sou
rce
code
repo
s, o
r tra
nsie
nt c
loud
AP
Is, s
erve
rless
func
tions
, or s
tora
ge b
ucke
ts
(aut
ogen
-buc
ket-i
d.cl
oud.
exam
ple.
com
) or s
imila
r. P
rote
ctio
ns c
an in
clud
e en
surin
g th
at D
NS
nam
es u
sed
by a
pplic
atio
ns a
re re
gula
rly c
heck
ed fo
r exp
iry o
r ch
ange
.X
XX
350
V11
Bus
Logi
c11
.1.1
Ver
ify th
e ap
plic
atio
n w
ill o
nly
proc
ess
busi
ness
logi
c flo
ws
for t
he s
ame
user
in
sequ
entia
l ste
p or
der a
nd w
ithou
t ski
ppin
g st
eps.
XX
X84
1
V11
Bus
Logi
c11
.1.2
Ver
ify th
e ap
plic
atio
n w
ill o
nly
proc
ess
busi
ness
logi
c flo
ws
with
all
step
s be
ing
proc
esse
d in
real
istic
hum
an ti
me,
i.e.
tran
sact
ions
are
not
sub
mitt
ed to
o qu
ickl
y.X
XX
779
V11
Bus
Logi
c11
.1.3
Ver
ify th
e ap
plic
atio
n ha
s ap
prop
riate
lim
its fo
r spe
cific
bus
ines
s ac
tions
or
trans
actio
ns w
hich
are
cor
rect
ly e
nfor
ced
on a
per
use
r bas
is.
XX
X77
0
V11
Bus
Logi
c11
.1.4
Ver
ify th
e ap
plic
atio
n ha
s su
ffici
ent a
nti-a
utom
atio
n co
ntro
ls to
det
ect a
nd p
rote
ct
agai
nst d
ata
exfil
tratio
n, e
xces
sive
bus
ines
s lo
gic
requ
ests
, exc
essi
ve fi
le u
ploa
ds
or d
enia
l of s
ervi
ce a
ttack
s.X
XX
770
V11
Bus
Logi
c11
.1.5
Ver
ify th
e ap
plic
atio
n ha
s bu
sine
ss lo
gic
limits
or v
alid
atio
n to
pro
tect
aga
inst
lik
ely
busi
ness
risk
s or
thre
ats,
iden
tifie
d us
ing
thre
at m
odel
ling
or s
imila
r m
etho
dolo
gies
.X
XX
841
V11
Bus
Logi
c11
.1.6
Ver
ify th
e ap
plic
atio
n do
es n
ot s
uffe
r fro
m "t
ime
of c
heck
to ti
me
of u
se"
(TO
CTO
U) i
ssue
s or
oth
er ra
ce c
ondi
tions
for s
ensi
tive
oper
atio
ns.
XX
367
Cou
ld b
e re
leva
nt fo
r pas
swor
d re
cove
ry. H
ad a
n is
sue
rece
ntly
that
was
fixe
d.
V11
Bus
Logi
c11
.1.8
Ver
ify th
e ap
plic
atio
n ha
s co
nfig
urab
le a
lerti
ng w
hen
auto
mat
ed a
ttack
s or
un
usua
l act
ivity
is d
etec
ted.
XX
390
V12
File
s12
.1.1
Ver
ify th
at th
e ap
plic
atio
n w
ill n
ot a
ccep
t lar
ge fi
les
that
cou
ld fi
ll up
sto
rage
or
caus
e a
deni
al o
f ser
vice
atta
ck.
XX
X40
0
V12
File
s12
.1.2
Ver
ify th
at c
ompr
esse
d fil
es a
re c
heck
ed fo
r "zi
p bo
mbs
" - s
mal
l inp
ut fi
les
that
will
de
com
pres
s in
to h
uge
files
thus
exh
aust
ing
file
stor
age
limits
.X
X40
9H
ave
no c
heck
on
it.
V12
File
s12
.1.3
Ver
ify th
at a
file
siz
e qu
ota
and
max
imum
num
ber o
f file
s pe
r use
r is
enfo
rced
to
ensu
re th
at a
sin
gle
user
can
not f
ill u
p th
e st
orag
e w
ith to
o m
any
files
, or
exce
ssiv
ely
larg
e fil
es.
XX
770
V12
File
s12
.2.1
Ver
ify th
at fi
les
obta
ined
from
unt
rust
ed s
ourc
es a
re v
alid
ated
to b
e of
exp
ecte
d ty
pe b
ased
on
the
file'
s co
nten
t.X
X43
4D
on't
valid
ate
all f
iles.
For
pic
ture
s, w
e ve
rify
that
it's
a
pict
ure
etc.
C1-
C10
Top
10
Proa
ctiv
e C
ontr
ols:
http
s://w
ww
.ow
asp.
org/
inde
x.ph
p/O
WA
SP_P
roac
tive_
Con
trol
s#ta
b=Fo
rmal
_Num
berin
g)25
8/28
612
2/25
814
6/25
84/
258
174/
258
79
V12
File
s12
.3.1
Ver
ify th
at u
ser-
subm
itted
file
nam
e m
etad
ata
is n
ot u
sed
dire
ctly
with
sys
tem
or
fram
ewor
k fil
e an
d U
RL
AP
I to
prot
ect a
gain
st p
ath
trave
rsal
.X
XX
22H
andl
ed b
y th
e ex
tern
al fr
amew
ork.
V12
File
s12
.3.2
Ver
ify th
at u
ser-
subm
itted
file
nam
e m
etad
ata
is v
alid
ated
or i
gnor
ed to
pre
vent
the
disc
losu
re, c
reat
ion,
upd
atin
g or
rem
oval
of l
ocal
file
s (L
FI).
XX
X73
V12
File
s12
.3.3
Ver
ify th
at u
ser-
subm
itted
file
nam
e m
etad
ata
is v
alid
ated
or i
gnor
ed to
pre
vent
the
disc
losu
re o
r exe
cutio
n of
rem
ote
files
(RFI
), w
hich
may
als
o le
ad to
SS
RF.
XX
X98
V12
File
s12
.3.4
Ver
ify th
at th
e ap
plic
atio
n pr
otec
ts a
gain
st re
flect
ive
file
dow
nloa
d (R
FD) b
y va
lidat
ing
or ig
norin
g us
er-s
ubm
itted
file
nam
es in
a J
SO
N, J
SO
NP
, or U
RL
para
met
er, t
he re
spon
se C
onte
nt-T
ype
head
er s
houl
d be
set
to te
xt/p
lain
, and
the
Con
tent
-Dis
posi
tion
head
er s
houl
d ha
ve a
fixe
d fil
enam
e.X
XX
641
V12
File
s12
.3.5
Ver
ify th
at u
ntru
sted
file
met
adat
a is
not
use
d di
rect
ly w
ith s
yste
m A
PI o
r lib
rarie
s,
to p
rote
ct a
gain
st O
S c
omm
and
inje
ctio
n.X
XX
78
V12
File
s12
.3.6
Ver
ify th
at th
e ap
plic
atio
n do
es n
ot in
clud
e an
d ex
ecut
e fu
nctio
nalit
y fro
m
untru
sted
sou
rces
, suc
h as
unv
erifi
ed c
onte
nt d
istri
butio
n ne
twor
ks, J
avaS
crip
t lib
rarie
s, n
ode
npm
libr
arie
s, o
r ser
ver-
side
DLL
s.X
X82
9
We
use
a lo
t of N
PM
lib
rarie
s,
thou
gh w
e at
tem
pt to
co
de
revi
ew th
e on
es w
e re
ly o
n.
V12
File
s12
.4.1
Ver
ify th
at fi
les
obta
ined
from
unt
rust
ed s
ourc
es a
re s
tore
d ou
tsid
e th
e w
eb ro
ot,
with
lim
ited
perm
issi
ons,
pre
fera
bly
with
stro
ng v
alid
atio
n.X
XX
922
V12
File
s12
.4.2
Ver
ify th
at fi
les
obta
ined
from
unt
rust
ed s
ourc
es a
re s
cann
ed b
y an
tiviru
s sc
anne
rs to
pre
vent
upl
oad
of k
now
n m
alic
ious
con
tent
.X
XX
509
V12
File
s12
.5.1
Ver
ify th
at th
e w
eb ti
er is
con
figur
ed to
ser
ve o
nly
files
with
spe
cific
file
ext
ensi
ons
to p
reve
nt u
nint
entio
nal i
nfor
mat
ion
and
sour
ce c
ode
leak
age.
For
exa
mpl
e,
back
up fi
les
(e.g
. .ba
k), t
empo
rary
wor
king
file
s (e
.g. .
swp)
, com
pres
sed
files
(.zi
p,
.tar.g
z, e
tc) a
nd o
ther
ext
ensi
ons
com
mon
ly u
sed
by e
dito
rs s
houl
d be
blo
cked
un
less
requ
ired.
XX
X55
2
V12
File
s12
.5.2
Ver
ify th
at d
irect
requ
ests
to u
ploa
ded
files
will
nev
er b
e ex
ecut
ed a
s H
TML/
Java
Scr
ipt c
onte
nt.
XX
X43
4
V12
File
s12
.6.1
Ver
ify th
at th
e w
eb o
r app
licat
ion
serv
er is
con
figur
ed w
ith a
whi
telis
t of r
esou
rces
or
sys
tem
s to
whi
ch th
e se
rver
can
sen
d re
ques
ts o
r loa
d da
ta/fi
les
from
.X
XX
918
impl
. ser
ver c
onfig
urat
ion
V13
AP
I13
.1.1
Ver
ify th
at a
ll ap
plic
atio
n co
mpo
nent
s us
e th
e sa
me
enco
ding
s an
d pa
rser
s to
av
oid
pars
ing
atta
cks
that
exp
loit
diffe
rent
UR
I or f
ile p
arsi
ng b
ehav
ior t
hat c
ould
be
use
d in
SS
RF
and
RFI
atta
cks.
XX
X11
6
V13
AP
I13
.1.2
Ver
ify th
at a
cces
s to
adm
inis
tratio
n an
d m
anag
emen
t fun
ctio
ns is
lim
ited
to
auth
oriz
ed a
dmin
istra
tors
.X
XX
419
V13
AP
I13
.1.3
Ver
ify A
PI U
RLs
do
not e
xpos
e se
nsiti
ve in
form
atio
n, s
uch
as th
e A
PI k
ey,
sess
ion
toke
ns e
tc.
XX
X59
8
V13
AP
I13
.1.4
Ver
ify th
at a
utho
rizat
ion
deci
sion
s ar
e m
ade
at b
oth
the
UR
I, en
forc
ed b
y pr
ogra
mm
atic
or d
ecla
rativ
e se
curit
y at
the
cont
rolle
r or r
oute
r, an
d at
the
reso
urce
leve
l, en
forc
ed b
y m
odel
-bas
ed p
erm
issi
ons.
XX
285
V13
AP
I13
.1.5
Ver
ify th
at re
ques
ts c
onta
inin
g un
expe
cted
or m
issi
ng c
onte
nt ty
pes
are
reje
cted
w
ith a
ppro
pria
te h
eade
rs (H
TTP
resp
onse
sta
tus
406
Una
ccep
tabl
e or
415
U
nsup
porte
d M
edia
Typ
e).
XX
434
V13
AP
I13
.2.1
Ver
ify th
at e
nabl
ed R
ES
Tful
HTT
P m
etho
ds a
re a
val
id c
hoic
e fo
r the
use
r or
actio
n, s
uch
as p
reve
ntin
g no
rmal
use
rs u
sing
DE
LETE
or P
UT
on p
rote
cted
AP
I or
reso
urce
s.X
XX
650
V13
AP
I13
.2.2
Ver
ify th
at J
SO
N s
chem
a va
lidat
ion
is in
pla
ce a
nd v
erifi
ed b
efor
e ac
cept
ing
inpu
t.X
XX
20
V13
AP
I13
.2.3
Ver
ify th
at R
ES
Tful
web
ser
vice
s th
at u
tiliz
e co
okie
s ar
e pr
otec
ted
from
Cro
ss-
Site
Req
uest
For
gery
via
the
use
of a
t lea
st o
ne o
r mor
e of
the
follo
win
g: tr
iple
or
doub
le s
ubm
it co
okie
pat
tern
(see
http
s://w
ww
.ow
asp.
org/
inde
x.ph
p/C
ross
-S
ite_R
eque
st_F
orge
ry_(
CS
RF)
_Pre
vent
ion_
Che
at_S
heet
), C
SR
F no
nces
, or
OR
IGIN
requ
est h
eade
r che
cks.
XX
X35
2
V13
AP
I13
.2.4
Ver
ify th
at R
ES
T se
rvic
es h
ave
anti-
auto
mat
ion
cont
rols
to p
rote
ct a
gain
st
exce
ssiv
e ca
lls, e
spec
ially
if th
e A
PI i
s un
auth
entic
ated
.X
X77
9
V13
AP
I13
.2.5
Ver
ify th
at R
ES
T se
rvic
es e
xplic
itly
chec
k th
e in
com
ing
Con
tent
-Typ
e to
be
the
expe
cted
one
, suc
h as
app
licat
ion/
xml o
r app
licat
ion/
JSO
N.
XX
436
V13
AP
I13
.2.6
Ver
ify th
at th
e m
essa
ge h
eade
rs a
nd p
aylo
ad a
re tr
ustw
orth
y an
d no
t mod
ified
in
trans
it. R
equi
ring
stro
ng e
ncry
ptio
n fo
r tra
nspo
rt (T
LS o
nly)
may
be
suffi
cien
t in
man
y ca
ses
as it
pro
vide
s bo
th c
onfid
entia
lity
and
inte
grity
pro
tect
ion.
Per
-m
essa
ge d
igita
l sig
natu
res
can
prov
ide
addi
tiona
l ass
uran
ce o
n to
p of
the
trans
port
prot
ectio
ns fo
r hig
h-se
curit
y ap
plic
atio
ns b
ut b
ring
with
them
add
ition
al
com
plex
ity a
nd ri
sks
to w
eigh
aga
inst
the
bene
fits.
XX
345
V13
AP
I13
.3.1
Ver
ify th
at X
SD
sch
ema
valid
atio
n ta
kes
plac
e to
ens
ure
a pr
oper
ly fo
rmed
XM
L do
cum
ent,
follo
wed
by
valid
atio
n of
eac
h in
put f
ield
bef
ore
any
proc
essi
ng o
f tha
t da
ta ta
kes
plac
e.X
XX
20P
ossi
bly
hand
led
by a
noth
er li
brar
y
C1-
C10
Top
10
Proa
ctiv
e C
ontr
ols:
http
s://w
ww
.ow
asp.
org/
inde
x.ph
p/O
WA
SP_P
roac
tive_
Con
trol
s#ta
b=Fo
rmal
_Num
berin
g)25
8/28
612
2/25
814
6/25
84/
258
174/
258
79
V13
AP
I13
.3.2
Ver
ify th
at th
e m
essa
ge p
aylo
ad is
sig
ned
usin
g W
S-S
ecur
ity to
ens
ure
relia
ble
trans
port
betw
een
clie
nt a
nd s
ervi
ce.
XX
345
V13
AP
I13
.4.1
Ver
ify th
at q
uery
whi
telis
ting
or a
com
bina
tion
of d
epth
lim
iting
and
am
ount
lim
iting
sh
ould
be
used
to p
reve
nt G
raph
QL
or d
ata
laye
r exp
ress
ion
deni
al o
f ser
vice
(D
oS) a
s a
resu
lt of
exp
ensi
ve, n
este
d qu
erie
s. F
or m
ore
adva
nced
sce
nario
s,
quer
y co
st a
naly
sis
shou
ld b
e us
ed.
XX
770
V13
AP
I13
.4.2
Ver
ify th
at G
raph
QL
or o
ther
dat
a la
yer a
utho
rizat
ion
logi
c sh
ould
be
impl
emen
ted
at th
e bu
sine
ss lo
gic
laye
r ins
tead
of t
he G
raph
QL
laye
r.X
X28
5
V14
Con
fig14
.1.1
Ver
ify th
at th
e ap
plic
atio
n bu
ild a
nd d
eplo
ymen
t pro
cess
es a
re p
erfo
rmed
in a
se
cure
and
repe
atab
le w
ay, s
uch
as C
I / C
D a
utom
atio
n, a
utom
ated
con
figur
atio
n m
anag
emen
t, an
d au
tom
ated
dep
loym
ent s
crip
ts.
XX
V14
Con
fig14
.1.2
Ver
ify th
at c
ompi
ler f
lags
are
con
figur
ed to
ena
ble
all a
vaila
ble
buffe
r ove
rflow
pr
otec
tions
and
war
ning
s, in
clud
ing
stac
k ra
ndom
izat
ion,
dat
a ex
ecut
ion
prev
entio
n, a
nd to
bre
ak th
e bu
ild if
an
unsa
fe p
oint
er, m
emor
y, fo
rmat
stri
ng,
inte
ger,
or s
tring
ope
ratio
ns a
re fo
und.
XX
120
V14
Con
fig14
.1.4
Ver
ify th
at th
e ap
plic
atio
n, c
onfig
urat
ion,
and
all
depe
nden
cies
can
be
re-d
eplo
yed
usin
g au
tom
ated
dep
loym
ent s
crip
ts, b
uilt
from
a d
ocum
ente
d an
d te
sted
runb
ook
in a
reas
onab
le ti
me,
or r
esto
red
from
bac
kups
in a
tim
ely
fash
ion.
XX
V14
Con
fig14
.1.5
Ver
ify th
at a
utho
rized
adm
inis
trato
rs c
an v
erify
the
inte
grity
of a
ll se
curit
y-re
leva
nt
conf
igur
atio
ns to
det
ect t
ampe
ring.
X
V14
Con
fig14
.2.1
Ver
ify th
at a
ll co
mpo
nent
s ar
e up
to d
ate,
pre
fera
bly
usin
g a
depe
nden
cy c
heck
er
durin
g bu
ild o
r com
pile
tim
e. [C
2]X
XX
1026
Do
it m
anua
lly.
V14
Con
fig14
.2.2
Ver
ify th
at a
ll un
need
ed fe
atur
es, d
ocum
enta
tion,
sam
ples
, con
figur
atio
ns a
re
rem
oved
, suc
h as
sam
ple
appl
icat
ions
, pla
tform
doc
umen
tatio
n, a
nd d
efau
lt or
ex
ampl
e us
ers.
XX
X10
02D
oing
man
ually
on
ocas
sion
.
V14
Con
fig14
.2.4
Ver
ify th
at th
ird p
arty
com
pone
nts
com
e fro
m p
re-d
efin
ed, t
rust
ed a
nd c
ontin
ually
m
aint
aine
d re
posi
torie
s. [C
2]X
X82
9
V14
Con
fig14
.2.5
Ver
ify th
at a
n in
vent
ory
cata
log
is m
aint
aine
d of
all
third
par
ty li
brar
ies
in u
se. [
C2]
XX
Fail,
may
be
coul
d be
aut
o ge
nera
ted
V14
Con
fig14
.2.6
Ver
ify th
at th
e at
tack
sur
face
is re
duce
d by
san
dbox
ing
or e
ncap
sula
ting
third
pa
rty li
brar
ies
to e
xpos
e on
ly th
e re
quire
d be
havi
our i
nto
the
appl
icat
ion.
([C
2](h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g))
XX
265
V14
Con
fig14
.3.1
Ver
ify th
at w
eb o
r app
licat
ion
serv
er a
nd fr
amew
ork
erro
r mes
sage
s ar
e co
nfig
ured
to d
eliv
er u
ser a
ctio
nabl
e, c
usto
miz
ed re
spon
ses
to e
limin
ate
any
unin
tend
ed s
ecur
ity d
iscl
osur
es.
XX
X20
9
V14
Con
fig14
.3.2
Ver
ify th
at w
eb o
r app
licat
ion
serv
er a
nd a
pplic
atio
n fra
mew
ork
debu
g m
odes
are
di
sabl
ed in
pro
duct
ion
to e
limin
ate
debu
g fe
atur
es, d
evel
oper
con
sole
s, a
nd
unin
tend
ed s
ecur
ity d
iscl
osur
es.
XX
X49
7
Impl
emen
tatio
n re
spon
sbili
ty. T
hey
have
the
posi
blity
to
run
debu
g op
eatio
ns, b
ut it
s no
t act
ivat
ed b
y de
faul
t.
V14
Con
fig14
.3.3
Ver
ify th
at th
e H
TTP
hea
ders
or a
ny p
art o
f the
HTT
P re
spon
se d
o no
t exp
ose
deta
iled
vers
ion
info
rmat
ion
of s
yste
m c
ompo
nent
s.X
XX
200
V14
Con
fig14
.4.1
Ver
ify th
at e
very
HTT
P re
spon
se c
onta
ins
a co
nten
t typ
e he
ader
spe
cify
ing
a sa
fe
char
acte
r set
(e.g
., U
TF-8
, IS
O 8
859-
1).
XX
X17
3
V14
Con
fig14
.4.2
Ver
ify th
at a
ll A
PI r
espo
nses
con
tain
Con
tent
-Dis
posi
tion:
atta
chm
ent;
filen
ame=
"ap
i.jso
n" (o
r oth
er a
ppro
pria
te fi
lena
me
for t
he c
onte
nt ty
pe).
XX
X11
6
V14
Con
fig14
.4.3
Ver
ify th
at a
con
tent
sec
urity
pol
icy
(CS
Pv2
) is
in p
lace
that
hel
ps m
itiga
te im
pact
fo
r XS
S a
ttack
s lik
e H
TML,
DO
M, J
SO
N, a
nd J
avaS
crip
t inj
ectio
n vu
lner
abili
ties.
XX
X10
21V
14C
onfig
14.4
.4V
erify
that
all
resp
onse
s co
ntai
n X
-Con
tent
-Typ
e-O
ptio
ns: n
osni
ff.X
XX
116
V14
Con
fig14
.4.5
Ver
ify th
at H
TTP
Stri
ct T
rans
port
Sec
urity
hea
ders
are
incl
uded
on
all r
espo
nses
an
d fo
r all
subd
omai
ns, s
uch
as S
trict
-Tra
nspo
rt-S
ecur
ity: m
ax-a
ge=1
5724
800;
in
clud
eSub
dom
ains
.X
XX
523
V14
Con
fig14
.4.6
Ver
ify th
at a
sui
tabl
e "R
efer
rer-
Pol
icy"
hea
der i
s in
clud
ed, s
uch
as "n
o-re
ferr
er" o
r "s
ame-
orig
in".
XX
X11
6
V14
Con
fig14
.4.7
Ver
ify th
at a
sui
tabl
e X
-Fra
me-
Opt
ions
or C
onte
nt-S
ecur
ity-P
olic
y: fr
ame-
ance
stor
s he
ader
is in
use
for s
ites
whe
re c
onte
nt s
houl
d no
t be
embe
dded
in a
th
ird-p
arty
site
.X
XX
346
V14
Con
fig14
.5.1
Ver
ify th
at th
e ap
plic
atio
n se
rver
onl
y ac
cept
s th
e H
TTP
met
hods
in u
se b
y th
e ap
plic
atio
n or
AP
I, in
clud
ing
pre-
fligh
t OP
TIO
NS
.X
XX
749
V14
Con
fig14
.5.2
Ver
ify th
at th
e su
pplie
d O
rigin
hea
der i
s no
t use
d fo
r aut
hent
icat
ion
or a
cces
s co
ntro
l dec
isio
ns, a
s th
e O
rigin
hea
der c
an e
asily
be
chan
ged
by a
n at
tack
er.
XX
X34
6
V14
Con
fig14
.5.3
Ver
ify th
at th
e cr
oss-
dom
ain
reso
urce
sha
ring
(CO
RS
) Acc
ess-
Con
trol-A
llow
-O
rigin
hea
der u
ses
a st
rict w
hite
-list
of t
rust
ed d
omai
ns to
mat
ch a
gain
st a
nd d
oes
not s
uppo
rt th
e "n
ull"
orig
in.
XX
X34
6Th
ey d
o ha
ve a
whi
telis
t.
V14
Con
fig14
.5.4
Ver
ify th
at H
TTP
hea
ders
add
ed b
y a
trust
ed p
roxy
or S
SO
dev
ices
, suc
h as
a
bear
er to
ken,
are
aut
hent
icat
ed b
y th
e ap
plic
atio
n.X
X30
6
B.1 Updated scoring
This spreadsheet shows the results from the scoring conducted by the
security engineer in early April 2020. The security engineer re-scored the
50 controls that had previously been a fail.
The old and new results are presented side-by-side, with additional
comments. Controls that will be passing soon are marked blue.
131
C
1-C
10 T
op 1
0 Pr
oact
ive
Con
trol
s: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
ASP
_Pro
activ
e_C
ontr
ols#
tab=
Form
al_N
umbe
ring)
258/
286
174/
258
189/
258
AS
VS
4.0
Old
resu
ltsN
ew re
sults
Sec
urity
Eng
inee
r upd
ated
Sid
e co
mm
ents
Sect
ion
Nam
eIte
mD
escr
iptio
nL1
L2L3
CW
EN
IST
App
licab
le
V1
Arc
hite
ctur
e1.
1.1
Ver
ify th
e us
e of
a s
ecur
e so
ftwar
e de
velo
pmen
t life
cycl
e th
at a
ddre
sses
se
curit
y in
all
stag
es o
f dev
elop
men
t. [C
1]X
X
DH
IS2
uses
Gith
ub fo
r mos
t of t
he d
ev.
cycl
e in
clud
ing
a C
I pip
elin
e. W
e ha
ve a
co
mm
it re
view
pro
cess
that
requ
ires
two
pers
ons
to re
view
eac
h co
mm
it be
fore
it c
an
be m
erge
d. A
s pe
r 2 A
pril,
202
0 G
ithub
stil
l do
n't m
ake
sign
atur
es fo
r rel
ease
s av
aila
ble
auto
mat
ical
ly. T
his
can
be a
dded
. Ove
rall
DH
IS2
uses
a v
ery
stan
dard
dev
cyc
le a
nd
are
cons
ider
ed s
afe
enou
gh fo
r an
open
sour
ce s
yste
m. I
t's n
ot p
erfe
ct a
nd
ther
e ar
e st
ill im
prov
emen
ts th
at c
an b
e ea
sily
add
ed li
ke re
leas
e si
gnat
ures
.I c
onsi
der i
t saf
e en
ough
for D
HIS
2
V1
Arc
hite
ctur
e1.
1.2
Ver
ify th
e us
e of
thre
at m
odel
ing
for e
very
des
ign
chan
ge o
r spr
int p
lann
ing
to id
entif
y th
reat
s, p
lan
for c
ount
erm
easu
res,
faci
litat
e ap
prop
riate
risk
re
spon
ses,
and
gui
de s
ecur
ity te
stin
g.X
X10
53
We
are
in th
e pr
oces
s of
mak
ing
avai
labl
e ch
eckl
ists
etc
.. W
e ha
ve a
lot o
f pen
test
s do
ne
on b
ehal
f of o
rgan
izat
ions
that
use
DH
IS2,
late
ly
ther
e ha
s be
en m
ore
inte
rest
from
par
tner
s to
en
sure
the
syst
em is
sec
ure.
The
re h
as b
een
a pr
etty
con
tinuo
us e
ffort
in te
rms
of p
ente
stin
g th
e la
st y
ear.
Aut
omat
ical
ly p
ente
stin
g in
the
CI
pipe
line
is a
lso
com
ing
soon
.I c
onsi
der i
t bet
ter t
han
in th
e fir
st a
ssm
ent.
Sho
uld
be p
assi
ng.
V1
Arc
hite
ctur
e1.
1.5
Ver
ify d
efin
ition
and
sec
urity
ana
lysi
s of
the
appl
icat
ion'
s hi
gh-le
vel
arch
itect
ure
and
all c
onne
cted
rem
ote
serv
ices
. [C
1]X
X10
59
V1
Arc
hite
ctur
e1.
1.7
Ver
ify a
vaila
bilit
y of
a s
ecur
e co
ding
che
cklis
t, se
curit
y re
quire
men
ts,
guid
elin
e, o
r pol
icy
to a
ll de
velo
pers
and
test
ers.
XX
637
Wor
k in
pro
gres
s.
V1
Arc
hite
ctur
e1.
2.3
Ver
ify th
at th
e ap
plic
atio
n us
es a
sin
gle
vette
d au
then
ticat
ion
mec
hani
sm
that
is k
now
n to
be
secu
re, c
an b
e ex
tend
ed to
incl
ude
stro
ng
auth
entic
atio
n, a
nd h
as s
uffic
ient
logg
ing
and
mon
itorin
g to
det
ect a
ccou
nt
abus
e or
bre
ache
s.X
X30
6
In th
e la
st 6
mon
ths,
ther
e ha
ve b
een
lots
of
impr
ovem
ents
in th
is a
rea.
DH
IS2
uses
indu
stry
-st
anda
rd a
uthe
ntic
atio
n sy
stem
in m
ost a
spec
t, lik
e pa
ssw
ord
algo
rithm
s an
d 2-
fact
or a
uth.
Lot
s of
impr
omen
ts in
aud
iting
and
mon
torin
g ha
ve
been
impl
emen
ted
late
ly to
o.I c
onsi
der t
his
a pa
ss n
ow.
V1
Arc
hite
ctur
e1.
4.5
Ver
ify th
at a
ttrib
ute
or fe
atur
e-ba
sed
acce
ss c
ontro
l is
used
whe
reby
the
code
che
cks
the
user
's a
utho
rizat
ion
for a
feat
ure/
data
item
rath
er th
an ju
st
thei
r rol
e. P
erm
issi
ons
shou
ld s
till b
e al
loca
ted
usin
g ro
les.
[C7]
XX
275
V1
Arc
hite
ctur
e1.
6.2
Ver
ify th
at c
onsu
mer
s of
cry
ptog
raph
ic s
ervi
ces
prot
ect k
ey m
ater
ial a
nd
othe
r sec
rets
by
usin
g ke
y va
ults
or A
PI b
ased
alte
rnat
ives
.X
X32
0
DH
IS2
has
supp
ort f
or s
ymm
etric
enc
rypt
ion
of
som
e va
lues
, for
exa
mpl
e, a
ttrib
utes
that
are
co
nsid
ered
sen
sitiv
e. T
he e
ncry
ptio
n ke
y m
anag
emen
t and
con
figur
atio
n ar
e pr
etty
sim
ple
and
can
be im
prov
ed u
pon.
Thi
s is
pla
nned
to b
e im
prov
ed in
upc
omin
g ve
rsio
ns.
V1
Arc
hite
ctur
e1.
6.3
Ver
ify th
at a
ll ke
ys a
nd p
assw
ords
are
repl
acea
ble
and
are
part
of a
wel
l-de
fined
pro
cess
to re
-enc
rypt
sen
sitiv
e da
ta.
XX
320
Pla
ns to
impl
emen
t a p
assw
ord
re-h
ashi
ng
feat
ure,
mak
ing
it po
ssib
le h
avin
g a
diffe
rent
kin
d of
pas
swor
d ha
shes
at t
he s
ame
time.
V1
Arc
hite
ctur
e1.
6.4
Ver
ify th
at s
ymm
etric
key
s, p
assw
ords
, or A
PI s
ecre
ts g
ener
ated
by
or
shar
ed w
ith c
lient
s ar
e us
ed o
nly
in p
rote
ctin
g lo
w ri
sk s
ecre
ts, s
uch
as
encr
yptin
g lo
cal s
tora
ge, o
r tem
pora
ry e
phem
eral
use
s su
ch a
s pa
ram
eter
ob
fusc
atio
n. S
harin
g se
cret
s w
ith c
lient
s is
cle
ar-te
xt e
quiv
alen
t and
ar
chite
ctur
ally
sho
uld
be tr
eate
d as
suc
h.X
X32
0P
ass
V1
Arc
hite
ctur
e1.
7.2
Ver
ify th
at lo
gs a
re s
ecur
ely
trans
mitt
ed to
a p
refe
rabl
y re
mot
e sy
stem
for
anal
ysis
, det
ectio
n, a
lerti
ng, a
nd e
scal
atio
n. [C
9]X
X
V1
Arc
hite
ctur
e1.
12.2
Ver
ify th
at u
ser-
uplo
aded
file
s - i
f req
uire
d to
be
disp
laye
d or
dow
nloa
ded
from
the
appl
icat
ion
- are
ser
ved
by e
ither
oct
et s
tream
dow
nloa
ds, o
r fro
m
an u
nrel
ated
dom
ain,
suc
h as
a c
loud
file
sto
rage
buc
ket.
Impl
emen
t a
suita
ble
cont
ent s
ecur
ity p
olic
y to
redu
ce th
e ris
k fro
m X
SS
vec
tors
or o
ther
at
tack
s fro
m th
e up
load
ed fi
le.
XX
646
Cur
rent
ly b
eing
fixe
d as
par
t of p
ente
st, s
houl
d be
ava
ilabl
e in
nex
t ver
sion
.P
assi
ng s
oon
C
1-C
10 T
op 1
0 Pr
oact
ive
Con
trol
s: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
ASP
_Pro
activ
e_C
ontr
ols#
tab=
Form
al_N
umbe
ring)
258/
286
174/
258
189/
258
V2
Aut
hent
icat
ion
2.1.
7
Ver
ify th
at p
assw
ords
sub
mitt
ed d
urin
g ac
coun
t reg
istra
tion,
logi
n, a
nd
pass
wor
d ch
ange
are
che
cked
aga
inst
a s
et o
f bre
ache
d pa
ssw
ords
eith
er
loca
lly (s
uch
as th
e to
p 1,
000
or 1
0,00
0 m
ost c
omm
on p
assw
ords
whi
ch
mat
ch th
e sy
stem
's p
assw
ord
polic
y) o
r usi
ng a
n ex
tern
al A
PI.
If us
ing
an
AP
I a z
ero
know
ledg
e pr
oof o
r oth
er m
echa
nism
sho
uld
be u
sed
to e
nsur
e th
at th
e pl
ain
text
pas
swor
d is
not
sen
t or u
sed
in v
erify
ing
the
brea
ch s
tatu
s of
the
pass
wor
d. If
the
pass
wor
d is
bre
ache
d, th
e ap
plic
atio
n m
ust r
equi
re
the
user
to s
et a
new
non
-bre
ache
d pa
ssw
ord.
[C6]
XX
X52
15.
1.1
.2D
HIS
2 do
es n
ot h
ave
such
a fe
atur
e ye
t. Th
is is
a
plan
ned
feat
ure.
V2
Aut
hent
icat
ion
2.1.
8V
erify
that
a p
assw
ord
stre
ngth
met
er is
pro
vide
d to
hel
p us
ers
set a
st
rong
er p
assw
ord.
XX
X52
15.
1.1
.2
V2
Aut
hent
icat
ion
2.1.
9
Ver
ify th
at th
ere
are
no p
assw
ord
com
posi
tion
rule
s lim
iting
the
type
of
char
acte
rs p
erm
itted
. The
re s
houl
d be
no
requ
irem
ent f
or u
pper
or l
ower
ca
se o
r num
bers
or s
peci
al c
hara
cter
s. [C
6]X
XX
521
5.1.
1.2
V2
Aut
hent
icat
ion
2.1.
12
Ver
ify th
at th
e us
er c
an c
hoos
e to
eith
er te
mpo
raril
y vi
ew th
e en
tire
mas
ked
pass
wor
d, o
r tem
pora
rily
view
the
last
type
d ch
arac
ter o
f the
pas
swor
d on
pl
atfo
rms
that
do
not h
ave
this
as
nativ
e fu
nctio
nalit
y.X
XX
521
5.1.
1.2
V2
Aut
hent
icat
ion
2.2.
3
Ver
ify th
at s
ecur
e no
tific
atio
ns a
re s
ent t
o us
ers
afte
r upd
ates
to
auth
entic
atio
n de
tails
, suc
h as
cre
dent
ial r
eset
s, e
mai
l or a
ddre
ss c
hang
es,
logg
ing
in fr
om u
nkno
wn
or ri
sky
loca
tions
. The
use
of p
ush
notif
icat
ions
- ra
ther
than
SM
S o
r em
ail -
is p
refe
rred
, but
in th
e ab
senc
e of
pus
h no
tific
atio
ns, S
MS
or e
mai
l is
acce
ptab
le a
s lo
ng a
s no
sen
sitiv
e in
form
atio
n is
dis
clos
ed in
the
notif
icat
ion.
XX
X62
0Th
is is
not
impl
emen
ted.
Thi
s is
a p
lann
ed
feat
ure.
V2
Aut
hent
icat
ion
2.4.
3
Ver
ify th
at if
PB
KD
F2 is
use
d, th
e ite
ratio
n co
unt S
HO
ULD
be
as la
rge
as
verif
icat
ion
serv
er p
erfo
rman
ce w
ill a
llow
, typ
ical
ly a
t lea
st 1
00,0
00
itera
tions
. [C
6]X
X91
65.
1.1
.2P
ass
V2
Aut
hent
icat
ion
2.4.
4V
erify
that
if b
cryp
t is
used
, the
wor
k fa
ctor
SH
OU
LD b
e as
larg
e as
ve
rific
atio
n se
rver
per
form
ance
will
allo
w, t
ypic
ally
at l
east
13.
[C6]
XX
916
5.1.
1.2
Pas
s
V2
Aut
hent
icat
ion
2.5.
1V
erify
that
a s
yste
m g
ener
ated
initi
al a
ctiv
atio
n or
reco
very
sec
ret i
s no
t sen
t in
cle
ar te
xt to
the
user
. [C
6]X
XX
640
5.1.
1.2
This
is fi
xed
now
.S
houl
d be
a p
ass
V2
Aut
hent
icat
ion
2.5.
5V
erify
that
if a
n au
then
ticat
ion
fact
or is
cha
nged
or r
epla
ced,
that
the
user
is
notif
ied
of th
is e
vent
.X
XX
304
6.1.
2.3
V3
Ses
sion
3.3.
4V
erify
that
use
rs a
re a
ble
to v
iew
and
log
out o
f any
or a
ll cu
rren
tly a
ctiv
e se
ssio
ns a
nd d
evic
es.
XX
613
7.1
This
is n
ot im
plem
ente
d. T
his
is a
pla
nned
fe
atur
e.
V3
Ses
sion
3.4.
4V
erify
that
coo
kie-
base
d se
ssio
n to
kens
use
"__H
ost-"
pre
fix (s
ee
refe
renc
es) t
o pr
ovid
e se
ssio
n co
okie
con
fiden
tialit
y.X
XX
167.
1.1
This
is fi
xed
in la
test
ver
sion
.S
houl
d be
a p
ass
V3
Ses
sion
3.6.
2V
erify
that
CS
Ps
info
rm re
lyin
g pa
rties
of t
he la
st a
uthe
ntic
atio
n ev
ent,
to
allo
w R
Ps
to d
eter
min
e if
they
nee
d to
re-a
uthe
ntic
ate
the
user
.X
613
7.2.
1
V3
Ses
sion
3.7.
1
Ver
ify th
e ap
plic
atio
n en
sure
s a
valid
logi
n se
ssio
n or
requ
ires
re-
auth
entic
atio
n or
sec
onda
ry v
erifi
catio
n be
fore
allo
win
g an
y se
nsiti
ve
trans
actio
ns o
r acc
ount
mod
ifica
tions
.X
XX
778
This
is n
ot im
plem
ente
d. T
his
is a
pla
nned
fe
atur
e. W
e pr
otec
t pas
swor
d ch
ange
with
bru
te
forc
e ch
eck.
To
chan
ge p
assw
ord
you
need
to
ente
r old
pas
swor
d.P
artia
l pas
s.
V4
Acc
ess
4.2.
2
Ver
ify th
at th
e ap
plic
atio
n or
fram
ewor
k en
forc
es a
stro
ng a
nti-C
SR
F m
echa
nism
to p
rote
ct a
uthe
ntic
ated
func
tiona
lity,
and
effe
ctiv
e an
ti-au
tom
atio
n or
ant
i-CS
RF
prot
ects
una
uthe
ntic
ated
func
tiona
lity.
XX
X35
2Th
is is
not
impl
emen
ted.
Thi
s is
a p
lann
ed
feat
ure.
V4
Acc
ess
4.3.
1V
erify
adm
inis
trativ
e in
terfa
ces
use
appr
opria
te m
ulti-
fact
or a
uthe
ntic
atio
n to
pr
even
t una
utho
rized
use
.X
XX
419
DH
IS2
supp
orts
2-fa
ctor
. Thi
s is
con
figur
able
an
d up
to th
e re
spec
tive
user
s/ad
min
s to
dec
ide
if th
ey w
ant t
o us
e.
V5
Val
idat
ion
5.1.
5V
erify
that
UR
L re
dire
cts
and
forw
ards
onl
y al
low
whi
telis
ted
dest
inat
ions
, or
show
a w
arni
ng w
hen
redi
rect
ing
to p
oten
tially
unt
rust
ed c
onte
nt.
XX
X60
1Th
is is
not
impl
emen
ted.
Thi
s is
a p
lann
ed
feat
ure.
V5
Val
idat
ion
5.2.
1V
erify
that
all
untru
sted
HTM
L in
put f
rom
WY
SIW
YG
edi
tors
or s
imila
r is
prop
erly
san
itize
d w
ith a
n H
TML
sani
tizer
libr
ary
or fr
amew
ork
feat
ure.
[C5]
XX
X11
6Th
is is
fixe
d in
late
t ver
sion
s.S
houl
d be
a p
ass
now
V5
Val
idat
ion
5.2.
2V
erify
that
uns
truct
ured
dat
a is
san
itize
d to
enf
orce
saf
ety
mea
sure
s su
ch
as a
llow
ed c
hara
cter
s an
d le
ngth
.X
XX
138
This
is fi
xed
in la
tet v
ersi
ons.
Sho
uld
be a
pas
s no
w
V5
Val
idat
ion
5.2.
5V
erify
that
the
appl
icat
ion
prot
ects
aga
inst
tem
plat
e in
ject
ion
atta
cks
by
ensu
ring
that
any
use
r inp
ut b
eing
incl
uded
is s
aniti
zed
or s
andb
oxed
.X
XX
94P
ass
V6
Cry
ptog
raph
y6.
1.3
Ver
ify th
at re
gula
ted
finan
cial
dat
a is
sto
red
encr
ypte
d w
hile
at r
est,
such
as
finan
cial
acc
ount
s, d
efau
lts o
r cre
dit h
isto
ry, t
ax re
cord
s, p
ay h
isto
ry,
bene
ficia
ries,
or d
e-an
onym
ized
mar
ket o
r res
earc
h re
cord
s.X
X31
1N
/A
C
1-C
10 T
op 1
0 Pr
oact
ive
Con
trol
s: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
ASP
_Pro
activ
e_C
ontr
ols#
tab=
Form
al_N
umbe
ring)
258/
286
174/
258
189/
258
V6
Cry
ptog
raph
y6.
3.1
Ver
ify th
at a
ll ra
ndom
num
bers
, ran
dom
file
nam
es, r
ando
m G
UID
s, a
nd
rand
om s
tring
s ar
e ge
nera
ted
usin
g th
e cr
ypto
grap
hic
mod
ule'
s ap
prov
ed
cryp
togr
aphi
cally
sec
ure
rand
om n
umbe
r gen
erat
or w
hen
thes
e ra
ndom
va
lues
are
inte
nded
to b
e no
t gue
ssab
le b
y an
atta
cker
.X
X33
8Th
is is
fixe
d in
late
t ver
sion
s.S
houl
d be
a p
ass
now
V8
Dat
a8.
1.1
Ver
ify th
e ap
plic
atio
n pr
otec
ts s
ensi
tive
data
from
bei
ng c
ache
d in
ser
ver
com
pone
nts
such
as
load
bal
ance
rs a
nd a
pplic
atio
n ca
ches
.X
X52
4
V8
Dat
a8.
1.4
Ver
ify th
e ap
plic
atio
n ca
n de
tect
and
ale
rt on
abn
orm
al n
umbe
rs o
f re
ques
ts, s
uch
as b
y IP
, use
r, to
tal p
er h
our o
r day
, or w
hate
ver m
akes
se
nse
for t
he a
pplic
atio
n.X
X77
0
Par
tial s
uppo
rt by
pro
tect
ing
the
mos
t sen
sitiv
e A
PI e
ndpo
ints
with
bru
te-fo
rce
chec
ks. W
e al
so
enco
urag
e sy
stem
adm
ins
to im
plem
ent a
pro
xy
laye
r in
front
of t
heir
inst
alla
tions
to p
reve
nt b
rute
fo
rce
and
DO
S a
ttack
s.P
ass
V8
Dat
a8.
3.5
Ver
ify a
cces
sing
sen
sitiv
e da
ta is
aud
ited
(with
out l
oggi
ng th
e se
nsiti
ve d
ata
itsel
f), if
the
data
is c
olle
cted
und
er re
leva
nt d
ata
prot
ectio
n di
rect
ives
or
whe
re lo
ggin
g of
acc
ess
is re
quire
d.X
X53
2D
HIS
2 ha
ve b
ette
r aud
it fu
nctio
nalit
y in
new
est
vers
ions
.S
houl
d be
a p
ass
now
V8
Dat
a8.
3.6
Ver
ify th
at s
ensi
tive
info
rmat
ion
cont
aine
d in
mem
ory
is o
verw
ritte
n as
soo
n as
it is
no
long
er re
quire
d to
miti
gate
mem
ory
dum
ping
atta
cks,
usi
ng
zero
es o
r ran
dom
dat
a.X
X22
6P
artia
lly im
plem
ente
d in
libs
use
d. P
lann
ed ta
sk
to d
o a
deep
er a
naly
sis
V10
Mal
icio
us10
.2.4
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
es n
ot
cont
ain
time
bom
bs b
y se
arch
ing
for d
ate
and
time
rela
ted
func
tions
.X
511
V10
Mal
icio
us10
.2.5
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
es n
ot
cont
ain
mal
icio
us c
ode,
suc
h as
sal
ami a
ttack
s, lo
gic
bypa
sses
, or l
ogic
bo
mbs
.X
511
Wor
k in
pro
gres
s to
impl
emen
t int
o C
I pip
elin
e.
V10
Mal
icio
us10
.2.6
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
not
co
ntai
n E
aste
r egg
s or
any
oth
er p
oten
tially
unw
ante
d fu
nctio
nalit
y.X
507
Wor
k in
pro
gres
s to
impl
emen
t int
o C
I pip
elin
e.
V12
File
s12
.1.1
Ver
ify th
at th
e ap
plic
atio
n w
ill n
ot a
ccep
t lar
ge fi
les
that
cou
ld fi
ll up
sto
rage
or
cau
se a
den
ial o
f ser
vice
atta
ck.
XX
X40
0C
urre
ntly
bei
ng fi
xed
as p
art o
f pen
test
, sho
uld
be a
vaila
ble
in n
ext v
ersi
on.
Pas
sing
soo
n
V12
File
s12
.1.2
Ver
ify th
at c
ompr
esse
d fil
es a
re c
heck
ed fo
r "zi
p bo
mbs
" - s
mal
l inp
ut fi
les
that
will
dec
ompr
ess
into
hug
e fil
es th
us e
xhau
stin
g fil
e st
orag
e lim
its.
XX
409
Cur
rent
ly b
eing
fixe
d as
par
t of p
ente
st, s
houl
d be
ava
ilabl
e in
nex
t ver
sion
.P
assi
ng s
oon
V12
File
s12
.1.3
Ver
ify th
at a
file
siz
e qu
ota
and
max
imum
num
ber o
f file
s pe
r use
r is
enfo
rced
to e
nsur
e th
at a
sin
gle
user
can
not f
ill u
p th
e st
orag
e w
ith to
o m
any
files
, or e
xces
sive
ly la
rge
files
.X
X77
0C
urre
ntly
bei
ng fi
xed
as p
art o
f pen
test
, sho
uld
be a
vaila
ble
in n
ext v
ersi
on.
Pas
sing
soo
n
V12
File
s12
.2.1
Ver
ify th
at fi
les
obta
ined
from
unt
rust
ed s
ourc
es a
re v
alid
ated
to b
e of
ex
pect
ed ty
pe b
ased
on
the
file'
s co
nten
t.X
X43
4C
urre
ntly
bei
ng fi
xed
as p
art o
f pen
test
, sho
uld
be a
vaila
ble
in n
ext v
ersi
on.
Pas
sing
soo
n
V12
File
s12
.4.2
Ver
ify th
at fi
les
obta
ined
from
unt
rust
ed s
ourc
es a
re s
cann
ed b
y an
tiviru
s sc
anne
rs to
pre
vent
upl
oad
of k
now
n m
alic
ious
con
tent
.X
XX
509
Cur
rent
ly b
eing
fixe
d as
par
t of p
ente
st, s
houl
d be
ava
ilabl
e in
nex
t ver
sion
.P
assi
ng s
oon
V13
AP
I13
.2.3
Ver
ify th
at R
ES
Tful
web
ser
vice
s th
at u
tiliz
e co
okie
s ar
e pr
otec
ted
from
C
ross
-Site
Req
uest
For
gery
via
the
use
of a
t lea
st o
ne o
r mor
e of
the
follo
win
g: tr
iple
or d
oubl
e su
bmit
cook
ie p
atte
rn (s
ee h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
Cro
ss-S
ite_R
eque
st_F
orge
ry_(
CS
RF)
_Pre
vent
ion_
Che
at_S
heet
), C
SR
F no
nces
, or O
RIG
IN re
ques
t hea
der
chec
ks.
XX
X35
2
V13
AP
I13
.2.4
Ver
ify th
at R
ES
T se
rvic
es h
ave
anti-
auto
mat
ion
cont
rols
to p
rote
ct a
gain
st
exce
ssiv
e ca
lls, e
spec
ially
if th
e A
PI i
s un
auth
entic
ated
.X
X77
9P
ass
V14
Con
fig14
.2.5
Ver
ify th
at a
n in
vent
ory
cata
log
is m
aint
aine
d of
all
third
par
ty li
brar
ies
in
use.
[C2]
XX
V14
Con
fig14
.2.6
Ver
ify th
at th
e at
tack
sur
face
is re
duce
d by
san
dbox
ing
or e
ncap
sula
ting
third
par
ty li
brar
ies
to e
xpos
e on
ly th
e re
quire
d be
havi
our i
nto
the
appl
icat
ion.
([C
2](h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g))
XX
265
Cur
rent
ly b
eing
fixe
d as
par
t of p
ente
st, s
houl
d be
ava
ilabl
e in
nex
t ver
sion
.P
assi
ng s
oon
V14
Con
fig14
.4.2
Ver
ify th
at a
ll A
PI r
espo
nses
con
tain
Con
tent
-Dis
posi
tion:
atta
chm
ent;
filen
ame=
"api
.json
" (or
oth
er a
ppro
pria
te fi
lena
me
for t
he c
onte
nt ty
pe).
XX
X11
6C
urre
ntly
bei
ng fi
xed
as p
art o
f pen
test
, sho
uld
be a
vaila
ble
in n
ext v
ersi
on.
Pas
sing
soo
n
V14
Con
fig14
.5.4
Ver
ify th
at H
TTP
hea
ders
add
ed b
y a
trust
ed p
roxy
or S
SO
dev
ices
, suc
h as
a b
eare
r tok
en, a
re a
uthe
ntic
ated
by
the
appl
icat
ion.
XX
306
Phase 3: Ranking spreadsheet
This spreadsheet shows the results of the ranking phase. The spreadsheet
shows all 50 failed controls, and the comments and ranking given by the
two participants.
135
C
1-C
10 T
op 1
0 Pr
oact
ive
Con
trol
s: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
ASP
_Pro
activ
e_C
ontr
ols#
tab=
Form
al_N
umbe
ring)
258/
286
50/2
58A
SV
S 4
.0S
ecur
ity e
ngin
eer
Fron
tend
Sect
ion
Nam
eIte
mD
escr
iptio
nL1
L2L3
CW
EN
IST
App
licab
leFa
iled
Com
men
tsC
omm
ents
V1
Arc
hite
ctur
e1.
1.1
Ver
ify th
e us
e of
a s
ecur
e so
ftwar
e de
velo
pmen
t life
cycl
e th
at a
ddre
sses
se
curit
y in
all
stag
es o
f dev
elop
men
t. [C
1]X
X
Pro
babl
y th
e m
ost s
cary
thin
g, if
per
haps
som
e at
tack
er
can
com
mit
som
e co
de in
to th
e re
posi
tory
, and
the
code
ge
ts re
dist
ribut
ed th
roug
h di
ffere
nt c
hann
els.
Tha
t's m
ore
on th
e de
velo
pmen
t life
cycl
e, m
akin
g su
re th
at e
very
co
mm
it is
sig
ned,
use
che
cksu
ms
for d
istri
butio
ns.
Ran
k: 5
I con
side
r sec
urity
a p
roce
ss m
ore
than
an
end
stat
e, s
o th
is is
som
ethi
ng w
e sh
ould
do
. R
ank:
5.
V1
Arc
hite
ctur
e1.
1.2
Ver
ify th
e us
e of
thre
at m
odel
ing
for e
very
des
ign
chan
ge o
r spr
int p
lann
ing
to id
entif
y th
reat
s, p
lan
for c
ount
erm
easu
res,
faci
litat
e ap
prop
riate
risk
re
spon
ses,
and
gui
de s
ecur
ity te
stin
g.X
X10
53
Don
't ha
ve a
ny g
ood
form
aliz
ie p
roce
ss o
r che
cklis
ts fo
r do
ing
this
, but
it's
on
a to
-do
list,
to h
ave
a ch
eckl
ist a
nd
som
e ba
sic
thin
king
abo
ut w
hat t
hey
are
actu
ally
doi
ng
and
impl
emen
ting.
Ran
k: 4
I'm n
ot fa
mili
ar w
ith th
reat
mod
elin
g pr
oces
ses.
W
e ha
ve re
cent
ly h
ired
a se
curit
y en
gine
er th
at
shou
ld p
rovi
de g
uida
nce
on h
ow to
inte
grat
e th
is
into
our
pro
cess
es.
Ran
k: 3
V1
Arc
hite
ctur
e1.
1.5
Ver
ify d
efin
ition
and
sec
urity
ana
lysi
s of
the
appl
icat
ion'
s hi
gh-le
vel
arch
itect
ure
and
all c
onne
cted
rem
ote
serv
ices
. [C
1]X
X10
59R
ank:
4
This
is o
n th
e im
plem
enta
tion
side
, but
we
shou
ld p
rovi
de c
lear
gui
danc
e on
wha
t the
sy
sadm
ins
MU
ST
and
MU
ST
NO
T do
in te
rms
of
mai
ntai
ning
a s
ecur
e sy
stem
. R
ank:
4
V1
Arc
hite
ctur
e1.
1.7
Ver
ify a
vaila
bilit
y of
a s
ecur
e co
ding
che
cklis
t, se
curit
y re
quire
men
ts,
guid
elin
e, o
r pol
icy
to a
ll de
velo
pers
and
test
ers.
XX
637
Ran
k: 4
This
is s
omet
hing
that
we
wou
ld b
enef
it fro
m.
Ran
k: 3
V1
Arc
hite
ctur
e1.
2.3
Ver
ify th
at th
e ap
plic
atio
n us
es a
sin
gle
vette
d au
then
ticat
ion
mec
hani
sm
that
is k
now
n to
be
secu
re, c
an b
e ex
tend
ed to
incl
ude
stro
ng
auth
entic
atio
n, a
nd h
as s
uffic
ient
logg
ing
and
mon
itorin
g to
det
ect a
ccou
nt
abus
e or
bre
ache
s.X
X30
6
Kin
d of
hav
e th
is. H
ave
this
on
prot
ectio
n fo
r pas
swor
d re
cove
ry. W
as p
ossi
ble
to d
o a
limite
d nu
mbe
r of
pass
wor
wd
reco
verie
s. F
alls
into
bru
tec
forc
e an
d ra
te
limiti
ng. F
alls
into
acc
ount
lock
ing,
not
ifyin
g th
e us
er. T
his
part
coul
d be
impr
oved
upo
n. T
he b
asic
one
-fact
or a
nd
two-
fact
or is
pre
tty s
tand
ard
stuf
f, us
ing
Spr
ing
secu
rity
and
usin
g kn
own
prac
tices
. Cur
rent
ly, n
ot p
ossi
ble
to d
o an
ulim
ited
num
ber o
f rec
over
ies.
Not
a to
tal f
ail,
but t
he
basi
cs a
re in
pla
ce.
Ran
k: 5
(if t
his
was
a h
ard
fail)
. It i
s a
broa
d se
curit
y re
quire
men
t. Th
e de
scrip
tion
coul
d be
bro
ken
into
mor
e pa
rts. T
he fi
rst p
art o
f the
sen
tenc
e is
the
mos
t im
porta
nt
thin
g.
Mus
t im
plem
ent.
It is
just
a m
atte
r of t
ime
until
th
e fir
st b
reac
h ha
ppen
s as
a re
sult
of th
is.
Ran
k: 5
V1
Arc
hite
ctur
e1.
4.5
Ver
ify th
at a
ttrib
ute
or fe
atur
e-ba
sed
acce
ss c
ontro
l is
used
whe
reby
the
code
che
cks
the
user
's a
utho
rizat
ion
for a
feat
ure/
data
item
rath
er th
an ju
st
thei
r rol
e. P
erm
issi
ons
shou
ld s
till b
e al
loca
ted
usin
g ro
les.
[C7]
XX
275
V1
Arc
hite
ctur
e1.
6.2
Ver
ify th
at c
onsu
mer
s of
cry
ptog
raph
ic s
ervi
ces
prot
ect k
ey m
ater
ial a
nd
othe
r sec
rets
by
usin
g ke
y va
ults
or A
PI b
ased
alte
rnat
ives
.X
X32
0
Sin
ce th
e en
cryp
tion
they
re d
oing
is s
ymm
etric
enc
yptio
n is
ver
y lim
ited,
and
ther
e ar
e fe
w s
ettin
gs to
con
figur
e.
Look
ed a
t im
plem
enta
tion
and
its n
ot v
ery
good
. Hav
ing
the
optio
n to
hoo
k in
to K
eyV
ault,
sho
uld
be a
n op
tion.
Ran
k: 4
V1
Arc
hite
ctur
e1.
6.3
Ver
ify th
at a
ll ke
ys a
nd p
assw
ords
are
repl
acea
ble
and
are
part
of a
wel
l-de
fined
pro
cess
to re
-enc
rypt
sen
sitiv
e da
ta.
XX
320
Task
to d
o a
reha
rshi
ng o
f the
pas
swor
d, h
avin
g a
diffe
rent
kin
d of
pas
swor
d ha
shes
. You
pre
-pen
d th
e ha
sh w
ith th
e ki
nd o
f has
h yo
u ar
e us
ing,
so
you
can
look
ito
the
data
base
and
do
a re
hara
shin
g if
its n
eces
sary
. R
ank:
4
V1
Arc
hite
ctur
e1.
6.4
Ver
ify th
at s
ymm
etric
key
s, p
assw
ords
, or A
PI s
ecre
ts g
ener
ated
by
or
shar
ed w
ith c
lient
s ar
e us
ed o
nly
in p
rote
ctin
g lo
w ri
sk s
ecre
ts, s
uch
as
encr
yptin
g lo
cal s
tora
ge, o
r tem
pora
ry e
phem
eral
use
s su
ch a
s pa
ram
eter
ob
fusc
atio
n. S
harin
g se
cret
s w
ith c
lient
s is
cle
ar-te
xt e
quiv
alen
t and
ar
chite
ctur
ally
sho
uld
be tr
eate
d as
suc
h.X
X32
0
V1
Arc
hite
ctur
e1.
7.2
Ver
ify th
at lo
gs a
re s
ecur
ely
trans
mitt
ed to
a p
refe
rabl
y re
mot
e sy
stem
for
anal
ysis
, det
ectio
n, a
lerti
ng, a
nd e
scal
atio
n. [C
9]X
X
V1
Arc
hite
ctur
e1.
12.2
Ver
ify th
at u
ser-
uplo
aded
file
s - i
f req
uire
d to
be
disp
laye
d or
dow
nloa
ded
from
the
appl
icat
ion
- are
ser
ved
by e
ither
oct
et s
tream
dow
nloa
ds, o
r fro
m
an u
nrel
ated
dom
ain,
suc
h as
a c
loud
file
sto
rage
buc
ket.
Impl
emen
t a
suita
ble
cont
ent s
ecur
ity p
olic
y to
redu
ce th
e ris
k fro
m X
SS
vec
tors
or o
ther
at
tack
s fro
m th
e up
load
ed fi
le.
XX
646
C
1-C
10 T
op 1
0 Pr
oact
ive
Con
trol
s: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
ASP
_Pro
activ
e_C
ontr
ols#
tab=
Form
al_N
umbe
ring)
258/
286
50/2
58
V2
Aut
hent
icat
ion
2.1.
7
Ver
ify th
at p
assw
ords
sub
mitt
ed d
urin
g ac
coun
t reg
istra
tion,
logi
n, a
nd
pass
wor
d ch
ange
are
che
cked
aga
inst
a s
et o
f bre
ache
d pa
ssw
ords
eith
er
loca
lly (s
uch
as th
e to
p 1,
000
or 1
0,00
0 m
ost c
omm
on p
assw
ords
whi
ch
mat
ch th
e sy
stem
's p
assw
ord
polic
y) o
r usi
ng a
n ex
tern
al A
PI.
If us
ing
an
AP
I a z
ero
know
ledg
e pr
oof o
r oth
er m
echa
nism
sho
uld
be u
sed
to e
nsur
e th
at th
e pl
ain
text
pas
swor
d is
not
sen
t or u
sed
in v
erify
ing
the
brea
ch s
tatu
s of
the
pass
wor
d. If
the
pass
wor
d is
bre
ache
d, th
e ap
plic
atio
n m
ust r
equi
re
the
user
to s
et a
new
non
-bre
ache
d pa
ssw
ord.
[C6]
XX
X52
15.
1.1
.2
Don
't ha
ve p
assw
ord
brea
ch d
evic
e, b
ut p
roba
bly
shou
ld.
Api
's th
ey c
ould
sub
srib
e to
, a lo
t of c
ompa
nies
mak
ing
mon
ey o
f hos
ting
this
brid
ge p
assw
ord
data
base
s.
Bec
omin
g qu
ite p
opul
ar, t
his
serv
ice
for d
oing
this
. How
th
is is
app
lied
to a
n op
en s
ourc
e sy
stem
, not
qui
te s
ure,
be
acus
e th
e se
rvic
e se
lls th
e se
rvic
e as
a p
aid
subs
crip
tion,
so
not s
ure
how
this
can
be
done
in a
free
se
rvic
e. M
aybe
you
can
add
som
e co
nfig
urat
ion,
so
it is
po
ssib
le fo
r the
guy
s th
at h
ost t
he s
yste
m th
at a
dd it
if
they
wan
t, m
ake
it so
me
plug
gibl
e sy
stem
ouf
of i
t. C
ould
be
an
extra
sec
urity
mea
sure
for p
eopl
e th
at w
ant i
t. D
oesn
't se
e it
as a
maj
or b
ig s
ecur
ity th
ing,
but
peo
ple
coul
d of
cou
rse
use
bad
pass
wor
ds.
Ran
k: 3
We
shou
ld m
atch
aga
inst
kno
wn
brea
ched
pa
ssw
ords
any
time
a pa
ssw
ord
is s
et o
r up
date
d.
Ran
k: 4
V2
Aut
hent
icat
ion
2.1.
8V
erify
that
a p
assw
ord
stre
ngth
met
er is
pro
vide
d to
hel
p us
ers
set a
st
rong
er p
assw
ord.
XX
X52
15.
1.1
.2H
elpf
ul fo
r a u
ser i
nter
face
, its
a h
elpf
ul fe
edba
ck.
Ran
k: 1
/2
Nic
e to
hav
e, th
ough
I ha
ve n
ot re
sear
ched
if th
is
actu
ally
affe
cts
anyt
hing
if n
ot e
nfor
ced.
R
ank:
1
V2
Aut
hent
icat
ion
2.1.
9
Ver
ify th
at th
ere
are
no p
assw
ord
com
posi
tion
rule
s lim
iting
the
type
of
char
acte
rs p
erm
itted
. The
re s
houl
d be
no
requ
irem
ent f
or u
pper
or l
ower
ca
se o
r num
bers
or s
peci
al c
hara
cter
s. [C
6]X
XX
521
5.1.
1.2
Wou
ld h
ave
liked
to s
ee it
go
away
.R
ank:
2
I hav
e a
pet p
eeve
not
bei
ng a
llow
ed fu
ll un
icod
e ch
arse
t whe
n se
tting
pas
swor
ds, s
o pe
rson
ally
I fin
d th
is im
porta
nt.
Ran
k: 3
V2
Aut
hent
icat
ion
2.1.
12
Ver
ify th
at th
e us
er c
an c
hoos
e to
eith
er te
mpo
raril
y vi
ew th
e en
tire
mas
ked
pass
wor
d, o
r tem
pora
rily
view
the
last
type
d ch
arac
ter o
f the
pas
swor
d on
pl
atfo
rms
that
do
not h
ave
this
as
nativ
e fu
nctio
nalit
y.X
XX
521
5.1.
1.2
Use
r int
erfa
ce c
once
rn.
Ran
k: 1
/2
Wou
ld b
e ha
ndy,
not
the
high
est p
riorit
y w
e ha
ve.
Ran
k: 1
V2
Aut
hent
icat
ion
2.2.
3
Ver
ify th
at s
ecur
e no
tific
atio
ns a
re s
ent t
o us
ers
afte
r upd
ates
to
auth
entic
atio
n de
tails
, suc
h as
cre
dent
ial r
eset
s, e
mai
l or a
ddre
ss c
hang
es,
logg
ing
in fr
om u
nkno
wn
or ri
sky
loca
tions
. The
use
of p
ush
notif
icat
ions
- ra
ther
than
SM
S o
r em
ail -
is p
refe
rred
, but
in th
e ab
senc
e of
pus
h no
tific
atio
ns, S
MS
or e
mai
l is
acce
ptab
le a
s lo
ng a
s no
sen
sitiv
e in
form
atio
n is
dis
clos
ed in
the
notif
icat
ion.
XX
X62
0
Mor
e se
rious
. Hav
e be
en w
orki
ng o
n br
uce
forc
e pr
otec
tion.
Whe
n su
spic
ious
act
ivity
hap
ens
on y
our
acco
unts
, whe
n so
meo
ne tr
ying
to lo
gin
from
diff
eren
t pl
aces
, it c
hang
es v
ery
fast
, you
can
't ph
ysic
ally
cha
nge
that
fast
. Det
ectin
g st
rang
e be
havi
ors,
and
doi
ng
som
ethi
ng w
ith it
, tha
t inf
orm
atio
n - s
endi
ng n
otifi
catio
ns
Ran
k: 4
Mus
t hav
e. C
urre
ntly
if a
use
r's p
assw
ord
is
chan
ged
with
out h
er k
now
ledg
e sh
e w
ill n
ot b
e aw
are
until
the
next
use
, whi
ch m
ay b
e to
o la
te.
Ran
k: 4
V2
Aut
hent
icat
ion
2.4.
3
Ver
ify th
at if
PB
KD
F2 is
use
d, th
e ite
ratio
n co
unt S
HO
ULD
be
as la
rge
as
verif
icat
ion
serv
er p
erfo
rman
ce w
ill a
llow
, typ
ical
ly a
t lea
st 1
00,0
00
itera
tions
. [C
6]X
X91
65.
1.1
.2
V2
Aut
hent
icat
ion
2.4.
4V
erify
that
if b
cryp
t is
used
, the
wor
k fa
ctor
SH
OU
LD b
e as
larg
e as
ve
rific
atio
n se
rver
per
form
ance
will
allo
w, t
ypic
ally
at l
east
13.
[C6]
XX
916
5.1.
1.2
V2
Aut
hent
icat
ion
2.5.
1V
erify
that
a s
yste
m g
ener
ated
initi
al a
ctiv
atio
n or
reco
very
sec
ret i
s no
t sen
t in
cle
ar te
xt to
the
user
. [C
6]X
XX
640
5.1.
1.2
Ski
p
Em
barr
assi
ng th
at w
e fa
il on
this
.R
ank:
5
V2
Aut
hent
icat
ion
2.5.
5V
erify
that
if a
n au
then
ticat
ion
fact
or is
cha
nged
or r
epla
ced,
that
the
user
is
notif
ied
of th
is e
vent
.X
XX
304
6.1.
2.3
Rel
ated
to th
e ot
her n
otifi
catio
n is
sue
Ran
k: 4
Ties
into
2.5
.1, w
e sh
ould
not
ify th
e us
er w
hen
sens
itive
info
rmat
ion
on h
er a
ccou
nt c
hang
es.
Ran
k: 5
V3
Ses
sion
3.3.
4V
erify
that
use
rs a
re a
ble
to v
iew
and
log
out o
f any
or a
ll cu
rren
tly a
ctiv
e se
ssio
ns a
nd d
evic
es.
XX
613
7.1
It's
lack
ing.
Fai
rly e
asy
to d
o on
the
back
end,
but
a lo
t of
wor
k on
the
front
-end
. Com
es w
ith th
e pa
rt on
get
ting
notif
icat
ion
and
seei
ng a
log
of w
hen
you
logg
ed in
and
ou
t.R
ank
4
This
wou
ld b
e a
very
use
ful t
ool t
o pr
ovid
e fo
r us
ers.
We
shou
ld b
e gi
ving
the
user
eno
ugh
tool
s to
man
age
thei
r ow
n se
curit
y as
it is
the
first
line
of d
efen
ce.
Ran
k: 3
V3
Ses
sion
3.4.
4V
erify
that
coo
kie-
base
d se
ssio
n to
kens
use
"__H
ost-"
pre
fix (s
ee
refe
renc
es) t
o pr
ovid
e se
ssio
n co
okie
con
fiden
tialit
y.X
XX
167.
1.1
Doi
ng it
as
part
of a
pen
test
they
hav
e. T
his
is a
n on
goin
g th
ing,
impo
rtant
. R
ank:
4
Not
fully
aw
are
of th
e co
nseq
uenc
es, b
ut it
is a
tri
vial
thin
g to
fix
and
we
shou
ld fo
llow
bes
t pr
actic
e on
this
. 3
V3
Ses
sion
3.6.
2V
erify
that
CS
Ps
info
rm re
lyin
g pa
rties
of t
he la
st a
uthe
ntic
atio
n ev
ent,
to
allo
w R
Ps
to d
eter
min
e if
they
nee
d to
re-a
uthe
ntic
ate
the
user
.X
613
7.2.
1U
nsur
e of
the
cons
eque
nces
of t
his
omis
sion
. R
ank:
2
V3
Ses
sion
3.7.
1
Ver
ify th
e ap
plic
atio
n en
sure
s a
valid
logi
n se
ssio
n or
requ
ires
re-
auth
entic
atio
n or
sec
onda
ry v
erifi
catio
n be
fore
allo
win
g an
y se
nsiti
ve
trans
actio
ns o
r acc
ount
mod
ifica
tions
.X
XX
778
Don
't do
it. S
teal
you
r ses
sion
, eith
er p
hysi
cally
into
you
r m
achi
ne o
r, so
me
othe
r kin
d of
tric
kery
. Sho
uld
prev
ent
the
atta
cker
from
doi
ng th
at.
Ran
k: 4
Ther
e is
no
need
for a
use
r to
be a
t ful
l priv
ilege
s at
all
times
, and
cou
ld e
asily
esc
alat
e hi
s ac
tive
priv
ilege
s th
roug
h a
seco
ndar
y pa
ssw
ord
entry
w
hen
deal
ing
with
sen
sitiv
e op
erat
ions
. R
ank:
4
V4
Acc
ess
4.2.
2
Ver
ify th
at th
e ap
plic
atio
n or
fram
ewor
k en
forc
es a
stro
ng a
nti-C
SR
F m
echa
nism
to p
rote
ct a
uthe
ntic
ated
func
tiona
lity,
and
effe
ctiv
e an
ti-au
tom
atio
n or
ant
i-CS
RF
prot
ects
una
uthe
ntic
ated
func
tiona
lity.
XX
X35
2
Cur
rent
ly a
re n
ot d
oing
this
, it's
on
the
late
st p
ente
st li
st.
It's
poss
ible
to d
o, b
ut o
ther
prio
ritie
s.R
ank:
3Im
porta
nt. W
e ar
e vu
lner
able
to th
is th
roug
hout
. R
ankl
: 5
C
1-C
10 T
op 1
0 Pr
oact
ive
Con
trol
s: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
ASP
_Pro
activ
e_C
ontr
ols#
tab=
Form
al_N
umbe
ring)
258/
286
50/2
58
V4
Acc
ess
4.3.
1V
erify
adm
inis
trativ
e in
terfa
ces
use
appr
opria
te m
ulti-
fact
or a
uthe
ntic
atio
n to
pr
even
t una
utho
rized
use
.X
XX
419
Do
have
two-
fact
or, b
ut it
is n
ot e
nfor
ced
on a
dmin
ac
coun
ts. I
ts h
ard
to e
nfor
ce. I
t's m
ore
like
a en
d-us
er U
I de
cisi
on, m
ore
than
a te
chni
cal d
ecis
ion.
It c
an m
ake
som
e us
ers
anno
yed.
It's
not
sup
er im
porta
nt.
Ran
k: 2
Impo
rtant
, esp
ecia
lly if
we
do n
ot fi
x th
e C
SR
F-pr
oble
ms
AS
AP
. R
ank:
5
V5
Val
idat
ion
5.1.
5V
erify
that
UR
L re
dire
cts
and
forw
ards
onl
y al
low
whi
telis
ted
dest
inat
ions
, or
show
a w
arni
ng w
hen
redi
rect
ing
to p
oten
tially
unt
rust
ed c
onte
nt.
XX
X60
1
You
hav
e to
impl
emen
t it i
nto
the
clie
nt, i
f you
wan
t to
real
ly p
rote
ct a
gain
st it
. Don
't do
ser
ver-
side
redi
rect
ion
in
that
sen
ce. I
f you
are
not
logg
ed in
, you
are
redi
rect
ed
else
.R
ank:
4 (b
ut n
ot s
ure
if ap
plic
able
).N
ice
to h
ave,
I do
not
con
side
r it h
igh
prio
rity.
R
ank:
3
V5
Val
idat
ion
5.2.
1V
erify
that
all
untru
sted
HTM
L in
put f
rom
WY
SIW
YG
edi
tors
or s
imila
r is
prop
erly
san
itize
d w
ith a
n H
TML
sani
tizer
libr
ary
or fr
amew
ork
feat
ure.
[C5]
XX
X11
6
On
the
pent
est,
poss
ible
to a
dd s
ome
java
scrip
t int
o th
e fo
rm a
nd th
en a
n ad
min
use
r wou
ld re
ad it
, and
it w
ould
ge
t exe
cute
d, a
nd c
ould
do
bad
thin
gs. H
ard
fail.
Ran
k: 5
Mus
t im
plem
ent,
we
have
ope
n is
sues
on
this
th
at a
re b
eing
wor
ked
on.
Ran
k: 4
V5
Val
idat
ion
5.2.
2V
erify
that
uns
truct
ured
dat
a is
san
itize
d to
enf
orce
saf
ety
mea
sure
s su
ch
as a
llow
ed c
hara
cter
s an
d le
ngth
.X
XX
138
Sim
ilar t
o 5.
2.1.
Rel
ated
.R
ank:
5
Sho
uld
be p
rovi
ded
on a
ser
vice
leve
l lay
er
(bac
kend
). R
anl:
3
V5
Val
idat
ion
5.2.
5V
erify
that
the
appl
icat
ion
prot
ects
aga
inst
tem
plat
e in
ject
ion
atta
cks
by
ensu
ring
that
any
use
r inp
ut b
eing
incl
uded
is s
aniti
zed
or s
andb
oxed
.X
XX
94
V6
Cry
ptog
raph
y6.
1.3
Ver
ify th
at re
gula
ted
finan
cial
dat
a is
sto
red
encr
ypte
d w
hile
at r
est,
such
as
finan
cial
acc
ount
s, d
efau
lts o
r cre
dit h
isto
ry, t
ax re
cord
s, p
ay h
isto
ry,
bene
ficia
ries,
or d
e-an
onym
ized
mar
ket o
r res
earc
h re
cord
s.X
X31
1
V6
Cry
ptog
raph
y6.
3.1
Ver
ify th
at a
ll ra
ndom
num
bers
, ran
dom
file
nam
es, r
ando
m G
UID
s, a
nd
rand
om s
tring
s ar
e ge
nera
ted
usin
g th
e cr
ypto
grap
hic
mod
ule'
s ap
prov
ed
cryp
togr
aphi
cally
sec
ure
rand
om n
umbe
r gen
erat
or w
hen
thes
e ra
ndom
va
lues
are
inte
nded
to b
e no
t gue
ssab
le b
y an
atta
cker
.X
X33
8
Bee
n try
ing
to c
heck
if s
ecur
e ra
ndom
is b
eing
use
d,
have
n't g
otte
n an
ove
rvie
w o
ver i
t yet
. Thi
s is
sup
er
impo
rtant
. The
rank
dep
ends
on
the
cont
ext.
Ran
k; 4
Sho
uld
prob
ably
use
som
ethi
ng li
ke U
UID
v4
over
our
nai
vely
gen
erat
ed id
entif
icat
ors,
but
is a
co
nsid
erab
le c
hang
e.R
ank:
3
V8
Dat
a8.
1.1
Ver
ify th
e ap
plic
atio
n pr
otec
ts s
ensi
tive
data
from
bei
ng c
ache
d in
ser
ver
com
pone
nts
such
as
load
bal
ance
rs a
nd a
pplic
atio
n ca
ches
.X
X52
4
V8
Dat
a8.
1.4
Ver
ify th
e ap
plic
atio
n ca
n de
tect
and
ale
rt on
abn
orm
al n
umbe
rs o
f re
ques
ts, s
uch
as b
y IP
, use
r, to
tal p
er h
our o
r day
, or w
hate
ver m
akes
se
nse
for t
he a
pplic
atio
n.X
X77
0
Bee
n w
orki
ng o
n th
is. I
f the
re is
an
ongo
ing
atta
ck, i
t's a
lo
t of s
yste
m d
on't
have
pro
tect
ion
for t
his
at a
ll. If
you
do
n't h
ave
any
syst
ems
to d
etec
t thi
s, y
ou a
re b
asic
ally
, it'
s ha
rd to
look
thro
ugh
logs
and
a lo
t of e
xtra
wor
k to
fig
ure
out w
hat i
s go
ing
on.
Ran
k 4
This
cou
ld (a
nd s
houl
d) b
e ha
ndle
d on
the
impl
emen
ters
sid
e on
a s
erve
r lev
el, a
s th
at is
w
here
the
reve
rse
prox
y fo
r DH
IS2
lives
, and
re
gard
less
, sys
adm
ins
shou
ld b
e aw
are
of w
hat
requ
ests
are
hitt
ing
ther
e se
rver
and
not
DH
IS2
spec
ifica
lly. W
e co
uld
prov
ide
an in
terfa
ce th
at
only
mon
itors
requ
ests
that
get
thro
ugh
to
DH
IS2,
but
I fin
d it
of d
ubio
us v
alue
V8
Dat
a8.
3.5
Ver
ify a
cces
sing
sen
sitiv
e da
ta is
aud
ited
(with
out l
oggi
ng th
e se
nsiti
ve d
ata
itsel
f), if
the
data
is c
olle
cted
und
er re
leva
nt d
ata
prot
ectio
n di
rect
ives
or
whe
re lo
ggin
g of
acc
ess
is re
quire
d.X
X53
2
This
goe
s in
to a
udit
stuf
f, ha
ven'
t bee
n lo
okin
g m
uch
at it
ye
t. If
this
is la
ckin
g, th
enR
ank:
3/4
Use
ful f
or s
ecur
ity fo
rens
ic a
ctiv
ities
. R
ank:
3.
V8
Dat
a8.
3.6
Ver
ify th
at s
ensi
tive
info
rmat
ion
cont
aine
d in
mem
ory
is o
verw
ritte
n as
soo
n as
it is
no
long
er re
quire
d to
miti
gate
mem
ory
dum
ping
atta
cks,
usi
ng
zero
es o
r ran
dom
dat
a.X
X22
6
Tric
k to
test
, tric
ky to
ver
ify th
at y
our p
rote
ctio
n ac
tual
ly
wor
ks.
Ran
k: 3
/4
Uns
ure
how
this
cou
ld b
e do
ne, b
ut it
sho
uld
at
leas
t be
inve
stig
ated
. R
anl:
2.
V10
Mal
icio
us10
.2.4
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
es n
ot
cont
ain
time
bom
bs b
y se
arch
ing
for d
ate
and
time
rela
ted
func
tions
.X
511
Cou
ld d
o m
ore
third
-par
ty c
heck
ing
verif
icat
ions
, rig
ht
now
its
not m
uch
to d
o ab
out i
t.R
ank:
3
V10
Mal
icio
us10
.2.5
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
es n
ot
cont
ain
mal
icio
us c
ode,
suc
h as
sal
ami a
ttack
s, lo
gic
bypa
sses
, or l
ogic
bo
mbs
.X
511
Mor
e on
the
tota
l dev
elop
men
t life
cycl
e th
ing,
and
th
eref
ore
impo
rtant
.R
ank
4.
We
rely
on
CV
E re
ports
on
libra
ries
to v
erify
if
ther
e ar
e an
y kn
own
prob
lem
s. W
e us
e th
ose
repo
rts to
aut
omat
ical
ly u
pdat
e th
e lib
rarie
s. W
e ne
ed to
do
this
mor
e sy
stem
atic
ally
and
pr
efer
ably
aut
omat
ed.
Ran
k: 4
V10
Mal
icio
us10
.2.6
Ver
ify th
at th
e ap
plic
atio
n so
urce
cod
e an
d th
ird p
arty
libr
arie
s do
not
co
ntai
n E
aste
r egg
s or
any
oth
er p
oten
tially
unw
ante
d fu
nctio
nalit
y.X
507
Dep
ends
on
the
kind
of E
aste
r egg
s yo
u us
e.R
ank
4
We
rely
on
CV
E re
ports
on
libra
ries
to v
erify
if
ther
e ar
e an
y kn
own
prob
lem
s. W
e us
e th
ose
repo
rts to
aut
omat
ical
ly u
pdat
e th
e lib
rarie
s. W
e ne
ed to
do
this
mor
e sy
stem
atic
ally
and
pr
efer
ably
aut
omat
ed.
Ran
k: 4
V12
File
s12
.1.1
Ver
ify th
at th
e ap
plic
atio
n w
ill n
ot a
ccep
t lar
ge fi
les
that
cou
ld fi
ll up
sto
rage
or
cau
se a
den
ial o
f ser
vice
atta
ck.
XX
X40
0
Impo
rant
, but
har
d to
do
in th
e co
de. I
f you
allo
w
stre
amin
g up
load
s.
Ran
k: 4
This
is s
omet
hing
we
shou
ld h
ave.
Ran
k: 3
C
1-C
10 T
op 1
0 Pr
oact
ive
Con
trol
s: h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
ASP
_Pro
activ
e_C
ontr
ols#
tab=
Form
al_N
umbe
ring)
258/
286
50/2
58
V12
File
s12
.1.2
Ver
ify th
at c
ompr
esse
d fil
es a
re c
heck
ed fo
r "zi
p bo
mbs
" - s
mal
l inp
ut fi
les
that
will
dec
ompr
ess
into
hug
e fil
es th
us e
xhau
stin
g fil
e st
orag
e lim
its.
XX
409
No
chec
k fo
r tha
t.R
ank:
3
This
is s
omet
hing
we
shou
ld h
ave.
Ran
k: 3
V12
File
s12
.1.3
Ver
ify th
at a
file
siz
e qu
ota
and
max
imum
num
ber o
f file
s pe
r use
r is
enfo
rced
to e
nsur
e th
at a
sin
gle
user
can
not f
ill u
p th
e st
orag
e w
ith to
o m
any
files
, or e
xces
sive
ly la
rge
files
.X
X77
0R
eally
impo
rtant
.R
ank:
4
This
is s
omet
hing
we
shou
ld h
ave.
R
ank:
3
V12
File
s12
.2.1
Ver
ify th
at fi
les
obta
ined
from
unt
rust
ed s
ourc
es a
re v
alid
ated
to b
e of
ex
pect
ed ty
pe b
ased
on
the
file'
s co
nten
t.X
X43
4
V12
File
s12
.4.2
Ver
ify th
at fi
les
obta
ined
from
unt
rust
ed s
ourc
es a
re s
cann
ed b
y an
tiviru
s sc
anne
rs to
pre
vent
upl
oad
of k
now
n m
alic
ious
con
tent
.X
XX
509
Rel
ated
to 1
2.1.
1. D
on't
know
how
this
mec
hani
sm fo
r ad
ding
app
s is
don
e. If
it's
pos
sibl
e to
upl
oad
an
appl
icat
ion
that
can
run
any
time
of c
ode,
then
that
is a
pr
oble
m. N
ot s
ure
if it
is p
ossi
ble
to 1
00%
fix
that
kin
d of
pr
oble
m. T
hat i
s pa
sica
lly w
hat g
oogl
e pl
ay is
tryi
ng to
do.
Ran
k: 5
This
sho
uld
be d
one
on th
e im
plem
ente
rs s
ide,
w
e ca
n pr
ovid
e gu
idan
ce th
at th
ey _
shou
ld_
be
doin
g it.
R
ank:
1
V13
AP
I13
.2.3
Ver
ify th
at R
ES
Tful
web
ser
vice
s th
at u
tiliz
e co
okie
s ar
e pr
otec
ted
from
C
ross
-Site
Req
uest
For
gery
via
the
use
of a
t lea
st o
ne o
r mor
e of
the
follo
win
g: tr
iple
or d
oubl
e su
bmit
cook
ie p
atte
rn (s
ee h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
Cro
ss-S
ite_R
eque
st_F
orge
ry_(
CS
RF)
_Pre
vent
ion_
Che
at_S
heet
), C
SR
F no
nces
, or O
RIG
IN re
ques
t hea
der
chec
ks.
XX
X35
2O
n th
e pe
ntes
t lis
t.R
ank:
4M
ust d
o, h
ave
an o
pen
issu
e on
this
. R
ank:
5
V13
AP
I13
.2.4
Ver
ify th
at R
ES
T se
rvic
es h
ave
anti-
auto
mat
ion
cont
rols
to p
rote
ct a
gain
st
exce
ssiv
e ca
lls, e
spec
ially
if th
e A
PI i
s un
auth
entic
ated
.X
X77
9R
elat
ed to
red-
limiti
ng th
at is
bei
ng d
iscu
ssed
.R
ank:
4
Sho
uld
do, t
houg
h w
e do
not
hav
e an
un
auth
entic
ated
AP
I. R
ank:
3
V14
Con
fig14
.2.5
Ver
ify th
at a
n in
vent
ory
cata
log
is m
aint
aine
d of
all
third
par
ty li
brar
ies
in
use.
[C2]
XX
V14
Con
fig14
.2.6
Ver
ify th
at th
e at
tack
sur
face
is re
duce
d by
san
dbox
ing
or e
ncap
sula
ting
third
par
ty li
brar
ies
to e
xpos
e on
ly th
e re
quire
d be
havi
our i
nto
the
appl
icat
ion.
([C
2](h
ttps:
//ww
w.o
was
p.or
g/in
dex.
php/
OW
AS
P_P
roac
tive_
Con
trols
#tab
=For
mal
_Num
berin
g))
XX
265
This
app
lies
if yo
u ar
e ha
ve th
ird-p
arty
app
s in
the
app
stor
e. S
andb
oxin
g is
com
mon
ly p
reve
ntin
g th
ird-p
arty
ap
ps, e
spec
ially
app
s th
at a
re to
tally
not
che
cked
.R
ank
4
We
have
sta
rted
doin
g so
me
of th
is o
n th
e fro
nten
d si
de, w
e co
uld
be d
oing
mor
e of
it.
Ran
k: 3
V14
Con
fig14
.4.2
Ver
ify th
at a
ll A
PI r
espo
nses
con
tain
Con
tent
-Dis
posi
tion:
atta
chm
ent;
filen
ame=
"api
.json
" (or
oth
er a
ppro
pria
te fi
lena
me
for t
he c
onte
nt ty
pe).
XX
X11
6N
ot s
ure
wha
t you
can
abu
se w
ith th
is. C
an tr
ick
som
eone
to d
ownl
oad
som
ethi
ng e
lse.
Not
sur
e.
Wou
ld a
han
dy a
dditi
on to
mak
e th
e A
PI m
ore
pred
icta
ble.
R
ank:
3
V14
Con
fig14
.5.4
Ver
ify th
at H
TTP
hea
ders
add
ed b
y a
trust
ed p
roxy
or S
SO
dev
ices
, suc
h as
a b
eare
r tok
en, a
re a
uthe
ntic
ated
by
the
appl
icat
ion.
XX
306
Impo
rtant
. R
ank:
3/4
I don
't kn
ow th
e im
pact
of t
his,
but
ver
ifyin
g th
e H
TTP
hea
ders
on
the
appl
icat
ion
boun
darie
s se
ems
wis
e.
Ran
k: 3
