Real-life

Example
Secure Application
Review

Anonymized report

Author: Vincent van Dijk

Date: 15 November 2022

imima
Table of Contents
TABLE OF CONTENTS ............................................................................................................................................................ 2

MANAGEMENT SUMMARY ................................................................................................................................................... 3

VERSION CONTROL .............................................................................................................................................................. 4

DISTRIBUTION...................................................................................................................................................................... 4

SECURE APPLICATION REVIEW .............................................................................................................................................. 5

REVIEW PROCESS ................................................................................................................................................................. 6

STEP 1 - DESIGN REVIEW ............................................................................................................................................................ 7

STEP 2 - SECURITY TESTING ......................................................................................................................................................... 7
STEP 3 - CODE REVIEW............................................................................................................................................................... 7
STEP 4 – FINDINGS.................................................................................................................................................................... 8
STEP 5 - CONCLUSION ................................................................................................................................................................ 8

DESIGN REVIEW ................................................................................................................................................................... 9

SECURITY CONCERN 1 – INSECURE ACCESS CONTROL DESIGN ................................................................................................................. 9

SECURITY CONCERN 2 – THE DATA OF DIFFERENT CUSTOMERS ARE MIXED. .............................................................................................. 10
SECURITY CONCERN 3 – THE DEVELOPMENT ENVIRONMENT IS NOT PROTECTED. ....................................................................................... 10

SECURITY TESTING ............................................................................................................................................................. 11

SECURITY TESTING TOOLS.......................................................................................................................................................... 11

RESULTS................................................................................................................................................................................................. 11
CONFIRMED ISSUES ................................................................................................................................................................. 12

CODE REVIEW .................................................................................................................................................................... 13

1. BROKEN ACCESS CONTROL .................................................................................................................................................................... 13

2. CRYPTOGRAPHIC FAILURES .................................................................................................................................................................... 13
3. INJECTION .......................................................................................................................................................................................... 14
4. INSECURE DESIGN................................................................................................................................................................................. 14
5. SECURITY MISCONFIGURATION ............................................................................................................................................................... 14
6. VULNERABLE AND OUTDATED COMPONENTS ............................................................................................................................................ 14
7. IDENTIFICATION AND AUTHENTICATION FAILURES ...................................................................................................................................... 14
8. SOFTWARE AND DATA INTEGRITY FAILURES .............................................................................................................................................. 15
9. SECURITY LOGGING AND MONITORING FAILURES ....................................................................................................................................... 15
10. SERVER-SIDE REQUEST FORGERY .......................................................................................................................................................... 15

FINDINGS ........................................................................................................................................................................... 16

CONCLUSION ..................................................................................................................................................................... 17

RECOMMENDATIONS ......................................................................................................................................................... 18

REFERENCES....................................................................................................................................................................... 19

Secure Application Review | Author: Vincent van Dijk 2

Management Summary
Client contacted Security Scientist for because of concerns of the security of their latest product.
Security Scientist conducted a Secure Application Review to determine the state of security of the
product.

Security rating

In total there were 25 security issues in the application. These 25 security issues resulted in a security
rating of D. The security expert(s) recommended a security rating of at least B because of the
sensitive nature of the customer’s data.

Rating Design requirement Security tests Code review

requirement requirement
A 0% concerns valid No issues No issues
B < 30% concerns valid No critical and high < 2 OWASP patterns with
issues issues
C < 50% concerns valid No critical issues < 7 OWASP patterns
with issues
D > 50% concerns valid Has critical and high > 7 OWASP patterns with
issues issues

Client: D 67% concerns valid 1 critical and 6 high 9 OWASP patterns with
issues issues

Recommendations
Because Client is a startup, it will need help managing security risks within. A recent study shows that
small-medium businesses do not have the resources to comply with security standards. (V. van Dijk,
2022).

To help Client effectively manage security, consortium could provide the necessary resources to:
• Implement a Secure Development standard for a complete security approach.
• Supply the necessary resources to implement improvements.
• Conduct security reviews on each major release of the application

Secure Application Review | Author: Vincent van Dijk 3

