Carry out the penetration testing activities which are necessary to prove AT LEAST HALF of the vulnerabilities that have been identified for each of the SFRs

Section 1: Overview of the target of evaluation (TOE)

XYZ is an online retail company which has developed an online store called Juice Shop. XYZ is
planning to request Common Criteria certification for Juice Shop. Juice shop’s documentation can also be found at Architecture overview · Pwning OWASP Juice Shop (owasp-juice.shop).

The Juice Shop system includes

  • A Frontend subsystem involving a pure web application implemented in JavaScript and TypeScript (which is compiled into regular JavaScript). In the frontend the popular Angularframework is used to create a so-called Single Page Application. The user interface layout is implementing Google’s Material Design using Angular Material It uses Angular Flex-Layout to achieve responsiveness. All icons found in the UI are originating from the Font Awesome library.
  • A Backend subsystem implemented primarily in JavaScript that involves anExpress application hosted in a js server delivers the client-side code to the browser. It also provides the necessary backend functionality to the client via a RESTful API. As an underlying database a light-weight SQLite was chosen, because of its file-based nature. This makes the database easy to create from scratch programmatically without the need for a dedicated server. Sequelize and finale-rest are used as an abstraction layer from the database. This allows using dynamically created API endpoints for simple interactions (i.e. CRUD operations) with database resources while still allowing the execution of custom SQL for more complex queries.
  • An additional data store, a MarsDB. It is a JavaScript derivative of the widely used MongoDBNoSQL database and compatible with most of its query/modify operations.
  • The push notifications that are shown when a challenge was successfully hacked, are implemented via WebSocket Protocol. The application also offers convenient user registration via OAuth 2.0so users can sign in with their Google accounts.

The following diagram shows the high-level communication paths between the client, server and data layers:

 

Additional details on the components can be found below.

Frontend
The frontend consists of the following elements:

  • A set of Services, each responsible to handle specific RESTful HTTP calls to the backend
  • A set of Components, each responsible for one screen portion of the application (e.g., contract
    form, basket)
  • A set of Templates, working with components to display graphical content to the user

The frontend supports 2 types of users:

  • Users, who interact with the web store and perform actions within their access rights (e.g., login,
    buy a new product, write a complaint)
  • Administrators, who are responsible for the maintenance of the web store.