Version Control
Version Date Author Status Changes
1.0 31 October 2022 Vincent van Dijk Initial draft
1.1 4 November 2022 Vincent van Dijk Draft Processed feedback
1.2 15 November 2022 Vincent van Dijk Final Processed feedback
from Client

Distribution
Version Date Send to Send by
1.0 31 October 2022 Vincent van Dijk
1,1 4 November 2022 Vincent van Dijk
1.2 15 November 2022 Vincent van Dijk

Secure Application Review | Author: Vincent van Dijk 4

Secure Application Review
The Secure Application Review is a comprehensive process that will help determine if an application
is ready for release. The Secure Application Review consists of three components: code review,
security testing, and design review. In each component, several activities must be performed to
review the state of the application.

The Secure Application Review aims to identify security risks early in the development process so that
they can be mitigated or eliminated before the application is deployed. By performing a Secure
Application Review, organizations can significantly reduce the risks of their applications.

Design Review: Verification of the high-level and low-level design of the code and the associated
services and API’s.

Security Testing: Testing the code against known security vulnerabilities and standards by using
best-practices tools

Code Review: An expert will review the code on insecure and risky code patterns based on the OWASP
(Open Web Application Security Project) top 10. The expert uses his years of experience working with
developers to figure out common patterns of potential risk.

The Secure Application Review supplies the three verification components of the Software Assurance
Maturity Model (Open SAMM)

Secure Application Review | Author: Vincent van Dijk 5

Review process
The security expert must undertake a comprehensive research process to review an application's
security thoroughly. Each component of the application is assessed using a variety of different steps
and tools.

First, the security expert evaluates the design on potential concerns in the "Design" review
component. Next, the "code review" component must review the application's coding practices.
Finally, the security expert analyzes the application's source code to identify potential security
vulnerabilities in the 'Security Testing" component. By following this comprehensive research
process, security can answer the primary questions of the research.

Secure Application Review Process

Secure Application Review | Author: Vincent van Dijk 6

Step 1 - Design Review
A design review is an essential step in the software development process. It helps to ensure that the
code meets the intended functional requirements and is fit for purpose. The review also assesses
whether the code is secure and of sufficient quality. The design review aims to verify the high-level
and low-level design of the code and the associated services and API's. This process includes
assessing the feasibility of the proposed design and identifying any risks or potential problems.

The design review lists all of the initial concerns of the security expert(s), and then each concern is
investigated and concluded on its validity. This process helps to ensure that only genuine security
concerns are investigated and tested on validity.

Step 2 - Security Testing

Within the security testing component, the security expert(s) test the application's code against four
best-in-breed code security analysis tools. These tools are designed to identify common coding
vulnerabilities that attackers could exploit. By running the application's code through these tools, the
expert(s) can identify any potential weaknesses. In addition to testing against known vulnerabilities,
these tests also review the code for compliance with industry-standard security coding practices.

Step 3 - Code Review

The Open Web Application Security Project (OWASP) maintains a list of the most common code-level
security risks, which they refer to as the OWASP Top 10. OWASP groups these risks into categories,
including Injection, Broken Access Control, and Cross-Site Scripting (XSS). Any organization that
develops or uses software should be aware of these risks and take steps to mitigate them.

In the code review step, the security expert(s) reviews the code for insecure and risky code patterns
based on the OWASP Top 10. Furthermore, the security expert(s) uses his years of experience in
auditing and developing secure code to find common patterns of mistakes that the developers repeat.
These mistakes are crucial to address early in the development lifecycle because they tend to multiply
over time, increasing the risk of potential security incidents.

Secure Application Review | Author: Vincent van Dijk 7

Step 4 – Findings
The findings from this review step consolidate all of the findings from the three components within
the review step. The consolidation will allow for a more comprehensive and holistic evaluation of the
data collected and provide a complete picture of the research question. Furthermore, this approach
will also provide a more streamlined data analysis, ultimately leading to more accurate and reliable
results. In sum, these findings provide a solid foundation to build an understanding of the concerns
and allow for more precise and definitive conclusions to be drawn.

Step 5 - Conclusion
The conclusion of the security analysis will answer the primary research questions concisely based on
the findings and the professional opinion of the security expert(s). The professional statement will be
formulated by logical reasoning based on the insights of the review. The conclusion provides
necessary input for the decision makers to make grounded decisions on the following steps regarding
the application.