Backend
The backend of the system is separated into two layers: Server layer and the Storage layer:

  • The Server layer that consists of three components, namely:
    • REST API endpoints to support CRUD operations for the database models
    • A custom set of middleware components that are used to enable the business logic
      (e.g., ordering a product) and access control (e.g., check if user is authorized to
      make an order)
    • A security component responsible for various security-relevant utilities (e.g.,
      captcha verification)
  • The Storage layer that consists of three components, namely:
    • A SQL database that stores
      • Business data (e.g., the products of the store)
      • User data (e.g., usernames)
      • Security data (e.g., security questions)
      • Metadata (e.g., database schema definition)
      • Operational data (e.g., configuration files)
      • Development data (e.g., custom queries and functions)
    • A No-SQL database that stores
      • Feedback data for the products (e.g., reviews placed by the users)
    • The filesystem that stores
      • Business related files (e.g., order confirmation, complaint reports

IT Environment
The IT environment in which the backend of the webstore resides is Linux based (Ubuntu) and
supports 2 types of users (this refers to the provided Virtual Machine, but the IT environment depends entirely on your deployment approach):

  • Web Application user (i.e., a user with limited permissions that is allowed to execute the web-
    store related files)
  • Root user (i.e., a user with all permissions enabled that is responsible for the maintenance of the
    IT environment)

 

Beyond the above description, you should also examine the comprehensive codebase explanation in the following link Codebase 101 · Pwning OWASP Juice Shop (owasp-juice.shop).

Section 2: Your Task

Your task in this part of the coursework will be to evaluate the satisfaction (or otherwise) of the TOE system that is described in Section 1 above against the following security functional requirements (SFRs) of the Common Criteria certification framework:

 

  • 1.1 The TSF shall enforce the systems access control SFP on all subjects, all objects, and all operations among subjects and objects covered by the SFP.
  • 2.2 The TSF shall ensure that all operations between any subject controlled by the TSF, and any object controlled by the TSF are covered by an access control SFP.
  • 1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.
  • 3.1 The TSF shall prevent use of authentication data that has been forged by any user of the TSF.
  • 3.2 The TSF shall prevent use of authentication data that has been copied from any other user of the TSF.
  • 1.1 The TSF shall enforce the access control SFP(s), to restrict the ability to change, and delete the security attributes username and user password to admin users.
  • 1.1 The TSF shall restrict the ability to reset user passwords to root and admin users.
  • 3.1 The TSF shall be able to maintain an internal representation of the following signature events EVENT1, EVENT2, …, EVENTn that may indicate a violation of the enforcement of the SFRs.
  • 3.3 The TSF shall be able to indicate a potential violation of the enforcement of the SFRs when a system event is found to match a signature event that indicates a potential violation of the enforcement of the SFRs.
  • 1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed:
  • no user other than the user who created data stored within the system can delete or modify them
  • no user can create data associated with another user
  • 1.3 The TSF shall explicitly authorise access of subjects to objects based on the following additional rules:
  • only a user with root rights can register another user as an admin user
  • 1.4 The TSF shall explicitly deny access of subjects to objects based on the following additional rules:
  • no normal or admin user can register himself/herself or another user as an admin user
  • 2.2 Upon detection of a data integrity error, the TSF shall decline any operation related to the particular piece of data.

To assess the above SFRs, you should

  • Identify which of the vulnerability challenges of the Juicy Shop system that have been described in[1] are relevant to the satisfaction/violation of each SFR
  • Carry out the penetration testing activities which are necessary to prove AT LEAST HALF of the vulnerabilities that have been identified for each of the SFRs
  • Record the evidence generated whilst carrying out penetration testing for each vulnerability
  • Provide a rationale of how exactly the evidence accumulated for (3) indicates the violation of the SFR that is associated with the relevant vulnerability challenge in (1)

More specifically, your submission should be structured as follows:

SFR Identifier: SFRi

Related vulnerability challenges: VC1, VC2, …, VCn

Tested Vulnerability Challenges:

VCj

  • Description of penetration testing that was carried out for VCj
  • Outcomes (evidence) of the penetration testing in (a)
  • Explanation of how the evidence included in (b) proves that SFRi is violated

VCj+1

  • Description of penetration testing that was carried out for VCj+1
  • Outcomes (evidence) of the penetration testing in (a)
  • Explanation of how the evidence included in (b) proves that SFRi is violated

etc.

 

Section 3: Tools that you will needed

Lab Deployment

The system that you are going to assess is publicly available on the following repository and it offers various deployment options (check the setup section of the repository).

Repository: https://github.com/juice-shop/juice-shop

In addition to the provided options we created an alternative way that might be more convenient for some; its ready out of the box image usable on most popular hypervisors (Virtualbox, VMware, Parallels etc.), you may download the virtual machine (.ova file) from the following link (make sure you access the link with your city email, otherwise it will not work).

  • To deploy the image in VirtualBox, follow the instructions on this link.
  • To deploy the image in VMware Player, follow the instructions on this link.
  • To deploy the image in M1 Mac OS, its better to use one of the proposed deployments offered by OWASP on this link, but you can also try to use UTM to deploy a Linux distribution of your choice, then there you can try deploying the virtual machine or the container.

Security Tools

For the investigator machine you can use either a container or a virtual machine, Offensive Security offers their Linux Distribution (i.e., Kali Linux) in any format you are likely to need it (including M1 support), check the following link. The default images contain all the necessary tools you have practiced on the tutorials.  For instructions, examples, and documentation on how to use the tools, you should consult Tutorials 6 (Nmap) and Tutorial 7 (ZAP).

Additional deployment notes

Make sure your Investigator system and the Web Shop system are on the same network. There are 3 basic cases for that.

  • You have 2 virtual machines for both systems
    • Both must have a bridged network adapter, or host-only or to be connected to the same custom network
  • You have 2 containers for both systems
    • Both must be part of the same network. You can use the tutorial 1 or 2 docker-compose files if you want to use a docker-compose. If you use regular docker make sure both are connected to the same network. One way is the following
      • docker network create network_name
      • docker connect network_name investigator_container_name
      • docker connect network_name web_shop_container_name
    • You have 1 virtual machine and 1 container (either the investigator/web-shop)
      • Make sure that the virtual machine is on a bridged or host-only network
      • The container should be able to communicate with it with no further configuration.

[1] PART II of https://pwning.owasp-juice.shop