Secure Application Review | Author: Vincent van Dijk 8

Design Review
The design review aims to verify the high-level and low-level design of the code and the associated
services and API's. This process includes assessing the feasibility of the proposed design and
identifying any risks or potential problems.

The design review lists all the initial concerns of the security expert(s). Then each concern is
investigated and concluded on its validity.

2 out of the 3 high-level security concerns were valid.

Security concern 1 – Insecure access control design

Broken access control and permissions are the most significant concerns about applications.
(OWASP, 2021) Access control maintains policy by preventing users from acting beyond their specified
permissions. Because of its importance, proper access control needs to be included within the
design.

Client uses Auth0 to provide authentication. Using Auth0 reduces the risks of authentication failures
because the provider manages authentication according to best practices. In 2021, Gartner
recognized Auth0 as the leader domain of Access Management.

However, Auth0 cannot remove all the complexities. Client manages these complexes within the code
correctly by using an API on top of Auth0 that ensures that permissions schemes are set up when
accessing the data.

Conclusion: concern invalid

Secure Application Review | Author: Vincent van Dijk 9

Security concern 2 – The data of different customers
are mixed.
Client expressed that customer data should never be mixed. When mixing the data from different
customers, there is more exposure to potential data loss. Also, mixing data might cause data validity
issues when a developer mistakes the database, especially if the error doesn’t cause warnings and
stays unnoticed.

Client has separated the storage of sustainability documents, users and their customers’ sites. Each
customer has their own Client instance. Documents are stored separately in Azure Blob Storage, with
each customer on their tenant. Users are managed on MongoDB and Auth0, where each customer has
their own tenant.

However, the deployment of the instances is inside one single Kubernetes instance. Secondly, the
MongoDB databases store the metadata on all customers to translate blockchain identification to
companies. An adversary could metadata for all customers if he acquires access to one database.
Lastly, all the application’s logs are stored in a centralized location, and customer logs are mixed.

Conclusion: Concern is valid

Security concern 3 – The development environment is

not protected.
The development environment is a crucial component of any application. The development
environment is often a place for developer to test functionality and code. This tends to make the
application more vulnerable. You always want to secure your development environment against
unauthorized access.

The development environment of Client is publicly accessible, exposing the risky functionality and
code to the world. Furthermore, the Client code base is not separated. Front-end, back-end, libraries,
scripts, and hosting details are stored in one code base. Any developer could access and modify all the
code and configuration anytime.

Conclusion: Concern valid

Secure Application Review | Author: Vincent van Dijk 10

Security Testing
Security testing is a process that helps to identify potential security risks in an application. Many
security risks range from data leakage to code injection attacks. The security expert(s) use four tools
to search applications for security issues. These tools work by scanning the application's code and
looking for common patterns associated with security risks.

Security Testing tools

Code Analysis Scanner 1 – DeepSource
DeepSource is a code quality tool that specializes in finding security issues in code.

Code Analysis Scanner 2 – SonarCube

SonarCube is the industry standard for code quality and security scanning within code.

Code Analysis Scanner 3 – Codacy

Codacy is a tool that focusses on code quality but has a component to analyze code on security
issues.

Code Analysis Scanner 4 – Snyk

Snyk is a specialized tool for finding for finding vulnerabilities and security issues in code.

Results
Code Analysis Scanner Security issues
DeepSource 2 critical, 18 high
SonarCube 2 medium, 5 low
Codacy 29 medium
Snyk 2 critical, 55 high, 112 medium, 161 low
Total 4 critical, 72 high, 143 medium, 166 low

Secure Application Review | Author: Vincent van Dijk 11

Confirmed issues
Not all the issues that were detected are actual security issues. After analysis and consolidation 11
issues stood out; 1 critical, 6 high, and 4 medium. All the low issues were emitted because of the
severity of the current issues in comparison these issues do not pose a threat.

# Issue OWASP Pattern Discovered by Severity

1 Disable X-POWERED-BY Security DeepSource Medium
HTTP header misconfiguration
2 SSL certificate found in the Cryptographic DeepSource High
source code Failures
3 Resource integrity not Security SonarCube Medium
checked for Auth0 misconfiguration
4 Unsanitized input when Injection Snyk High
returning errors
5 Allocation of Resources Security Snyk Medium
Without Limits or Throttling misconfiguration
6 Credentials, usernames and Broken Access Snyk High
more stored inside scripts Control
7 CSRF protection is disabled Security Snyk High
for your Express app misconfiguration
8 Sensitive Cookie Without Security Snyk Medium
'HttpOnly' Flag misconfiguration
9 Critical vulnerabilities foundVulnerable and Snyk Critical
Docker configuration Outdated
Components
10 Vulnerable Vulnerable and Snyk High
Javascript/Typescript library Outdated
Components
11 Kubernetes Role with Security Snyk High
dangerous permissions misconfiguration

Secure Application Review | Author: Vincent van Dijk 12

Code Review
In the code review step, the security expert(s) reviews the code for insecure and risky code patterns
based on the OWASP Top 10. The Open Web Application Security Project (OWASP) maintains a list of
the most common code-level security risks, which they refer to as the OWASP Top 10.

Summary:
• 7 Good practices found by the code review
• 11 issues found by the code review
• 9/10 OWASP patterns with issues

1. Broken Access Control

Access control maintains policy by preventing users from acting beyond their specified permissions.
Failures generally result in information exposure, data change or deletion, or executing a business
function beyond the user's capabilities.

Good practices
• Strong permissions schemes were set up. These schemes were built on top of Auth0 and are
incorporated in the backend and the frontend of the application

Issues found
• You are able to access all the data from the API without verification by the front end.

2. Cryptographic Failures
Cryptographic failures can have devastating consequences. A small error in the design or
implementation of a cryptographic system can allow an attacker to break the system's security,
potentially exposing sensitive data or allowing unauthorized access. Cryptographic failures can occur
for various reasons, including poor design, weak implementations, and faulty random number
generators.

Good practices
• Sharing documents is done through a strong encryption mechanism
• HTTPS has been set up for all the resources

Issues found
• Documents that are stored are not encrypted.
• Passwords are stored inside the code repositories.
• SSL certificates are stored inside the code repositories.
• Data stored in MongoDB is not encrypted, even though it contains sensitive data.
• Encryption libraries are downloaded and stored inside code repository. You won’t be aware of
updates. Furthermore, local storage of those libraries is sensitive to manipulation and
mistakes.

Secure Application Review | Author: Vincent van Dijk 13

3. Injection
When data is not adequately validated, filtered, or sanitized by the application, there is a chance that a
malicious individual can inject malicious code into the application.

Good practices
• Excel sheets are being properly validated.

Issues found
• Unvalidated input is placed inside errors. Also covered in Review → A. Design review

4. Insecure design
There were issues found that are covered in Review → A. Design review

5. Security misconfiguration
There were issues found that are covered in Review → B. Security Testing

6. Vulnerable and Outdated Components

There were issues found that are covered in Review → B. Security Testing

7. Identification and Authentication Failures

The pattern “identification and authentication failures” refers to the mechanisms in place to verify the
logins and the user’s permission to interact with the application during its session.

Good practices:
• Auth0 is a secure SaaS provider for authentication. Auth0 has by default protections against
identification and authentication failures.

Secure Application Review | Author: Vincent van Dijk 14

8. Software and Data Integrity Failures
Software and data integrity failures relate to code and infrastructure that do not protect against
integrity violations. The application must verify plugins, libraries, or modules from untrusted sources,
repositories, and content delivery networks (CDNs).

No issued found apart from the issues discovered by “Review → B. Security Testing”

9. Security Logging and Monitoring Failures

Without logs, you cannot correctly investigate an incident. But during development, relevant logging
is often forgotten, resulting in the inability to investigate incidents and issues.

Good practices found:

• Azure application insights is used to track application’s usage
• Access and permission changes are logged in Auth0

Issues found:
• Auditable events, such as high-value transactions, are not logged.

10. Server-Side Request Forgery

Server-side request forgery flaws occur when a web application fetches a remote resource without
validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted
request to an unexpected destination, even when protected by a firewall or VPN.*

Issues found:
• All the development and production environments of each customer can be found by viewing
the domains mentioned in the SSL certificate.

* From a code review perspective you cannot get 100% coverage on all the potential issues. You need
access to the network and firewall rules to discover all these issues.

Secure Application Review | Author: Vincent van Dijk 15

Findings
The security expert(s) conducted the Secure Application Review on three primary activities on Client:
design review, security testing, and code review. The findings suggest a concern regarding security
and the implementation of the blockchain. The issues in the implementation of the blockchain might
directly hinder the business case for the implementation of Client. On the other hand, the security
concerns indicate a lack of capabilities to protect the consortium's data.

However, the findings also suggest that the developers of Client made a few good choices. These
choices indicate that Client is interested in a skilled workforce to improve the application. But Client
requires more attention to security.

The findings of the review can be summarized into six points:

• 2 out of 3 security concerns regarding it design were valid (67%).

• 11 issues were found during Security Testing; 1 critical, 6 high, and 4 medium.
• 7 Good practices found by the code review.
• 11 issues found by the code review.
• 10/10 OWASP patterns with issues.

Secure Application Review | Author: Vincent van Dijk 16

Conclusion
The Secure Application Review concluded in an Security rating of D, security might be considered, but
it seems to be very limited.

The results show that Client made security considerations within the design of Client. However, these
considerations were limited. 2 out of 3 security concerns tested in the design review were valid.
Secondly, the security expert(s) found 11 issues within the code review. Third, 11 were discovered by
the security expert(s) during the security tests. In total, 25 of the review uncovered security issues. All
in all, these findings resulted in a security rating of D.

These issues are too severe to use for Client to store sensitive information in Client. The design
review shows that the development environment of Client is insecure, resulting in the potential full
compromise of all the instances of Client. Furthermore, data needs the necessary encryption. In the
case of a compromise, malicious individuals can expose all the sensitive data of Client. The security
expert recommends improving the security rating to at least B.

Rating Design requirement Security tests Code review

requirement requirement
A 0% concerns valid No issues No issues
B < 30% concerns valid No critical and high < 2 OWASP patterns with
issues issues
C < 50% concerns valid No critical issues < 7 OWASP patterns
with issues
D > 50% concerns valid Has critical and high > 7 OWASP patterns with
issues issues

Client: D 67% concerns valid 1 critical and 6 high 9 OWASP patterns with
issues issues

Client was rated with a security rating of D.

Secure Application Review | Author: Vincent van Dijk 17

Recommendations
Regarding the security issues, the security expert(s) recommends that the consortium provides the
necessary resources to Client to lift the security rating to at least a B. Because only a rating of B or
higher demonstrates Client’s ability to have effective control on cybersecurity, a rating of C only
demonstrates partial control.

Because Client is a startup, it will need help managing security risks within. A recent study shows that
small-medium businesses do not have the resources to comply with security standards. (V. van Dijk,
2022).

To help Client effectively manage security, consortium could provide the necessary resources to:
• Implement a Secure Development standard for a complete security approach.
• Supply the necessary resources to implement improvements.
• Conduct security reviews on each major release of the application.

Secure Application Review | Author: Vincent van Dijk 18

References
Higginson, M., Lorenz, J.-T., Münstermann, B., & Olesen, P. B. (2017, March 1). The promise of
blockchain. McKinsey & Company. https://www.mckinsey.com/industries/financial-services/our-
insights/the-promise-of-blockchain

OWASP. (n.d.). OWASP top 10:2021. Retrieved October 31, 2022, from https://owasp.org/Top10/

Oxford Learning Dictonaries. (n.d.). Review. Retrieved October 31, 2022, from
https://www.oxfordlearnersdictionaries.com/definition/english/review_2

Samm, O. (2009, March 5). The open software assurance maturity model. OpenSAMM | A Guide to
Building Security into Software Development; OpenSAMM. https://www.opensamm.org
https://owasp.org/Top10/

Amazon (n.d.) What is Decentralization in Blockchain?;

https://aws.amazon.com/blockchain/decentralization-in-blockchain/

van Dijk, V. (2022, July 4). Research - A cybersecurity standard for SME. Security Scientist.
https://www.securityscientist.net/blog/research-a-cybersecurity-standard-for-sme/

Secure Application Review | Author: Vincent van Dijk 19